0
But damn it, this time I think I've got it.
I started this just before New Year's, and I'm nearly done with it now. I finally came up with a way to have my image converter create decent-looking screens that flicker between multicolor mode and bitmap mode to increase the apparent number of colors, and tonight I loaded it on hardware to see it work. And it does.
Even nicer, there is room left for sprites. I should have done some as a demonstration.
It uses most of VRAM though. Very little CPU though. All you do is set up a vertical interrupt callback (or poll for it), and during the blank you change VDP Registers 0 and 1 to switch between bitmap and multicolor modes.I don't have a CRT here to test it on, but in theory it should look best there (I have one at my office, though, I may try that just to see...) My two TVs actually responded differently. My big high-def TV didn't flicker at all - it tried to deinterlace the image! The results were not bad, except in some places it decided to draw separate lines rather than blend the colors. My little monitor had noticable flicker, so I used that in the video.
The mechanism turned out to be much simpler than I expected. All I had to do was map the multicolor first to half the image's brightness, and then run my normal dither code on top of that (but taking into account the multicolor contribution). It looks pretty good on most images, not just cartoons, but it's late and this was the image I was testing with tonight.
Because we already know that some flicker values may be unacceptable, I added a slider that lets you control how much flicker is acceptable in the result. The slider may need tuning, and I am not sure the best values. Right now it defaults to 95% and that's mostly there to prevent black+white flicker.
As you tune the slider lower, the difference in colors should be less but the image will have fewer options and end up blockier.There's a new setting for error control. Previously I just added up the error on every pixel, but I noticed that up to three pixels can contribute an error value to a single new pixel. The actual correction for that pixel should be the average of all three of them, not the sum of all three of them. I think. That's the default mode now, but an option lets you go back to the old mode. I'm not certain the new mode is more correct but it IS less noisy.
While I was at it, I completely rewrote the entire dithering engine, throwing out all the experimental code and hacks. As a result, the dithering (for both normal mode and half-multicolor mode) is now much better, with fewer artifacts around the borders and far less bleeding. In addition, all color work is now done internally in floating point to reduce rounding errors. I also fixed a couple of true bugs I found during all this which affected the dithering.
Finally, just for demonstration purposes I've added an MSX image output, and I will probably add a ColecoVision one too. They can already use the files I output, but this just makes it easier for them. For TI we already have the XB example code, after all.
I am not /quite/ ready to publish the converter - almost! But I didn't post entirely to tease. Here's the sample application from the video - I'd love to hear if it works on other people's machines. (DSK and raw OBJ file included. Editor/Assembler #3 file in both cases, plus source code for the viewer and my notes on the VDP layout).
halfmult.zip 89.97K
12 downloads(edit: there is a typo in readme.txt -- the file on WORK.DSK is "DSK1.TIPLAYER", there's no ".OBJ" part on the disk image.)
Edited by Tursi, Thu Jan 26, 2012 2:04 PM.
