This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Flickering sorted sprites possible?

Flickering sorted sprites possible?
by on (#90502)
Hi

I am making a game with a top down perspective. Players and enemies are sorted by their y coordinate so people can walk behind/in front of each other. I am trying to think of some way to flicker my sprites when doing this, but I feel I've hit a wall. Is it even possible in some smart way?

by on (#90503)
In theory you should shuffle enemy\player slots, so their OAM entries will be randomized, thus player sprite may be in first OAM entry at frame 1(so it'll be drawn as first and visible), but at frame 2 it may be the last(so it'll be ignored when you hit 8 sprite per line limit).

by on (#90504)
Denine, what you described is regular sprite cycling, where it's not possible to have virtual layers of sprites, like Nioreh needs.

I have thought about this in the past, but never came to a decent conclusion. Frontmost sprites will always have higher priority than backmost ones, which as a consequence will always be the ones disappearing.

It would be pretty useless to shuffle only the objects that have the same Y coordinate, because the objects in the back wouldn't benefit at all from it. This would probably have to be done at the object level, not the sprite level.

Any ideas?

by on (#90505)
I was thinking about how to select what enemies to shuffle, but I can't think of a really solid method. I was thinking of selecting ones that are not close to any other ones and swap those. It's just a pain to do it, and objects will still disappear if lots of them are grouped together. It also takes a lot of cpu to do the selection.

Maybe I'll have to work around it in my level design and not have any horizontal corridors and such where enemies can appear.

by on (#90507)
Try drawing sprites with X coordinate below 128 first in one frame, then drawing them last in the next frame.

by on (#90508)
I guess it could go something like this: First you organize the objects that overlap into groups. Then, when it's time to output the objects to OAM, you shuffle stray objects and groups. Stray objects can go anywhere in the OAM, but objects that belong to groups are output from the frontmost one to the backmost one. Individual sprites are not shuffled at all, only objects and groups of objects.

The only bad part about this method is the CPU time it would take to organize the groups. This part of the code would have to be optimized well.

by on (#90509)
Thanks Tepples and Tokumaru. I think I actually found something that works ok now. Here's what I do:

1.Count the number of enemies/players that are close enough on the y axis to interfer with eachother.

2. If this number is greater than the maximum (in my case 4), cycle everything.

This works ok. Normally they won't line up so many enemies at once, and the sorting looks good. If some do, all will cycle and some priorities go bad, but at least they all show up.

by on (#90542)
The only time you need to sort your sprites is when they're visually overlapping each other on the screen.

For example, if you have 8 sprites on the screen, but none of them are overlapping each other, it doesn't matter what order they're drawn in, so you could perform normal OAM cycling (or flickering, whatever you want to call it).

If sprite A and sprite B are overlapping, and sprite B has a Y position greater than sprite A, only then will it matter that sprite B has a higher priority than sprite A. Aside from that, sprite A and sprite B could be drawn in whatever order (with respect to all of the sprites on the screen), as long as B comes before A.

If sprites A, B, C, D, and E are all occupying the same scanlines, but aren't actually overlapping each other, then it doesn't matter if they're sorted or not, so regular sprite flicker would take care of them.



Edit: However, this might be a little hard to implement, because you basically have to perform collision detection on the sprites to figure out if they're overlapping each other (visually) or not. This could just be 1 extra routine in your game's regular collision detection engine though.

by on (#90642)
I have implemented this successfully in my engine for the game I was going to make (and that I haven't progressed on since 3 years), it's nothing complicated, just clever.

I combined two cycling techniques, so that when combined this creates in total 4 different orders that I can cycle between them.

The first technique is trivial, you simply draw metasprites "forward" one frame and "backwards" the other frame. This doesn't allow sprites to have priorities within the metasprite, but you get nothing for nothing. To be as fast as possible I do the forward/backward things in some piece of code that sits in RAM and I just change the instructions, this is faster than doing some kind of tests for EVERY sprite you want to draw.

The second techinque is to sort the metasprites, like you'd do if you wanted them with priorities, but instead of using their full Y coordinate to sort, I use a special sorting algorithm that compares only the top 5 bits. Then if the top 5 bits matches, I alternate the order depending on the frame.

A typical sorting algorithm will start with an entry of unordered object (for example 0,1,2,3....N) then if the object (k+1) have a smaller Y coordinate than object (k) you swap them, so they are drawn in the correct order to the screen.
My amelioration does just swap them only every other frame if the top 5 bits of their Y coordinate are equal.