Mode 72 development

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 72 development

Post by D3thAdd3r »

Jubatian wrote:If you wanted a vertical scroller (or no scrolling at all), it would be possible to drop horizontal scrolling capability for further sprites (tedious, but for a good space shooter, why not?).
That caught my interest. I don't have any project going at the moment, but a space shooter has been on my mind a long time. If I ever randomly start that one(every game I ever did started randomly so it is not an impossibility) I would definitely like to use this at some point.
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Mode 72 development

Post by Jubatian »

Does anybody use this mode?

I discovered a method to have unlimited number of sprites (that is, unlimited vertical multiplexing within each slot), but it drops automatic interlaced alternating display of sprite pairs (horizontal muxing when exhausting sprite limit per scanline), and makes using sprites a little more complex.

This method also makes it possible to port this video mode to an XMega later if anyone came up with an XMega Uzebox plan.

That it makes using sprites a little more complex means that in this scheme you would have sprite lists for each sprite slot in which you would have to list the sprites to display there, Y ordered. The count of sprites within such a list is arbitrary, messing up the order simply causes later sprites to not display (or partially if overlapping with a previous sprite). The current M72 only prioritizes sprites in a (horizontally) muxed pair (so their Y order doesn't matter).

I am tempted to just rewrite the mode for this scheme as it would be a bit more future-proof (due to the possibility of an XMega port).
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Mode 72 development

Post by D3thAdd3r »

I have given strong thought to using it and considered how my graphical resources might be adjusted. For this particular case I am leaning towards Mode 74 now, and just dealing with the flicker of alternating frame rendering for overflow, but not entirely sure still. Unlimited vertical sprites make me want to do a vertical shooter even more though.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Mode 72 development

Post by D3thAdd3r »

You said that a "thinner" screen, with lower cycles per pixel but still the same number of them in the center of the screen, would allow for more sprites. Do you have a rough estimate for the most extreme case of no horizontal scrolling and as thin as is reasonable? I think we have all played those "bullet hell" type arcade shooters, but when we think of what is possible on Uzebox we probably imagine something different than that. It seems though, that it might not be that far from possible. I have had some real fun on these crazy and ridiculous games(Radiant Silvergun=amazing cooperative mutliplayer) and it might be cool to have something approaching that on Uzebox.
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Mode 72 development

Post by Jubatian »

What you can expect with Mode72's approach is that it can process around 250 pixels for a line (with the current bg. generation and 12 or 16 pixels wide 2bpp sprites). No horizontal scrolling would give you possibly about 10 extra pixels (a tile and some scanline processing logic removed). Within some limits, you may trade this off between sprites and background (but it is not possible to make the background wider by going for 9cy / pixel as it would demand interleaving sprite code with bg output. Not impossible, but it would definitely be costly in ROM). The bg. could also be output at 5 cy / pixel rate for a roughly square pixel display, but it would slightly increase the size of the code tiles which make up the bg.

I also have a ROM sprite design, which is capable to do sligthly less sprite content. This could be interesting for smaller games as since both the bg. and the sprites are in ROM this case, you get lots of free RAM (only the VRAM forming the bg. and the sprite descriptors are in RAM then, a sprite descriptor is 8 bytes).

To get a "bullet hell" game, actually you might not need too many sprites horizontally, rather a good capability for vertical muxing. The bullets are small, and designing firing properly, you could avoid having too many of them on a given scanline (lots of games used such an approach since every machine having hardware sprites have horizontal limits, although later of course this limit went higher).

If you especially want a lot of small, featureless bullet sprites (such as a 2px x 3px box which is rectangular at 7cy / pixel), that could work to get you many of them: no ROM or RAM source, so lots of cycles relating to setting up and loading data is saved.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Mode 72 development

Post by D3thAdd3r »

The featureless bullet idea is really good and I want to see how crazy that can get. I do wonder if this mode would work well for something like Storm Force.
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Mode 72 development

Post by Jubatian »

A small progress report.

This mode needs lots of planning, considering the role of every assembler instruction (while I still aim to get it all done in a manner that it would be possible to adjust this mode to work on an XMega). so it isn't easy.

I actually managed to get it a little faster than what is in the repo, no much effect, though. Also I sketched up support for bullet sprites: 1/2 px wide, arbitrary tall. Sprite mode 0 (8px wide RAM sourced 2bpp sprites) now has the following capabilities (unless there is a bug somewhere which would prevent it working once I complete the environment):

X scrolling enabled: 9 main sprites + 0 bullets; 8 main sprites + 2 bullets; 7 main sprites + 5 bullets; 6 main sprites + 7 bullets.
X scrolling disabled: 9 main sprites + 1 bullet; 8 main sprites + 4 bullets; 7 main sprites + 6 bullets; 6 main sprites + 9 bullets.

X scrolling can be turned on / off with a preprocessor directive. Bullets may be turned off with a preprocessor directive (to save the ROM taken by that code if you don't need them). The count of main sprites can be adjusted by a variable (so you can adapt it to your needs if you want screens with different capabilities).

This is of course the horizontal capabilities, this many sprites can share a scanline. Vertically the mode would support any number of sprites (the limit is the RAM, 10 bytes are necessary for a sprite's descriptor). There may be a limit, though since the sprites would have to be Y ordered after setting them, and likely I can only use a sorting algorithm taking cycles proportional to the square of the number of sprites in each group (main or bullet sprites). Merge sort would take a deterministic count * log2(count) time, but that needs work RAM, quicksort isn't deterministic, so it is useless if you want for example to plan for finishing everything in VBlank. Of course this likely only becomes an issue if you wanted a really large amount of sprites in a group (main / bullet), like 40 or so. I will see what I can get when I arrive to that point.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Mode 72 development

Post by D3thAdd3r »

Even besides the bullet game, that is a huge amount of normal sprites allowing..something new we have not seen. Not sure what is best to demonstrate it though. Zombienator 2 could be quick to do.

If you have a general type of game with a short screen of 25, you can likely hit 40 ram tiles in mode 3. That is 2560 bytes and sprites are just 10 bytes here. So by this mode that is 256 sprites which is rather intense. Even to have sprites presorted, you could probably use that for some kind of crazy scene or effect. How do you turn a sprite off, just put it past the width of a scanline?

If you aimed at 256 sprites(not that you could have enough cycles to do something meaningful with them, just that they are available to use 64 in each part), you might just have "sprite quadrants" where the sprite is put into the first open spot for the quadrant it falls in(upper left 0-63, upper right 64-127, etc.). If that quadrant(or whatever size) is full then no more sprites could be put there, even if the mode itself was capable of displaying more...this would likely never happen. When you go to sort the sprites, you have drastically cut down on the amount of comparisons required in the worst case. Each frame you would first need to turn all sprites off, to indicate that slot is free. This is all a wild delusion I will fully enjoy in my imagination, until you inform me of the part that I did not know, which makes it not possible :D
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Mode 72 development

Post by Jubatian »

Need more sprites? Look at this! :)
screenshot5.png
screenshot5.png (15.83 KiB) Viewed 6172 times
I created a new sprite system. It now supports chaining in each sprite column, so you can have any number of sprites on-screen. Also I created support for ROM / RAM sprites (the mode in the demonstration can load sprite data from either ROM or RAM), and "bullet" sprites (the right zigzagging column is a bunch of bullets piled onto each other). So on this screen the mode produces 48 normal sprites and 128 bullets (8 normal sprites and 1 bullet are allowed on one scanline in this config, it can be switched runtime to 6 normal sprites + 5 bullets).

VBlank CPU consumption is of course zero (Mode 72 will just provide this interface, that is, you can chain-list a set of sprites for each column in proper order, it is up to you to write the multiplexer if you need any, often you might not even need any if you design the game levels right for simple allocation).

I updated the Mode 72 branch on my fork, although it is not quite useful yet (it works, but needs cleaning up stuff still from the old M72 concept).
Attachments
m72demo.uze
Mode 72 test
(43.44 KiB) Downloaded 302 times
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Mode 72 development

Post by D3thAdd3r »

What?! I am blown away by what I am seeing in CUzeBox right now. I don't understand what you mean by "sprite chaining" though. I assume you could individually move all those sprites in a sine wave or something, so long as they were always organized to not go over the per scanline limit?

Maybe it is time I start rethinking about doing a space shooter, the time seems right with this beast of a mode available.
Post Reply