Mode 52: 2bpp square pixels with scrolling & sprites

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Mode 52: 2bpp square pixels with scrolling & sprites

Post by D3thAdd3r »

Having that a variable is a good idea, especially in a mode like this where you can have many more ram tiles than could actually be blit as sprites. Tons of flexibility then for offloading title/menu/etc graphics while still having lots of tile indices available in game. Stacked on top of already small graphics resources you could do a lot without even touching the SD.
User avatar
nicksen782
Posts: 714
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Re: Mode 52: 2bpp square pixels with scrolling & sprites

Post by nicksen782 »

I do have a concern though. Did I read correctly that you are still limited to 256 tile indexes per tileset? If you have smaller sized tiles wouldn't that mean that your tileset would have more tiles and you would reach that limit sooner?

How do you mitigate that? Is there a way to change tilesets per screen section or row or something?
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Mode 52: 2bpp square pixels with scrolling & sprites

Post by Jubatian »

nicksen782 wrote: Mon Jul 02, 2018 7:06 pmI do have a concern though. Did I read correctly that you are still limited to 256 tile indexes per tileset? If you have smaller sized tiles wouldn't that mean that your tileset would have more tiles and you would reach that limit sooner?

How do you mitigate that? Is there a way to change tilesets per screen section or row or something?
Yes, the limit is 256 tiles, so active ROM + RAM tile count can not exceed that. With clever design stuff should fit in that (Flight of a Dragon has only 128 background tiles! It could have had more, but I rather used the ROM space for levels).

The mode is capable to do horizontal splits, for every tile row, you can select a background tileset from a global set of four. The Li-2 demo utilizes this, you can see it in action there, the plane's upper half and lower half are two different tilesets, the total tile count is somewhere above two hundreds maybe while it uses eighty RAM tiles. So not by much, but it's over 256 tiles total. The four background sets are enough for even a full-screen image if you decided on that (you can set their locations on the fly, so if you have so much ROM to spare, you may have a title screen served from ROM, and then a game with its own tilesets).
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Mode 52: 2bpp square pixels with scrolling & sprites

Post by Jubatian »

D3thAdd3r wrote: Mon Jul 02, 2018 7:04 pmHaving that a variable is a good idea, especially in a mode like this where you can have many more ram tiles than could actually be blit as sprites. Tons of flexibility then for offloading title/menu/etc graphics while still having lots of tile indices available in game. Stacked on top of already small graphics resources you could do a lot without even touching the SD.
That was about the idea: with this mode, you have lots of RAM to spare, depending on sprite count, you can go even below Mode 72. Instead of SD, I would say SPI RAM, the lots of RAM actually gives more freedom for designing for loading things from the card on an Uzebox without the SPI RAM extension, but of course it is also nice for 60Kbyte games not using the card at all. Some kind of strategy game for example which requires larger state (although then the difficulty would be saving that state: you can use the EEPROM, but then it takes up lots of blocks).
Post Reply