It is currently Thu Dec 14, 2017 8:20 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 2 posts ] 
Author Message
PostPosted: Thu Apr 09, 2015 11:57 pm 
Offline
User avatar

Joined: Sat May 31, 2014 4:12 pm
Posts: 140
I am an intermediate level NES programmer and I am just now starting to build my first project involving playable characters. I have been pondering strategies as to how to optimally construct a character out of sprites. I am aware every scenario is different but I am just curious everybody's thoughts and conventional strategies. This is the one I am currently building:

Each pic of a character has an ID. The ID takes me to an indirect address that has info that builds one specific image of the character. The subroutine is called that tells the computer to start building character # n (what ever that may be) and it constructs that character. The character has info involving whether they are facing right or left, y-pos, x-pos. In the early non-looping portion, two palettes are set. Each sprite should have access to palette selections but to save on space, I have my character data coded so it switches to another palette and continues assigning those to the following sprites that are being defined one after another. This makes it so the data stream has doesn't have to keep repeating the same number over and over.

Also, what are some conventions you have about buffers? Do you always reserve the same data region? What are your strategies. I haven't thought about mine yet.


Top
 Profile  
 
PostPosted: Fri Apr 10, 2015 6:48 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
This is what we call a metasprite system. This is basically a routine that looks into an object's state RAM to get its position, the direction it's facing and a pointer to a metasprite definition, and uses that info to build the set of sprites that will represent the current state of that object. Another important task this routine usually performs is the conversion of the object's coordinates from level space to screen space (by subtracting the camera's coordinates from the object's coordinates).

The actual format for the metasprite definitions can vary a lot. Personally, I use 4 bytes per sprite, just like the final OAM entries, with the difference that coordinates are relative to the center of the object (-128 to 127) and that the palette and flipping bits can be affected by the object's state. Flipping is obviously more complicated than just using the flip bits, since you have to mirror all the sprite positions.

Other people prefer more compact (and less versatile) formats, where sprites are arranged in a grid pattern so there's no need to specify the coordinates of every sprite.

Some formats use control codes/flags to be both compact and versatile, allowing coordinates and attributes to be changed only when necessary, which sounds more like what you want to do. The fact that there are a few free bits in the attribute byte could help, since you could use them for custom purposes.

raydempsey wrote:
Also, what are some conventions you have about buffers? Do you always reserve the same data region? What are your strategies.

Are you talking about the OAM buffer? Rendering sprites to hardcoded positions is a bad move, because it increases the chances of sprites disappearing (instead of flickering). There are several strategies for cycling sprites, each with their advantages and disadvantages.

One that's very effective, but doesn't allow layering (you can't guarantee that a sprite will be in front of another), is to start outputting sprites to a random location in the OAM buffer and increment the position by an odd number like 17 (17 * 4 = 68 bytes), letting it wrap around. This will cause sprites to be completely scrambled, always switching priorities from one frame to the next.

For me, layering is important, so I randomize the order in which I draw entire objects (to maintain sprite priorities within the same object) and I have virtual sprite planes, meaning that sprites can be output to either end of the OAM, depending on the "layer" they're in. This makes it possible to place explosions and such always in front of other sprites. These high priority sprites should be kept to a minimum though, otherwise they's quickly make the low priority ones disappear.


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

All times are UTC - 7 hours


Who is online

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