Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
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!D3thAdd3r wrote: ↑Sat Dec 16, 2017 8:19 pmWhat?! 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?
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).
- Mode 72 demo with moving sprites
- (41.59 KiB) Downloaded 80 times
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.
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.D3thAdd3r wrote: ↑Sun Dec 17, 2017 10:04 pmRam 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?
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.
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).
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.
Who is online
Users browsing this forum: No registered users and 1 guest