It is currently Sat Oct 21, 2017 3:36 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 7 posts ] 
Author Message
 Post subject: Cycling layered sprites
PostPosted: Fri Aug 04, 2006 12:36 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10065
Location: Rio de Janeiro - Brazil
I was thinking about sprite cycling the other day, and came to the conclusion that "traditional" sprite cycling methods will not work well with layered sprites. If only one of the layers of a multi-layer sprite is displayed, it will look worse than if none is displayed.

Also, traditional sprite cycling will invert the order of the layers, wich will look really wrong if you actually overlap pixels, as opposed to leaving such pixels transparent. This will also cause trouble when using high-priority sprites to mask low-priority ones (if the mask gets behind the sprite it has no effect).

The thing is I couldn't, so far, come up with a rule that will respect the order in wich layered sprites should be rendered, as well as force both or no layers to be displayed (never only 1).

Has anyone ever figured something like this out? I guess maybe sprite rendering should be object-based instead of sprite-based. That should result in fully displayed, or fully hidden objects. I don't know if this is better than parts of the object flickering (I mean, you can tell where the enemy is, although he might be missing a leg).

I know that making it all object-based will not solve all problems. Sprites will surelly be placed in OAM in the correct layering order, but the objects may still have only part of it's layers disappearing.

What do you think? I think that checking for sprites on the same scanline in software (so that you know in advance what will be displayed or not, and then not render partially displayed objects) would take too much time (checking each object's position, width and layer count to see if the sprite count goes over 8 at any given scanline). I don't think that the sprite overflow flag would be of much use, as it would only be set after an incorrectly displayed object, and you still wouldn't know wich one(s).

Any ideas?


Top
 Profile  
 
 Post subject:
PostPosted: Fri Aug 04, 2006 1:25 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7232
Location: Chexbres, VD, Switzerland
I think it is some sort of limitation.
Either you use advanced sprite cycling routines to cycle sprites randomly making the trick less noticable to the user, but you cannot use layered sprites, or either you use layered sprites but have a lot of restriction in their cycling.
As you noted, object based cycling is another option I use in my game (where sprite order is important, because of top-down graphics with high sprites, i.e. Secret of Mana). You should not do this in the routine that copy sprites to OAM, but in the main routine that shows all player/ennemy sprites to the screen.
Use some kind of sort algorithms to find the order in wich you want to display player/ennemies sprites, and then do the process for each sprites. This should work fine whathever you want to do. Also make sure the last entries gets ignored if the 64 sprites limit is overpassed.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Aug 04, 2006 1:40 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19113
Location: NE Indiana, USA (NTSC)
Capcom's solution as seen in Mega Man: Draw only the player character layered, and draw the player character frontmost.

Konami's solution as seen in Contra: Instead of drawing layers, draw a top half and a bottom half. Also seen in the HKO Kart Fighter and the pirate Super Mario World. May be seen in other games where the artists have also worked on the MSX.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Aug 04, 2006 2:14 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10065
Location: Rio de Janeiro - Brazil
Bregalad wrote:
You should not do this in the routine that copy sprites to OAM, but in the main routine that shows all player/ennemy sprites to the screen.

I agree. If the player is not gonna be displayed, don't even bother with calculating it's position, reading animation tables, etc.

tepples wrote:
Capcom's solution as seen in Mega Man: Draw only the player character layered, and draw the player character frontmost.

Do you mean Mega Man never flickers? I never noticed that. I've been working with this concept, but I figured that a main character that doesn't flicker results in more flickering around him. Later Mega Man games can flicker a lot.

Quote:
Konami's solution as seen in Contra: Instead of drawing layers, draw a top half and a bottom half. Also seen in the HKO Kart Fighter and the pirate Super Mario World.

Doesn't help if you want to do both (layering and halves). I don't think that would be the case for the NES, though. If the "top and bottom halves" thing does not work, you go with layering, but not both.

Quote:
May be seen in other games where the artists have also worked on the MSX.

Well, sprites on MSX1 have only one color, so both techniques are required if you want to produce "NES-like" sprites. Layering is barely an option for most MSX games, as it can only display 4 sprites on a scanline (they can be 16-pixels wide, though, so it's not that bad).


Top
 Profile  
 
 Post subject:
PostPosted: Sat Aug 05, 2006 1:02 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7232
Location: Chexbres, VD, Switzerland
Quote:
I agree. If the player is not gonna be displayed, don't even bother with calculating it's position, reading animation tables, etc.

You have to calculate its position anyway regardless of the display.
I like having the player flicker just like other sprites, because then there is less flicker arround him.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Aug 05, 2006 1:34 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10065
Location: Rio de Janeiro - Brazil
Bregalad wrote:
You have to calculate its position anyway regardless of the display.

I meant it's display position. Of course, you have to know it's position relative to the player, for game logic and stuff, but there is no need to calculate where this object should be on screen, specially where each of the sprites that form it should be. If you know you'll not display the object, just perform game logic on it and nothing else.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Aug 05, 2006 1:39 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7232
Location: Chexbres, VD, Switzerland
Quote:
If you know you'll not display the object, just perform game logic on it and nothing else.

Well, if you KNOW it, this couldn't prevent your game to have flickers and slowdowns, but avoid to have BOTH at the same time, right ?
But I'd have trouble to figure how to KNOW your player isn't gonna to be displayed AT ALL because of other objects on the same scanline with higher priority. The calculation to do this could be slower than just setup the sprite of your player.
However, this is possible and quite easy to KNOW if it is not going to be displayed because the OAM is already full, wich is rather rare, but you can then limit the slowdowns. I think the game I'm coding does pretty much that.

_________________
Life is complex: it has both real and imaginary components.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 6 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