Mode 72 development

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
User avatar
Artcfox
Posts: 946
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Mode 72 development

Post by Artcfox » Sat Dec 16, 2017 9:27 pm

Wow, that is an insane number of sprites!

User avatar
Jubatian
Posts: 1363
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Mode 72 development

Post by Jubatian » Sun Dec 17, 2017 3:24 pm

D3thAdd3r wrote:
Sat Dec 16, 2017 8:19 pm
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?
I completed the demo (sprites now jiggle a little around so it is more apparent that they are indeed distinct), now the source is also available: https://github.com/Jubatian/uzebox/tree ... es/m72demo The repo is up-to-date with Uzebox master, you may check it out and experiment with it!

Yes, basically you need to organize sprites to avoid the scanline limit. The mode has "sprite columns", this represents each "hardware" sprite slot, in the currently completed sprite mode 0, there are 8 of these for normal sprites. Each column is a chained list of sprites which must be Y ordered from top to bottom. Sprites otherwise are completely identical, you can move them around freely, and you may design a distinct multiplexer if you want to which could assign them proper to the sprite columns.

Larger sprite coverage (now it is 8 x 8 pixels normal sprites + 4 bullet pixels) is possible with larger sprites (6 x 12 or 5 x 16) or by having only RAM sprites, later I will add such sprite modes. I might tune sections a little later (I mean linker sections), it is hard to avoid wasting space due to 512 byte alignments, and another constraint is that the ROM sprites must be in the 0x8000 - 0xEFFF range. This wouldn't be a big problem, but it is hard to tell the linker to put the sprites there (without defining custom sections, not something difficult, but another obstacle for the user).
Attachments
m72demo.uze
Mode 72 demo with moving sprites
(41.59 KiB) Downloaded 50 times

User avatar
Artcfox
Posts: 946
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Mode 72 development

Post by Artcfox » Sun Dec 17, 2017 7:00 pm

Can you describe the bullet sprites in relation to the zig zag thing on the screen?

User avatar
Jubatian
Posts: 1363
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Mode 72 development

Post by Jubatian » Sun Dec 17, 2017 8:07 pm

Artcfox wrote:
Sun Dec 17, 2017 7:00 pm
Can you describe the bullet sprites in relation to the zig zag thing on the screen?
That's 128 1px tall bullets. The bullet can be 1-4 px wide, the animation just changes the width. You can look into the example to see: The section from Line 211 in main.c sets it up.

User avatar
D3thAdd3r
Posts: 2422
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Mode 72 development

Post by D3thAdd3r » Sun Dec 17, 2017 10:04 pm

Ram source sprites sure seems interesting...very interesting for potential streaming. What would the ram usage look like for this versus mode 3? I usually have (38*64) just for ram tiles, would I be correct to believe you could have nearly 40 unique ram source sprites....and having 40 sprites all with the same tile index, would cost just 64 bytes of graphics storage for those pixels for the reused tile?

User avatar
Artcfox
Posts: 946
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Mode 72 development

Post by Artcfox » Mon Dec 18, 2017 4:57 am

Jubatian wrote:
Sun Dec 17, 2017 8:07 pm
Artcfox wrote:
Sun Dec 17, 2017 7:00 pm
Can you describe the bullet sprites in relation to the zig zag thing on the screen?
That's 128 1px tall bullets. The bullet can be 1-4 px wide, the animation just changes the width. You can look into the example to see: The section from Line 211 in main.c sets it up.
Holy crap! That is an insane number of bullet sprites!

CunningFellow
Posts: 1180
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Mode 72 development

Post by CunningFellow » Mon Dec 18, 2017 6:27 am

touhou project anyone ?

User avatar
Jubatian
Posts: 1363
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Mode 72 development

Post by Jubatian » Mon Dec 18, 2017 6:32 am

D3thAdd3r wrote:
Sun Dec 17, 2017 10:04 pm
Ram source sprites sure seems interesting...very interesting for potential streaming. What would the ram usage look like for this versus mode 3? I usually have (38*64) just for ram tiles, would I be correct to believe you could have nearly 40 unique ram source sprites....and having 40 sprites all with the same tile index, would cost just 64 bytes of graphics storage for those pixels for the reused tile?
The sprites are 2bpp (different bit depts would be possible, see below). In this sprite mode you can have 64 pixels of horizontal sprite coverage (8x8), a rectangular surface (1.5:1 Pixel Aspect Ratio) would be 64 x 96 pixels. It takes 1.5K RAM (1536 bytes) to fill that. Moreover you can X mirror sprites, so for a symmetric image, you would require only half as much.

In other modes different horizontal coverages are possible. If I aimed for max coverage with RAM only and other limitations (targeting especially a capability to just have a big floating 3 color + transparency box), I think even 112 pixels might be possible.

Other bit depths:
  • I chose 2bpp since it is usually the best trade-off for translating byte data to pixels by code blocks. And it fits well with some old 8 bit micros (such as the C64).
  • 1bpp is also possible, but would be more costly in ROM. Of course it would have more coverage, might be interesting for some minimalistic themes.
  • 5 colors + transparency is an odd solution, but that means encoding 3 pixels in one byte (6 * 6 * 6 = 216). Coverage would usually be 3/4 of the 2bpp mode (like you would have 6px wide sprites instead of 8px), but in some sprite modes it might allow an extra sprite.
  • 4bpp is possible, but coverage would likely be only about 2/3 of the 2bpp mode.

User avatar
Jubatian
Posts: 1363
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Mode 72 development

Post by Jubatian » Mon Dec 18, 2017 6:39 am

CunningFellow wrote:
Mon Dec 18, 2017 6:27 am
touhou project anyone ?
Just pay attention to the scanline limit when designing, and then likely it is pretty much possible to get a real "bullet hell" impression with this! (Most likely a vertical shooter would work best as there enemies come from the top, bullets also from the top. You can easily time them right, for example in the 6 main sprite + 5 bullet configuration, so neither enemies or bullets line up to go beyond the limit).

User avatar
Jubatian
Posts: 1363
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Mode 72 development

Post by Jubatian » Tue Dec 19, 2017 8:40 pm

D3thAdd3r wrote:
Sun Dec 17, 2017 10:04 pm
Ram source sprites sure seems interesting...very interesting for potential streaming. (...)
I added a new sprite mode with 16px wide sprites of which you can have 5 on a scanline (so 80px coverage). Otherwise the mode is similar to the 8px wide sprite mode in features, it could be more useful if you want large sprites anyway (with 4 sprites enabled it has 4 bullets contrary to sprite mode 0 where you would have only 1 bullet if you made wider sprites out of 2 normal sprites).

You can enable multiple sprite modes if you want to switch between them (they are much smaller than those of the original Mode 72).

I will of course add further sprite modes soon.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests