This I think is really simple but I just wanted to run it by someone to make sure.
An entity postion should be stored in 4 bytes if the entity can scroll off screen correct? x high and low, y high and low.
basically, if it is beyond the right side of the screen ( over 255 )you can add the carry to the x high and say it's 1 screen to the right at FF.
But there is no negative carry I am assuming? so you have to check if x low is greater than the last x low after subtracting which means its negative and you can set the x high to FF or FE? and that we are working under the assumption that anything from 00 to 7e is positive and 80 to FF is negative?
Question about negative numbers
Moderator: Moderators
Re: Question about negative numbers
Yes. Because then you can use the N flag to control flow. BMI and BPL.anything from 00 to 7f is positive and 80 to FF is negative?
And FF is assumed to be -1. For example, an object just off the screen to the left. If it's moving right, eventually it's position will wrap back to 0, on screen.
nesdoug.com -- blog/tutorial on programming for the NES
Re: Question about negative numbers
ahh so there is a negative flag nice.
so for metasprites scrolling offscreen I guess you have to do a caculation for each individual sprite to see if its off screen or not, if its within the sprtie size range so each sprite ( as smoothly as possible ) gets put into the offscreen positions?
so for metasprites scrolling offscreen I guess you have to do a caculation for each individual sprite to see if its off screen or not, if its within the sprtie size range so each sprite ( as smoothly as possible ) gets put into the offscreen positions?
Re: Question about negative numbers
Funny you mention that. I was just working on code that would do just that. Still thinking about it, though.metasprites scrolling offscreen
Especially, large metasprites that just POP on screen instead of smoothly entering the screen is something that bothers me.
nesdoug.com -- blog/tutorial on programming for the NES
Re: Question about negative numbers
In 2's complement, positive or negative is a matter of interpretation. $FF is both 255 and -1. $FFFF is both 65535 and -1. It depends on how you interpret the numbers in each situation.
When you're treating numbers as signed, the highest bit indicates when a number is negative (set = negative, clear = positive). For our convenience, the CPU automatically copies the highest bit of the result of several instructions to the N flag. I don't recommend using the N flag for detecting off-screen sprites though, there's a faster shortcut.
As for controlling the positions of entities on the screen, the normal thing to do is to have one set of (X, Y) coordinates represent the position each entity in the game world, and after translating those coordinates into screen space (a step you can generally skip if your game doesn't scroll) you can calculate the positions of each 8x8 hardware sprite based on that point, and any coordinates > 255 or < 0 (i.e. the high byte is anything other than 0 - this is the shortcut!) indicates that the sprite is off screen and you can skip it.
You may opt to perform an extra check to also eliminate sprites with Y coordinates between 240 and 255 if you really feel like every last sprite will make a difference, but I generally ignore those in favor of a slightly faster metasprite subroutine.
When you're treating numbers as signed, the highest bit indicates when a number is negative (set = negative, clear = positive). For our convenience, the CPU automatically copies the highest bit of the result of several instructions to the N flag. I don't recommend using the N flag for detecting off-screen sprites though, there's a faster shortcut.
As for controlling the positions of entities on the screen, the normal thing to do is to have one set of (X, Y) coordinates represent the position each entity in the game world, and after translating those coordinates into screen space (a step you can generally skip if your game doesn't scroll) you can calculate the positions of each 8x8 hardware sprite based on that point, and any coordinates > 255 or < 0 (i.e. the high byte is anything other than 0 - this is the shortcut!) indicates that the sprite is off screen and you can skip it.
You may opt to perform an extra check to also eliminate sprites with Y coordinates between 240 and 255 if you really feel like every last sprite will make a difference, but I generally ignore those in favor of a slightly faster metasprite subroutine.
Re: Question about negative numbers
neslib has that, oam_meta_spr_clip filters out of screen sprites while still drawing visible ones.
Re: Question about negative numbers
About your code, calima.
In display.sinc
You should have reserved 2 bytes for SPR_XOFF, since you reference SPR_XOFF+1.
It works without issue, because SPR_YOFF is defined immediately below it, and never used.
example.
SPR_XOFF: .res 2
https://github.com/clbr/neslib/blob/master/display.sinc
I'm going to use a modified version of this code in my upcoming game. Thanks for making it open source.
In display.sinc
You should have reserved 2 bytes for SPR_XOFF, since you reference SPR_XOFF+1.
It works without issue, because SPR_YOFF is defined immediately below it, and never used.
example.
SPR_XOFF: .res 2
https://github.com/clbr/neslib/blob/master/display.sinc
I'm going to use a modified version of this code in my upcoming game. Thanks for making it open source.
nesdoug.com -- blog/tutorial on programming for the NES
Re: Question about negative numbers
Yeah so I implemented a smooth meta-sprite scroll offscreen the exact way I mentioned before and it works well.
basically you just check to see in the base entity + size touches the edge of the screen ( basically if x + width or y + height sets the carry ) and if so check each individual sprites to see if it is off screen or not and draw or don't draw accordingly. If its not touching an edge then all entity sprites are either all on or all off.
Also as a note to get completely smooth scrolling you do need to set the mask($2001) correctly for the left side of the screen to mask the spirtes in the first 8 pixels of each line.
basically you just check to see in the base entity + size touches the edge of the screen ( basically if x + width or y + height sets the carry ) and if so check each individual sprites to see if it is off screen or not and draw or don't draw accordingly. If its not touching an edge then all entity sprites are either all on or all off.
Also as a note to get completely smooth scrolling you do need to set the mask($2001) correctly for the left side of the screen to mask the spirtes in the first 8 pixels of each line.
Re: Question about negative numbers
I actual went back last night and greatly simplified the whole thing.
This only works if you align your entities x position to the right most position and not the center.
basically if your enitity's high byte is 0 then draw any sprite that is equal to or greater than your base X postion.
If your if your enitities high byte is FF then draw any sprite that your base X + (sprite X + 8) is greater than 0 ( or just if your sprite x is greater than 0 if your are masking the left 8 pixels)
I also added a hit box calculation to shrink and grow the hit box accordingly,
I am really surpised at what these little ( albiet emulated at this point) cpu/ppu can push out.
This only works if you align your entities x position to the right most position and not the center.
basically if your enitity's high byte is 0 then draw any sprite that is equal to or greater than your base X postion.
If your if your enitities high byte is FF then draw any sprite that your base X + (sprite X + 8) is greater than 0 ( or just if your sprite x is greater than 0 if your are masking the left 8 pixels)
I also added a hit box calculation to shrink and grow the hit box accordingly,
I am really surpised at what these little ( albiet emulated at this point) cpu/ppu can push out.