2bpp Video Mode Ideas

[lightfoot256]

I've been thinking about doing a 2bpp mode with tiles and sprites but shrinking the video output into the centre of the screen rather than making it stretched. This might look a little strange having just a small picture in the middle of the TV but at least it'll be high resolution! .

Anyway; what I was looking at was doing something similar to a buffering mode where you write to the buffer and then output the buffer; I was thinking of basically splitting the screen into 2 sections during hsync; the first half draws to the buffer and the second outputs it really fast but to avoid the picture being over to the right of the screen split the first part into 2 and offset it by half so the image ends up being somewhere in the middle or as close as possible. Then the way the rendering is done really fast is by using only 2 bits per pixel and hard coding all 256 combinations into a lookup table. This wastes lots of precious rom but now that the bitmap data is 4 times smaller who cares .

I was thinking along the lines of storing the jump address in the Z register; then adding the pixel value, making the jump, subtracting the pixel value from Z so we're back to the jump table address again and adding the next pixel and then making the next jump meanwhile outputting a pixel every 3 clocks; the down side to this is we have to lose a pixel combination (0) and instead of putting output instructions there put in the code for the end of the loop so the last byte in the buffer is always 0x00 and thus always ends the loop -- this could break if you accidentally write a 0x0 to the main buffer but the speed it gains it worth it I think. Just no solid dark backgrounds . I'm not sure what the byte widths are for the instructions I was planning on using but guessing and using 2 bytes per instruction gives a total of 20 bytes per screen byte (or 4 colours) and only 5kb for all 256 combinations.

I've not worked out how many clocks you have to actually write to the buffer but now that the rendering and buffer aren't overlayed on top of each other like I was doing before I might have a little more room... I was thinking of storing the tile data and masking data separate so the background plane is just blit 1:1 against the buffer, then the background is masked out using the masking values for the foreground tiles (binary 'and' the values) and finally the foreground is added (binary 'or' the foreground onto the buffer) onto the buffer. Could use a similar method for the sprites. Considering it's all only 2bpp it won't look as good as the original sonic but game boy managed to make a bunch of cool games using only 4 colours; I could even find 4 nice green colours and pretend it's a remake of the gb version .

Not sure what kind of resolution to expect from this method either; I guess it depends on how much time it takes to build the buffer up and thus how much time is left to output it... we'll see.

[uze6666]

Sounds very interesting. I got into thinking about such a mode a while ago (scanline based double-buffering). But it quickly get mind boggling when you consider that the code to pre-compute and write in the 1st buffer must be intertwined with code to output the second buffer. This gets even messier if you have mixed rom and ram tiles in your VRAM array like mode 3. To simplify things I though about only using RAM tiles. However, with 2K at 2bpp, that gives a maximum of about 120 tiles available at once...including the tiles used for sprites blitting. Backgrounds would have to be pretty plain. I guess my approach is just wrong.