Upcoming obscure video modes

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Platformer Video Mode 3+: 16x4 pixels per tile

Post by uze6666 »

martinsustek wrote:Good idea. So there will be one palette lookup for two adjacent pixels? And how much colors per tile? And palette for whole screen or per tile (like on zx spectrum)?
8 colors can be enough for some games - it depends on what colors will DAC generate, I suppose W,RGB,CMY,K, but real colors can be different.
There's no palette lookup involved, not enough cycles for that. Just packing two pixels in the same byte and using a simple shift to "view" the second pixel. Since only 3 pins of PORTC would be enabled that gives this global and fixed palette of 8 colors:
Image
Also, I got to think about the sprites in which we ususally need to allocate a color to be transparent. In this case that would mean sprites could never use say the yellow or purple. But it also happens that this scheme leaves 1 unused bit per pixel...perfect to act as a transparency flag, no lost color! :mrgreen:

Anyhow, since such a video mode represents quite some work to implement, I may wait until somebody comes up with a game that requires it!
Okayyy, now this thread counts as hijacked. I change the subject to "upcoming obscure video modes".
:lol:
User avatar
Janka
Posts: 214
Joined: Fri Sep 21, 2012 10:46 pm
Location: inside Out

Re: Upcoming obscure video modes

Post by Janka »

I've rethought the 16x4 mode again, and found it allows a dynamical 16 of 256 palette, half the flash needed for tile data, and at the same time 240x224 resolution; at the expense of 256 bytes RAM. :idea: (If 256 bytes RAM penalty are too hard, with the same mode you could always use e.g. only 8 of 256 colors, which frees 136 bytes en block and another 56 scattered in 7 blocks of 8 bytes usused palette entries. Or with 10 colors 100 instead of 256 bytes, or with 12 colors 144 instead of 256 bytes, what you like.)

The problem with current mode 3 having too few cycles for palette lookup is because we have 6 cycles per pixel, so one tile of 8 pixels has 48 cycles. For the usual direct video we need one LPM (3 cycles) and one OUT (1 cycle) per pixel, resulting in 32 cycles per 8-pixel tile. This leaves 16 cycles for the calculation of the next tile address from the index, which video mode 3 uses up completely:

Code: Select all

cycles | code
=======+======================================================================
3      | lpm r16,Z+    ; load pixel 1 direct video
1      | out vport,r16 ; output pixel 1 data
2      | Used for calculation of next tile address from index (step 1)
-------+----------------------------------------------------------------------
3      | lpm r16,Z+    ; load pixel 2 direct video
1      | out vport,r16 ; output pixel 2 data
2      | Used for calculation of next tile address from index (step 2)
==============================================================================
12 cycles for 2 pixels, 8 calculation steps per 8-pixel tile.
If we had only one tile lookup per 16 pixels, we would still need the same 16 cycles for calculation of the next tile address, but now they come from a pool of 96 cycles (16 pixels) instead of only 48. So we have 48 cycles for LPM/SWAP and OUT, and 16 cycles for tile address calculation, and another 32 cycles left for the palette :!:

Code: Select all

cycles | code
=======+======================================================================
3      | lpm r28,Z+    ; load pixel 1+2 palette indices from tile. (r28 is yl)
2      | ld r16,Y      ; palette lookup
1      | out vport,r16 ; output pixel 1 data
-------+----------------------------------------------------------------------
1      | swap r28      ; other pixel palette index (r28 is yl)
2      | ld r16,Y      ; palette lookup
2      | Used for calculation of next tile address from index (step 1)
1      | out vport,r16 ; output pixel 2 data
==============================================================================
12 cycles for 2 pixels, still 8 calculation steps per 16-pixel tile.
Please note this is still mode 3, only with a little tweaking, but with all features. 8-)
Last edited by Janka on Thu Oct 18, 2012 11:51 pm, edited 1 time in total.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Upcoming obscure video modes

Post by uze6666 »

