All Beauty Must End
Yesterday, I implemented the last remaining bit Urban Runner needed for 16bit graphics support, making all my dithering exploits useless.
After ScummVM got 16bit support for GSoC 2009, I chose to wait a bit before adapting the gob engine, since a lot of other code was entangled into the problem, including the CoktelVideo classes and the Indeo3 decoder.
But then clone2727 came along and completely revamped the VideoDecoder interface, making it 16bit-ready. So I rewrote the IMD/VMD classes to fit that interface accordingly. Next, I rewrote the gob engine drawing functions to support 16bit surfaces as well, and plugged everything together to get Urban Runner’s Indeo3 VMDs running in 16bit colour mode.
Unfortunately, I then hit a road block. One big thing still missing for a full 16bit Urban Runner experience was still high-color non-Indeo3′d VMD videos. I tried several approaches, but after the CoktelDecoder rewrite, they either didn’t work anymore or were dead-ugly. Becoming frustrated quickly, I started several other projects, handled some RL problems, etc., basically stopping working on it completely for several months.
Until yesterday. I found a way to implement the missing pieces, fixed a few smaller issue, and can now lay all that all to rest. So, I officially declare my dithering “series” dead .
Now, what’s next?
First of all, the one big problem in Urban Runner, the hotel lock-up, is still present. However, a guy by the handle of SylvainTV took a good look and gave me some valuable hints: The videos are supposed to play “in the background”, while the script execution continues. According to him, he hacked in a small proof of concept, and with that, the lock-up is gone. Of course, I need to find the proper way of hooking that into the engine, otherwise I invite all hell of strange bugs . I already have a few suspicious I need to check out.
Another glitch that’s bugging me is how the sprites aren’t completely correct yet. All sprite data in Urban Runner is in YUV (or YUV840, I guess you’d call it, since each 4×4 block of Y has one U and V value) and I apparently haven’t figured the exact format out yet. As you can see in the following screenshot, it looks like one colour channel is a bit offset to the lower right. The original does not feature that glitch, so it’s obviously my fault.
Anyone who might me interested in looking over my code and fiddling a bit with it, please contact me.
UPDATE: Thanks, again, to SylvainTV, the YUV glitch is fixed.