This should probably be my last question for VB dev for now, so I’ll stop hijacking the subforum.
The tech scroll says the following about Objects:
Objects, also known as sprites, are graphical elements that can be used to display Characters at arbitrary locations. This contrasts with the Background, which can only display Characters at a fixed, 8-pixel interval. The trade-off is that Objects require more memory per Character, and take longer to draw.
As noted above, objects permit you to display characters at any offset (including up to 7 pixels off the left of the screen- not sure if this applies to the right of the screen, can someone confirm this?), and can overlap each other at any position when drawn, but are limited to single characters.
This means that to create larger sprites, objects need to be combined together at offsets of 8 and moved simultaneously when movement should occur. Animations can also occur by swapping the character index field of the object attribute memory, of the relevant characters at each frame. Do I understand this correct?
This is what confuses me: Compared to drawing backgrounds, drawing objects is slower and requires more ROM space. Even though background tiles can only have tiles placed 8-pixels apart, placing a SINGLE sprite in a background (that is otherwise transparent) at any position on the screen should be trivial by adjusting the screen offsets in the world attributes. Animations can be accomplished by swapping out character memory each frame. For various sprites, worlds can be used to determine priority order. So it seems that individual sprites can be drawn using backgrounds as well, which is less processing intensive, takes less space.
In practice, is there any reason to draw sprites using objects instead of reserving backgrounds, which should be faster, when a limited number of foreground sprites should be displayed? Will drawing 1024 objects set the “draw time exceeded” VIP status?
Lastly, the official development manual has the following to say about object control registers (page 5-9-2):
When 1024 OBJs are displayed in one world and the same values are set in SPT3 and SPT2, the search of the 1024 OBJs is conducted from SPT3 to SPT3(OBJ_END_NUMBER)-1. At that time, the display priority is determined according to the location of SPT3.
This appears to be an edge case/exception to how the object control registers are normally interpreted, but the whole paragraph is confusing to me. If 1024 objects are to be displayed, wouldn’t SPT3 = 1023 and SPT2 = 0. This makes the whole paragraph seem contradictory; SPT3 != SPT2, and SPT3 MUST be 1023.
Seriously, I’m almost comfortable with the hardware. It only took me about 1.5 weeks too! 🙂
cr1901 wrote:
(including up to 7 pixels off the left of the screen- not sure if this applies to the right of the screen, can someone confirm this?)
Yes, and in fact at least 32 pixels off-screen in any direction. The X and Y coordinates are 16-bit anyway, so even larger numbers shouldn’t be a problem.
This means that to create larger sprites, objects need to be combined together at offsets of 8 and moved simultaneously when movement should occur. Animations can also occur by swapping the character index field of the object attribute memory, of the relevant characters at each frame. Do I understand this correct?
Yes.
This is what confuses me: Compared to drawing backgrounds, drawing objects is slower and requires more ROM space.
Why would it require more ROM space? The character format is the same and the last halfword of an object is the same as a BGMap tile. So you can store a sprite as a BGMap and (manually) convert it to objects when displaying it.
Animations can be accomplished by swapping out character memory each frame.
Or changing the world’s MX/MY/MP properties, which is much faster. You just put a sprite sheet on a BGMap.
In practice, is there any reason to draw sprites using objects instead of reserving backgrounds, which should be faster, when a limited number of foreground sprites should be displayed?
Yes, if you need many small sprites, like bullets in a shoot-em-up, or in any situation where you need more sprites than worlds and BGMaps allow.
Will drawing 1024 objects set the “draw time exceeded” VIP status?
I don’t know, test it. 😛
Lastly, the official development manual has the following to say about object control registers (page 5-9-2):
I can’t help you there, but the official manual is full of little errors like that, so that might be an error too.
Seriously, I’m almost comfortable with the hardware. It only took me about 1.5 weeks too! 🙂
That’s great! It took me much longer (and there are still things I haven’t explored yet).
HorvatM wrote:
Yes, and in fact at least 32 pixels off-screen in any direction. The X and Y coordinates are 16-bit anyway, so even larger numbers shouldn’t be a problem.
Probably the VIP just culls the object from further processing at that point.
This is what confuses me: Compared to drawing backgrounds, drawing objects is slower and requires more ROM space.
Why would it require more ROM space? The character format is the same and the last halfword of an object is the same as a BGMap tile. So you can store a sprite as a BGMap and (manually) convert it to objects when displaying it.
Because I don’t read technical manuals carefully :P.
Or changing the world’s MX/MY/MP properties, which is much faster. You just put a sprite sheet on a BGMap.
MUCH better idea :P. Also, swapping chars out probably isn’t a good idea period now that I think about it.
Yes, if you need many small sprites, like bullets in a shoot-em-up, or in any situation where you need more sprites than worlds and BGMaps allow.
Something I wanted to add to this: Objects also have the desirable property that parallax can be added on an object-by-object basis, as opposed to BGs, where all chars get the same parallax value. So OBJs and BGs can also be combined to create sprites. At least VB Wario Land MUST use this technique, because his hands do not have the same parallax value as his body. Unless of course each hand is dedicated to using a single world :P.
Will drawing 1024 objects set the “draw time exceeded” VIP status?
I don’t know, test it. 😛
I’ll report back with some results. Right now, I really could only check whether the “draw time is exceeded”. I’m not at the point yet where I’m comfortable using the VB’s timer to benchmark. I’d also have to predict the time each ISR invocation takes and subtract that from the final time.
I can’t help you there, but the official manual is full of little errors like that, so that might be an error too.
Would not surprise me. On a related note, the GY, MY, and MP value ranges on page 5-13-2 also don’t seem correct (Figure 5-13-1). Why is MP bounded by the value of SCY? And why can GY/MY only take on positive value? I think Nintendo swapped some table entries by accident.
That’s great! It took me much longer (and there are still things I haven’t explored yet).
It’s been going fairly well. This isn’t the first system I’ve attempt to program for. That would go to the Genesis back in late 2012. It went horribly- no thanks in part to that the official Genesis technical manual is VERY terse and full of errors. I then tried the SNES in May 2013 and that took about a month to get up to speed. Also, there are things I’m certainly not comfortable with yet on VB, such as VIP interrupts, LED control registers, and a majority of VSU registers. I’m also having difficulty generating my own music samples and may fall back to classics such as the sine/square/tri/saw for the time being.
TLDR: Each system I learn gets easier, but NOT by much…