Yeah, indeed, having wider tiles is a good trick to get more free cycles. However 16 cycles is not enough for any sort of palette translation without reducing resolution. That's because it would imply at very least a LD per pixel...that's 32 cycles right away. :(
User avatar
Janka
Posts: 214
Joined: Fri Sep 21, 2012 10:46 pm
Location: inside Out

Re: Upcoming obscure video modes

Post by Janka »

Uze, please see the "code" parts that I've posted. You are right the LD for 16 pixels need 32 cycles, but as we have only SWAP (1 cycle) instead of LPM (3 cycles) for every second pixel, we get the needed additional 2 cycles for each second LD out of that (and the 2 cycles for the first LD out of having 16 pixels per tile instead of 8).

EDIT: Edited the calculation in my previous post for better matching of the code part.
Last edited by Janka on Fri Oct 19, 2012 12:08 am, edited 2 times in total.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Upcoming obscure video modes

Post by uze6666 »

Sorry Janka, I missed the second table on my tiny smart phone! :oops: Yes, in that case that could work. As you mentioned, only downside to that approach is that a 16 colors palette really takes 256 bytes. So all BG tiles would need to have the same 16 colors?
User avatar
Janka
Posts: 214
Joined: Fri Sep 21, 2012 10:46 pm
Location: inside Out

Re: Upcoming obscure video modes

Post by Janka »

uze6666 wrote:As you mentioned, only downside to that approach is that a 16 colors palette really takes 256 bytes.
Yes, but if the game uses only e.g. 10 of 256 colors, that would be only 100 bytes. Because the other palette entries are never used, an understanding programmer could layer a union/struct on top of the palette and use these unused palette entries for variables.
So all BG tiles would need to have the same 16 colors?
Basically yes. But I think someone will soon introduce palette swapping through tricky programming.

EDIT: Oh, and I think to have palette effects on the background (e.g. switching colors on the fly with only 16 STS) is more useful for a lot of games than having all colors from the inkpot at the same time. I think of selectively lighten/darken some floors, ladders and other background elements.
User avatar
Janka
Posts: 214
Joined: Fri Sep 21, 2012 10:46 pm
Location: inside Out

Re: Upcoming obscure video modes

Post by Janka »

Don't know if/how the ATmega644 mirrors its RAM memory in the address map: If yes, we could use YH instead of YL for palette lookup, leaving out index 0 because of being in the register file (or abuse an unused register like a timer output compare) and using only 16 bytes RAM for a 16-color palette, at the expense of having the palette scattered through RAM.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Upcoming obscure video modes

Post by uze6666 »

Don't know if/how the ATmega644 mirrors its RAM memory in the address map
Hmmm, *very* interesting idea :ugeek:...I never though or tested that. I'll report on it when I get a chance.
User avatar
Janka
Posts: 214
Joined: Fri Sep 21, 2012 10:46 pm
Location: inside Out

Re: Upcoming obscure video modes

Post by Janka »

Oh, and for the original idea, if RAM is not mirrored: It's 16 out of 256 only for the naïve approach where odd and even pixels should be colored independently. But more is possible if we honour two pixels are now a pair: in most tilesets, a lot of the possible 256 combinations of colors are not used.

e.g. let the tile palette index be 0x52. Then the color index for the even pixel is 0x52, while for odd pixel it is 0x25. These palette indices should be filled e.g with red and green so pixel 1 is red and pixel 2 is green. The other way around is same, with 0x25 the first pixel now takes from the green palette index and the second from the red palette index. This works as expected. Now we have another pixel pair with tile palette index 0x53. In the naïve approach, that should mean first pixel is red and second pixel is e.g. blue. The palette indices are 0x53 and 0x35, which should be filled with red and blue. With a third pixel pair with tile palette index 0x23, in the naïve approach, that should mean first pixel is green and the second is blue. The palette indices are 0x23 and 0x32, which should be filled with green and blue. What we have now:

Code: Select all

0x23 green
0x25 green
0x32 blue
0x35 blue
0x52 red
0x53 red
One could easily see our palette are 16 blocks of 16 bytes holding the same color. The lower 4 bits are a "don't care" which we need because we cannot AND the palette index because of missing cycles.

But what if we care? What if we find out we never e.g. have a green pixel paired with a red pixel? Then we could free palette index 0x52 and 0x25 and use it for another color combination, e.g cyan+magenta. I'd say, let's make a tool which takes a direct video tileset image, checks the color combination of adjacent pixels and prepare a tileset array and an adjusted palette array with a minimum number of entries :D

EDIT: I will do such a tool tonight. Should be easy.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Upcoming obscure video modes

Post by D3thAdd3r »

Very interesting, I wonder though how sprites will work? What happens when an overlapping sprite on tile breaks the pair rules?
Post Reply