Flickering sorted sprites possible?

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

Post Reply
User avatar
Nioreh
Posts: 113
Joined: Sun Jan 22, 2012 11:46 am
Location: Stockholm, Sweden

Flickering sorted sprites possible?

Post by Nioreh » Sat Feb 25, 2012 7:24 am

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?

Denine
Posts: 394
Joined: Wed Feb 17, 2010 5:42 pm

Post by Denine » Sat Feb 25, 2012 7:36 am

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).

User avatar
tokumaru
Posts: 11445
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru » Sat Feb 25, 2012 8:04 am

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?

User avatar
Nioreh
Posts: 113
Joined: Sun Jan 22, 2012 11:46 am
Location: Stockholm, Sweden

Post by Nioreh » Sat Feb 25, 2012 8:11 am

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.

tepples
Posts: 21720
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Sat Feb 25, 2012 8:25 am

Try drawing sprites with X coordinate below 128 first in one frame, then drawing them last in the next frame.

User avatar
tokumaru
Posts: 11445
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru » Sat Feb 25, 2012 8:39 am

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.

User avatar
Nioreh
Posts: 113
Joined: Sun Jan 22, 2012 11:46 am
Location: Stockholm, Sweden

Post by Nioreh » Sat Feb 25, 2012 8:39 am

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.

Drag
Posts: 1275
Joined: Mon Sep 27, 2004 2:57 pm
Contact:

Post by Drag » Sat Feb 25, 2012 9:56 pm

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.

User avatar
Bregalad
Posts: 7752
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Post by Bregalad » Mon Feb 27, 2012 10:03 am

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.
Life is complex: it has both real and imaginary components.

Post Reply