It is currently Sun Dec 10, 2017 9:00 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 9 posts ] 
Author Message
PostPosted: Sat Feb 25, 2012 7:24 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 11:46 am
Posts: 78
Location: Stockholm, Sweden
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?


Top
 Profile  
 
 Post subject:
PostPosted: Sat Feb 25, 2012 7:36 am 
Offline

Joined: Wed Feb 17, 2010 5:42 pm
Posts: 359
Location: Denine's Devil Mansion
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).


Top
 Profile  
 
 Post subject:
PostPosted: Sat Feb 25, 2012 8:04 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
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?


Top
 Profile  
 
 Post subject:
PostPosted: Sat Feb 25, 2012 8:11 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 11:46 am
Posts: 78
Location: Stockholm, Sweden
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Feb 25, 2012 8:25 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19322
Location: NE Indiana, USA (NTSC)
Try drawing sprites with X coordinate below 128 first in one frame, then drawing them last in the next frame.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Feb 25, 2012 8:39 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Feb 25, 2012 8:39 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 11:46 am
Posts: 78
Location: Stockholm, Sweden
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Feb 25, 2012 9:56 pm 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1248
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.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 27, 2012 10:03 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7312
Location: Chexbres, VD, Switzerland
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: Bing [Bot] and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group