doxDev News - Wheels & Fire WIP (2010/06/23)

Wheels & Fire

After looong break i'm looking again at Wheels & Fire from TCH.
Game is running on custom, blitter based hardware (sprites + framebuffer layer with linescroll feature, and sprite-to-framebuffer rendering mode ).

I have made a lot of changes/improvements lately, but there's still a lot to do:
- proper image scaling - quite weird (close to hardware, i think) way to draw scaled images. for more details pls scroll down to the end of this post.
- framebuffer (various problems)
- sound - not emulated yet (2nd 68k + samples)


Here's few pics from the game:





W&F video hardware supports image scaling. For each image(sprite) to draw, there's a couple of parameters sent to the blitter:
- screen cooridnates of image rectangle ( top left ad bottom right corners) _after_ scale transform applied,
- source image cooridnates (only the upper-left corner, no info about the source dimensions),
- two sets (for x and y scale) of magic parameters : data1 (5 bit), data2 (5 bit), four flags ( double/half scale , zero/nonzero params (maybe they are just the MSB of the data1/data2))
Magic ;) parameters are packed into 5 bytes. They are essential to udnerestand how the hw works and how the scaling is done. So far it's just pure magic ;) Params are copied from a lookup table addressed by the scale factor (0-400%):

X Scale Table:
7 6 5 4 3 2 1 0
- - - A B C D E
- - - F G H I J
- - - - - - - -
- - - K - L - M
- - - - - - - N

Y Scale Table:
7 6 5 4 3 2 1 0
- A - - - - - -
D E - - - - - -
B C - F G H I J
- - K - L - M -
- - - - - - N -


BITS ABCDE = DATA1 (0-31)
BITS FGHIJ = DATA2 (0-31)
BIT K - ( scale > 200% ) ? 1 : 0
BIT L - ( DATA2 != 0) ? 1 : 0
BIT M - ( DATA1 != 0) ? 1 : 0
BIT N - ( scale < 50% ) ? 1 : 0


Both (x and y) tables contians exactly the same data, just shuffled arround to easielly pack (by OR-ing) into 5 bytes and send to blitter. For now i'm uisng lookup table to determine the scale factor (based on the above params). Works pretty well, but the goal is to underestand how the data is interpreted by video hw and emulate it properly.

RED = data1 (0-31), WHITE = data2 (0-31)
Ranges 25-50% and 50-100% (as well as 100-200% and 200-400%) contains very similiar data, and the first one has special ("half") bitflag set (same for 200-400% - there's another bitflag set("double")). Probably for change the video hw (fpga based) pixel counter/clock.

Both data1 and data2 are mysterious for now. There's few ideas about them:
- fixed point 5.5 (src pixel delta/step?)
- pair of step + oveflow for src pixel "counter"
- floating point num (5 bit mantissa, 5 bit exponent)

A couple of examples ( scale factor - data1 - data2 - bit M - bit L) :




Source: doxdev.blogspot.com