Author |
Message |
|
hotdog1234
Advanced Member
Joined: 14 Aug 2009 Posts: 291
|
Posted: 21 Mar 2010 02:13:01 am Post subject: |
|
|
I'm attempting to display a sprite on screen only if the sprite falls within the clipping range, meaning the sprite is not entirely off screen. Assume the 32 x 32 sprite is displayed at x = 0. The person moves the area to a new X position, de. So hl = x - de. If the player's x position falls within l=-32 and l=95, the calculator goes on to check the Y position (Check_Y_Coordinate_In_Range). If it fails, the sprite is not displayed (Check_Next_Building). Assume (IX+9) is 32.
Code: ld a, h
or a
jr z, _
cp 255
jr z, Check_X_Negative_Numbers
jp Check_Next_Building
_
ld a,l
or a
jr z, Check_Y_Coordinate_In_Range
cp 96
jp nc, Check_Next_Building
jr Check_Y_Coordinate_In_Range
Check_X_Negative_Numbers:
ld e, (IX+9)
ld a, e
neg
ld e,a
inc e
ld a,l
or a
jr z, Check_Y_Coordinate_In_Range
cp e
jp c, Check_Next_Building
What's a better way to do this?
Last edited by Guest on 21 Mar 2010 02:24:04 am; edited 1 time in total |
|
Back to top |
|
|
thepenguin77
Advanced Newbie
Joined: 17 Jul 2009 Posts: 72
|
Posted: 21 Mar 2010 11:23:28 am Post subject: |
|
|
There's better in two senses: optimize or rethink. I'll assume you mean optimize.
Code: ;sees if hl is less than 96, as negatives are actually higher,
;this goes to yCheck only if it is less than 96
ld de, 96
or a ;just like: cp hl, de
sbc hl, de
add hl, de
jr c, yCheck
;d is already 0, if the negative is lower than -32, this won't carry
ld e, (ix+9)
add hl, de
jr nc, nextBuilding
yCheck:
|
|
Back to top |
|
|
Mapar007
Advanced Member
Joined: 04 Oct 2008 Posts: 365
|
Posted: 23 Mar 2010 11:40:22 am Post subject: |
|
|
The 'assembly in 28 days'-tutorial has a clipping routine for 8x8 sprites, IIRC. Maybe you could rework it for 32x32, using the same underlying logic? |
|
Back to top |
|
|
hotdog1234
Advanced Member
Joined: 14 Aug 2009 Posts: 291
|
Posted: 23 Mar 2010 04:35:34 pm Post subject: |
|
|
Mapar007 wrote: The 'assembly in 28 days'-tutorial has a clipping routine for 8x8 sprites, IIRC. Maybe you could rework it for 32x32, using the same underlying logic?
We're doing any-size sprites, not just 32 x 32 |
|
Back to top |
|
|
FloppusMaximus
Advanced Member
Joined: 22 Aug 2008 Posts: 472
|
Posted: 23 Mar 2010 10:28:25 pm Post subject: |
|
|
Here's a general clipped-sprite routine to get you started. It might, of course, be possible to optimize better if I knew more about your specific case.
You might be able to get a bit of a speed-up by storing your sprites by columns rather than by rows (i.e., a 32x32 sprite would essentially be represented as four separate 8x32 sprites.) You might also be able to get a bit of a speed-up by reserving a column of the screen buffer for a status display (as in Sam Heald's Mario) - this would of course make a huge difference for 8-bit-wide sprites, and less so for larger ones.
If you have a 16-bit number (say, in HL), here's a simple way to check if it's between -128 and 127: Code: ld a,l
add a,a
sbc a,a
cp h (If the number is in signed 8-bit range, then all bits of H must match bit 7 of L.) |
|
Back to top |
|
|
hotdog1234
Advanced Member
Joined: 14 Aug 2009 Posts: 291
|
Posted: 24 Mar 2010 09:42:29 am Post subject: |
|
|
Quote: Here's a general clipped-sprite routine to get you started. It might, of course, be possible to optimize better if I knew more about your specific case.
Dude, I can't tell you how much I appreciate that. That is why it pains me to tell you that we already have a sprite routine with clipping, which is why I didn't mention any specific cases.
The routine in question is actually testing to see if the sprite routine should be run or not. If buildings/structures will not appear on the screen, there is no need to attempt to draw them. But if even one part of a single building appears on screen, the sprite routne should be run. |
|
Back to top |
|
|
tr1p1ea
Elite
Joined: 03 Aug 2003 Posts: 870
|
Posted: 24 Mar 2010 06:12:02 pm Post subject: |
|
|
Will this be just for drawing? Or will you not be updating/processing objects if they are offscreen?
Depending on your clipped sprite routine it should already take care of this (it should early exit if completely offscreen). |
|
Back to top |
|
|
hotdog1234
Advanced Member
Joined: 14 Aug 2009 Posts: 291
|
Posted: 24 Mar 2010 06:41:02 pm Post subject: |
|
|
There's some additional processing for selecting objects, yes. So for right now (it could change). checking the buildings coordinates saves this extra processing required, if the building is off-screen.
Last edited by Guest on 24 Mar 2010 06:41:15 pm; edited 1 time in total |
|
Back to top |
|
|
tr1p1ea
Elite
Joined: 03 Aug 2003 Posts: 870
|
Posted: 24 Mar 2010 07:45:08 pm Post subject: |
|
|
Just out of curiosity, what size buildings are you planning on having? are they always 32x32 (i saw you mentioned different size sprites above, but not sure if thats in general, or for buildings as well). |
|
Back to top |
|
|
FloppusMaximus
Advanced Member
Joined: 22 Aug 2008 Posts: 472
|
Posted: 24 Mar 2010 08:25:08 pm Post subject: |
|
|
When you say "selecting objects", are you referring to highlighting, or drawing a box around, the object that the user has chosen? I wouldn't expect that to take a lot of extra work (can the user select more than one object at a time? And even if so, would you ever expect a large number of objects to be selected at once?)
If you have thousands of objects and you're concerned that doing bounds checking for all of them would take a significant amount of time, you may want to think about other strategies for storing your data (e.g., keeping objects fully or partially sorted, or dividing the world into a grid of, say, 128x128-pixel cells.) But I doubt this is necessary; just be sure your loop is well optimized and you'll probably do fine.
Quote: Dude, I can't tell you how much I appreciate that. That is why it pains me to tell you that we already have a sprite routine with clipping, which is why I didn't mention any specific cases. My mistake, I thought that was the issue at hand. And I've had graphics routines on the brain a lot lately for some reason.
Last edited by Guest on 24 Mar 2010 08:32:16 pm; edited 1 time in total |
|
Back to top |
|
|
hotdog1234
Advanced Member
Joined: 14 Aug 2009 Posts: 291
|
Posted: 24 Mar 2010 11:16:37 pm Post subject: |
|
|
tr1p1ea wrote: Just out of curiosity, what size buildings are you planning on having? are they always 32x32 (i saw you mentioned different size sprites above, but not sure if thats in general, or for buildings as well).
We have mostly 32 x 32 and 16 x 16 buildings, but we also have one 16 x 32 building and one 32 x 16 building.
Quote: When you say "selecting objects", are you referring to highlighting, or drawing a box around, the object that the user has chosen? I wouldn't expect that to take a lot of extra work (can the user select more than one object at a time? And even if so, would you ever expect a large number of objects to be selected at once?)
All the addresses of the sprite data is stored. "Selecting" a building, in the case of this routine, involves getting the correct address so that the right building is drawn. This is allowing us to use "objects" rather than just "sprites" |
|
Back to top |
|
|
tr1p1ea
Elite
Joined: 03 Aug 2003 Posts: 870
|
Posted: 25 Mar 2010 06:40:41 pm Post subject: |
|
|
So you step through your objects, test if they are on-screen, if they are you process them, if not you skip them?
Floppy was asking that when you use the term 'selecting' were you referring to 'deciding whether they were on screen from a programming perspetive' or 'when the user is actually playing the game, moving the cursor around to select a building visually on the screen'.
Last edited by Guest on 25 Mar 2010 06:42:33 pm; edited 1 time in total |
|
Back to top |
|
|
hotdog1234
Advanced Member
Joined: 14 Aug 2009 Posts: 291
|
Posted: 25 Mar 2010 07:16:06 pm Post subject: |
|
|
tr1p1ea wrote: So you step through your objects, test if they are on-screen, if they are you process them, if not you skip them?
Floppy was asking that when you use the term 'selecting' were you referring to 'deciding whether they were on screen from a programming perspetive' or 'when the user is actually playing the game, moving the cursor around to select a building visually on the screen'.
To answer the first question, correct. To answer the second question, it's 'selecting' from a "programming perspective" |
|
Back to top |
|
|
FloppusMaximus
Advanced Member
Joined: 22 Aug 2008 Posts: 472
|
Posted: 27 Mar 2010 12:08:03 am Post subject: |
|
|
Hot Dog wrote: To answer the second question, it's 'selecting' from a "programming perspective"
Please clarify. I have no idea what that means. |
|
Back to top |
|
|
Mapar007
Advanced Member
Joined: 04 Oct 2008 Posts: 365
|
Posted: 27 Mar 2010 05:33:54 am Post subject: |
|
|
According to his previous post it means 'getting the correct address in memory of the building to display.' |
|
Back to top |
|
|
|