It is currently Tue Jan 16, 2018 8:21 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 21 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Wed Dec 20, 2017 9:27 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10228
Location: Rio de Janeiro - Brazil
I think it's OK to hardcode sprites when you have complete control of what's being displayed... This means that status bars and simpler games like Pong can get away with it, since you'll be managing/avoiding sprite overflows manually.

I personally don't think that avoiding flickering of the player sprite is a good idea, because the player needs to see enemies to plan their moves just as much as they need to see the characters they're playing as. I feel that what's important is that no sprite stays invisible for more than 1 frame, otherwise you may actually lose track of an object's position.

Lazycow wrote:
tokumaru wrote:
Hardcoding objects to OAM is a very bad thing to do, and only absolute beginners will do it.

*couch* *couch* :roll:

No offense intended... Each programmer knows what works for their game. With time, most programmers realize e benefits of separating logic and graphics, but I understand that in the beginning this is not the most straightforward way.


Top
 Profile  
 
PostPosted: Wed Dec 20, 2017 9:40 am 
Offline
User avatar

Joined: Thu Aug 13, 2015 4:40 pm
Posts: 155
Location: Rio de Janeiro - Brazil
tokumaru wrote:
I personally don't think that avoiding flickering of the player sprite is a good idea


That depends on the game really. On a beat em up I'd say it could be a bad idea, but on a platformer with many deadly pits I say it's good. The enemies are not the only source of danger. Not to mention that the flickering saved from the player is spread out on the enemies and items sprites, so it doesn't increase their flicker by that much.

_________________
http://nesrocks.com/blog/superpitfall30th/


Top
 Profile  
 
PostPosted: Wed Dec 20, 2017 10:07 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1203
Location: Gothenburg, Sweden
For instance, take a game like choplifter 2 for the game boy. For the more complex levels, what's important 90% of the time is knowing your exact distance, frame for frame, to a wall within a cave system. I'm not sure choplifter 2 even does that priority (it's been a decade since last i played it), but i'd argue they should've in any case, and i'd argue the same about solar jetman or any game of the type "you touch anything, you loose health" (replace with momentum or even lives in a racer).

In a game with fast / lots of bullets, tracking bullets frame to frame may be of higher priority than tracking enemies.

Then there are sprites which you can decide are safe to place within the lowest possible tier. Floating points from picking up a money bag? Most likely Nonessential. Embers and sparks, smoke, raindrops as pure special fx? Often nonessential, too.

You could probably come up with an algorithm where you sort sprites into ranges and let some be randomized for the OAM at a low-priority range and others at a high-priority range and have them overlap. Or just divide OAM in two or three regions;

-absolutely critical (if any)
-the rest
-absolutely nonessential.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Wed Dec 20, 2017 11:18 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19478
Location: NE Indiana, USA (NTSC)
FrankenGraphics wrote:
In a game with fast / lots of bullets, tracking bullets frame to frame may be of higher priority than tracking enemies.

But then when there are lots of bullets *cough*Touhou*cough*, you might want to draw each bullet only every other frame and let the mind fill in the blanks.


Top
 Profile  
 
PostPosted: Wed Dec 20, 2017 11:23 am 
Offline
User avatar

Joined: Thu Aug 13, 2015 4:40 pm
Posts: 155
Location: Rio de Janeiro - Brazil
Also, if going for the priority regions in OAM make sure the low priority gets at least some of the region that actually gets drawn otherwise it can go completely invisible on too busy scenes? This is going over my head now.

By the way, back to the game in topic, when he congratulated it I was sure the coins would be background graphics as they are stationary (albeit animated).

_________________
http://nesrocks.com/blog/superpitfall30th/


Top
 Profile  
 
PostPosted: Wed Dec 20, 2017 1:58 pm 
Offline

Joined: Mon May 27, 2013 9:40 am
Posts: 382
tepples wrote:
FrankenGraphics wrote:
In a game with fast / lots of bullets, tracking bullets frame to frame may be of higher priority than tracking enemies.

But then when there are lots of bullets *cough*Touhou*cough*, you might want to draw each bullet only every other frame and let the mind fill in the blanks.


This is what I do, for instance :) For bullets, I draw even indexed bullets on even frames, odd indexed bullets on odd frames. It doesn't look bad, either. Not in this game, of course, there are no bullets :)

This game was coded two years ago now, and the sprite ordering is not the best, but it seems to work, though. This was my first game to cycle sprites using an increment which is prime to the overall amount of sprites so they are sent in a different order each frame.

_________________
http://www.mojontwins.com


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 21 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

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