I have a lot of the ideas for doing stuff on the PCE, some public and mentioned here, and some not (private). I really want to get around to show casing these ideas in some demo form. It's fine and dandy to talk about them, but I know in my heart of hearts that no one is probably going to implement them. Since these demos I'm working on are to do with tips and tricks, and how to implement them - I'll post my progress here.
BG layer made up of sprites. I know I've already posted a bit on this, in this thread, but now that I have some free time (finished my last of my Finals on Thursday), I wanted to demo this idea. So this is what I'm working on:
I'm doing this one by hand (making the decoding LUTs for the above metatile set), and to get through it quickly (making the tables), I have some redundant tiles in vram. Just ignore those for now.
Some perspective: for this demo the gameplay/action window is 208x176 (it could be longer with a status bar, which is irrelevant). The foreground layer is a map where each entry is 32x32pixel
metatile. Each entry is used to index a series of LUTs, to break down the metatile into hardware sprites. To keep things optimal, it's best to have the majority of metatile entries decode directly into a single hardware 32x32 sprite. This is to keep the SATB usage as low as possibly, as well as the number of objects per scanline at minimal (not pixels per scanline, but objects per scanline - since now with a clipped display of 208, the sprite pixel limit exceeds the width of the display by 48pixels). Some entries are made up of paired 32x16 or 16x32 hardware sprites, to save on vram wastage. Some even have 16x16 sprite entries. The blue blocks in the metatiles, specifically in pairs, represents no hardware sprite.
So a screen display of 208x176 has a max object capacity of 7x7 metatiles. I'm keeping this example simple by parsing every metatile of the map, relative to the display area, every time there is screen movement. I could optimize this to cover just the 2 sides of the screen (diagonal direction for scrolling), and cache the hardware objects so I only have to update their X/Y positions instead of rebuilding them every frame (on a scroll change), but the complexity of such a map engine takes time. And there are some other ideas/demos I want to make in my in between semester break. So, every time there's a scroll change, every object gets re-decoded. I've set the limit at 300 cpu cycles per 32x32 metatile decode, and assumed the worse case scenario is that all metatiles translated into real hardware sprites (blank or null entries are normally quickly bypassed), then I'm looking at 7x7 = 49 x 300 = 14,700 cpu cycles or 12% cpu resource. And in that process of decoding, I'm also filling/updating a buffer/temp collision map in ram. So some of that 300 cycles is used for the collision map. So far in the decode routine that I've written, I haven't come close to the 300 limit, but I'll know in the end.
Just FYI - this foreground map setup isn't really made to simulate something like Super Mario games; I just wanted something to show that was more than just "blocks". This method has limitations that affects design, but some games (with or without modification) could be used to represent what you can do with this. One of those limitations, is depth. And by depth, I mean that the surface the main character walks on - should be a solid line (how they walk on it and not necessarily how its drawn). There are some careful designs where this doesn't have to be true, but then level design gets more complicated.
I think this video of Super Adventure Island presents some stages for visualization:
When I mentioned trying to keep a "flat surface" for the character to walk on, I don't mean that the pixels have to be flat all the way across the surface. In the video, look at 2:52 with the top of the stones graphics. Higgans walks on them as if they were flat, but clearly you can see small pixel gaps on the surface. This is fine. In the same level, the dirt/ground foreground area is fine, but the grass "foliage" should be made a little bit more sparse if it's going to appear in front or behind the character.
@13:19 - is probably the perfect example of how to use this sprite foreground method.
@17:06 - the sprite map as the back layer, and the hardware BG layer as the foreground layer.
@21:00 - imperfect surface (snow) treated as perfect flat surface and slopes. Perfectly doable. Trees are fine too. The snowflakes, in front or behind the sprite object layer, works too. Might be some slight issues for the fortress graphic at the end of the stage (would have to be modified).
@23:50-24:16 - implements fine with sprites, even the columns at the end. But the transition beyond 24:16 would have to be a little handled differently. But once @24:28, then it's fine again (switch to BAT as foreground, sprites as background).
