nesdev.org

This morning I had the idea of programming my own little dynamic animation engine that allows up to 48 16x16 sprites to be animated at 60 fps directly from the cart without the v-ram limitations.

Sure 48 sprites isn't the max amount of sprites the Snes can display, but I'm limiting the amount to 48 sprites due to the 6460 byte dma limit.

48*16*16*4/8=6144
170*38=6460

To eliminate overhead during v-blank, the sprites patterns will be copied onto a pattern table buffer, and the 6k pattern table will be dma to v-ram during v-blank at once.

Do whatever is best for your particular game design. I would be careful about trying to use every last potential piece of VBLANK time. You may want a slight margin for error. I'm guessing you've considered what other things need VBLANK time besides the actual transfer time for DMA?

MottZilla wrote:I would be careful about trying to use every last potential piece of VBLANK time.

I'd say not trying to use all the VBLANK time you got would be a waste.
What I usually do is to set up a dma queue that tries to upload as much as possible during blanking, but check how much time is left after each transfer, and postpone the remaining queued transfers if a certain threshold is exceeded.

Also, it's quite common to enter blanking early or exit blanking late, but not everybody is fond of that.
The trade-off here being screen size vs. amount of vram writes per frame, of course.

Unfortunately my game has more than 48 sprites onscreen already.

Keep commonly used sprite cels (such as projectiles and identical-looking enemies) in VRAM for a longer period of time, and devote only a portion of VRAM to demand-loaded sprite cels.

Which is better?

first 6k dynamic
last 10k standard

or

first 4k dynamic
last 12k standard

d4s wrote:

MottZilla wrote:I would be careful about trying to use every last potential piece of VBLANK time.

I'd say not trying to use all the VBLANK time you got would be a waste.
What I usually do is to set up a dma queue that tries to upload as much as possible during blanking, but check how much time is left after each transfer, and postpone the remaining queued transfers if a certain threshold is exceeded.

Also, it's quite common to enter blanking early or exit blanking late, but not everybody is fond of that.
The trade-off here being screen size vs. amount of vram writes per frame, of course.

While I agree you don't want to waste it, but you certainly don't want to push too far. I'm not saying let some huge amount of time go, but I'm saying you should give yourself a small bit of breathing room. For example rather than trying to use 100% of your VBLANK time doing whatever, save a tiny bit, maybe 1% or 0.5% of time as just a small buffer.

But it all boils down to what you need in your particular game. Some games are very simple and wouldn't need many of the features of the SNES at all. Others push the SNES much harder.

I think this topic in general is about what I recall being a relatively low amount of memory available for sprites and how to get the most out of it. For player characters like Player 1&2, which in 1v1 fighting games works as well, it's easy to DMA required tiles for each frame as needed. But it gets harder for the duplicate enemys and other objects. For example Metal Slug has the green soldiers with tons of animation frames. The SNES could easily handle 1 of those soldiers by DMAing the needed frame in. And I guess what you are thinking is doing the same thing but for a much larger size of characters. If you get it to work that's great for ultra smooth animation that is possible.

It'll be interesting to see what results you come up with. Particularly if you do try to push it to the limit, seeing just how many fully animated objects you can have moving around.

Without seeing a complete mock-up of your game in motion, it's hard to say in advance how to split it up. You could allocate space for a bunch of different tiers of sprite cels:

• Things that get reloaded every frame or every two frames (player character sprite)
• Things that get reloaded on player's demand (weapon projectiles; pause menu components; HUD indicators)
• Things that get reloaded when a particular kind of sprite enters the camera (a squad of identical mooks)
• Things that get reloaded per level (common projectiles; level-specific particles; more static HUD items such as score markers)

I just noticed something I overlooked. 6k dynamic sprites wouldn't work with 128 oam sprite entries. It would work with 48 oam sprite entries, but not 128. I guess I'm going with 5k so I can dma the entire oam and still have time for scrolling and other stuff like that.

At first using 30 fps animation instead of 60 fps seems like it would be a good solution since 30 fps looks almost as good as 60 fps and takes half the bandwidth, but 30 fps causes implementation problems. Let's say one enemy takes up sprites 12-15 and the next enemy takes up sprites 16-19. On the second frame of the frame pair, the first enemy dies, and the second enemy gets bumped down to sprites 12-15. For 1/60 second, enemy #2 has the wrong frame.

psycopathicteen wrote:At first using 30 fps animation instead of 60 fps seems like it would be a good solution since 30 fps looks almost as good as 60 fps and takes half the bandwidth, but 30 fps causes implementation problems. Let's say one enemy takes up sprites 12-15 and the next enemy takes up sprites 16-19. On the second frame of the frame pair, the first enemy dies, and the second enemy gets bumped down to sprites 12-15. For 1/60 second, enemy #2 has the wrong frame.

Don't bump them down just because a cel slot has opened. Instead, mark the slot as unused and ready to allocate to another actor.

tepples wrote:Don't bump them down just because a cel slot has opened. Instead, mark the slot as unused and ready to allocate to another actor.

You can use linked lists to keep track of used and unused slots.

I have a better idea. Only spawn and kill enemies on even frames. On even frames, upload first 5kB of patterns to backbuffer. On odd frames, upload second 5kB of patterns to backbuffer and switch buffers. Since this method causes the pattern table to lag 1 frame behind the oam, I will program a 1 frame delay for the oam to match the pattern table.

Just so you know, I'm not just making this dynamic animation engine for my own game, I encourage other people to play around with it, and see what other people could do with it. I'll post the source code when I'm ready, and I expect others to implement it in their own game engine. It will make me happy to see newcombers at homebrewing, being capable of producing animation better than released titles, right from the start.

Unlike other tricks like Mode-7 and transperancy that are impressive once or twice but lose their novelty, animation will always be impressive because it's an art form. When you see, for example, a transparent cloud doing an waving effects, it's just the waving effect that is impressive, not the game as a whole. When a game has consistantly high animation, it's not impressive because one specific thing is, the game is impressive overall.

That's just my theory of why I beleive animation is important. It's also why I admire Joakim Sandberg's indie games. Everytime I play one of his indie games I can't resist thinking to myself, "wouldn't it be nice if Super Nintendo games really looked like that!" It would also be cool if we can get Joakim to join the Snes homebrew scene.

psycopathicteen wrote: Unlike other tricks like Mode-7 and transperancy that are impressive once or twice but lose their novelty, animation will always be impressive because it's an art form. When you see, for example, a transparent cloud doing an waving effects, it's just the waving effect that is impressive, not the game as a whole. When a game has consistantly high animation, it's not impressive because one specific thing is, the game is impressive overall.

I'd say it's no different, actually. Animation is just a piece of the game, and impressive animation doesn't make a game impressive overall, just as a fancy effect doesn't. "It's just the animation that's impressive, not the game as a whole," is as valid a statement as, "It's just the waving effect that is impressive, not the game as a whole".

Don't get me wrong, I love 2d animation and if your animation engine allows people to make their games better that's awesome. I'm just saying there are beautiful games out there that don't play very well are aren't super engaging.

I honestly find the vast majority of Snes games to be neither impressive nor fun. The old "it doesn't matter what it looks like, just as long as it plays good" statement doesn't help. It could've been a lot better than it was, and this is why I got into homebrewing.