Yeah this is very tough to do right now. Essentially you have to break ground at every step to handle the stuff no one has ever done yet, which is really all the hurdles that has kept anyone from making a full and complex scrolling game. The sprite requirements here are higher than a Mario type game too..my main thought on that is "...'dat whip!?
I believe this can be done and turn out amazing, and I also believe the engine that does so immediately makes a plethora of scrolling games possible. Mario for instance, would probably not be as tight of a squeeze on resources. Partitioned sprites are really a must for any of this I'd say. It's a modest 10-15%+ gain, but we are taking about stuff on the extreme edge of possible at this point; right where most of us enjoy it!
So I did think up a new theory on what the best sprite rotation system would be. Of course it ends up being semi-complicated and cpu intensive but I think it will help considerably. The main concept is that some sprites are more important than others and additionally that some parts of those sprites are more important. Basically each 8x8 sprite can take up to 4 ram tiles, but often times there is just a couple pixels or none actually drawn on the ram tiles where the sprite simply went over the 8pixel boundaries but that part of the sprite is blank. The concept could work a couple different ways, 1 requiring significant overdraw on ram tiles(that is blitting higher priority stuff on top of stuff we had already used that ram tile for), and the other being a multi-pass approach on blitting in ProcessSprites().
The first approach I question whether we would have the cycles available, but basically BlitSprite() returns how many non-clear pixels were drawn on the ram tile just drawn and we keep track of that number(to save stack/ram space, put it in ram_tiles_restore since we will have already restored everything at that point?). When we run out of ram tiles but are still in ProcessSprites trying to draw stuff, we draw it to a reserved ram tile and calculate how many non-clear pixels where drawn. We scan through the list again looking for ram tiles where less pixels where drawn, and if found we simply copy from that reserved over that ram tile. Then at the very least we have maximized the number of actual sprite pixels drawn, and don't have a bunch of mostly empty ram tiles which happens constantly in these games currently. Somewhere at the end we make sure to use that reserve ram tile too
Might be a more clever way to handle the details but I haven't had time to explore it.
The second approach is a different modification to ProcessSprites(). Where normally we try to handle drawing up to 4 ram tiles for each sprite, we instead will only draw 1 of them on the first pass. We will end up making 4 passes through all the sprites this way. For each sprite in the sprite tile table, store 4 numbers. These number indicate which parts of the sprite are more important. We calculate this imagining that the sprite is evenly crossing 4 ram tiles, this works because we just look and say oh this is the back of simons boot. The least important part is the very back/bottom and it will be commonly drawing just a few pixels. Simon's head of course would have maximum priority for every quadrant because it would be very obvious when that flickers. In cases where only the x axis was off alignment we would add the upper left and lower left together and draw it the first pass, the second pass will fail because there is no lower left quadrant if it's aligned on y. Likewise for the right side to calculate its priority. The reason for that is that a sprite that is aligned on at least 1 axis is much more certain to not be wasting ram tiles on just a couple pixels. Of course the same way for the y axis and yes I know this sounds like a headache in the form of a rather late night poorly edited explanation. I think just a mental experiment by anyone, which is all I have done yet, shows that it will have a noticeable effect though.
A third possibility would be to combine those methods if cycles permit. Partitioning + Advanced Sprite Rotation, I feel comfortable in saying we could have 25-35% more perceived
sprite pixels on screen that we are used to seeing given the same amount of ram tiles. I did a write up on some of my thoughts on the subject and went a little overboard. It's in my wiki rants
. The actual sprite rotation I don't have the details hammered out on, but I will write it up and test it out when I get a few backlogged Uzebox tasks done. I think with a couple guys teaming up we could really advance scrolling on Uzebox. I volunteer for the work on the sprite rotation, another big issue is can we scroll from the SD card?