peekchar optimization

[+TwentySixHundred]

Ok guys so im using peekchar to determine walkable maptiles and was thinking the other night there has to be a way to optimize my code a little. Im using 5 points of reference around the player to calculate the surrounding maptiles. That's 3x5 (15) variables at work, well 14 because i reuse 1 of them as the return value would be the same. All 14 are making calculations every frame in the mainloop (feels wasteful).

 

Anyway for example this part of the code is two reference points for each leg a of walkable maptiles. Im reusing the ypos as it never cahnges to save the variable however have two separate variables for the two xpos locations. This had me thinking for all 5 points i dont see why i couldn't use 2 variables in total for calculating the neutral central point of the player then adjust accordingly when checking the ID using peekchar. Stripped down example below.

 dim tileunderLx = var12
 dim tileunderRx = var13
 dim tileundery = var14
 dim tileunderL_ID = var15
 dim tileunderR_ID = var16

mainloop
 blah
 blah
 blah

 tileunderLx=(playerx+4)/8 ; left foot
 tileunderRx=(playerx+12)/8 ; right foot
 tileundery=(playery+32)/16 ; ypos

 tileunderL_ID=peekchar(screendata,tileunderLx,tileundery,20,12) ; tile under left foot
 tileunderR_ID=peekchar(screendata,tileunderRx,tileundery,20,12) ; tile under right foot

 blah
 blah
 blah
 goto mailoop

 

That's all well and good however when i try something like this to eliminate the need of two separate xpos variables i get a bad argument error. For example

 dim tileunderx = var13
 dim tileundery = var14
 dim tileunderL_ID = var15
 dim tileunderR_ID = var16

mainloop
 blah
 blah
 blah

 tileunderx=(playerx+8)/8 ; central location of both 
 tileundery=(playery+32)/16 ; ypos

 tileunderL_ID=peekchar(screendata,(tileunderx-4),tileundery,20,12) ; tile under left foot - offset minus 4
 tileunderR_ID=peekchar(screendata,(tileunderx+4),tileundery,20,12) ; tile under right foot - offset plus 4

 blah
 blah
 blah
 goto mailoop

 

In my head it would make sense to save a boat load of variables and just calculating the central point of the player sprite. Then from here just add or subtract the offset locations when using peekchar to find a tiles ID location. I just feel like im making alot of calculations and wasting resources when the offset value never changes.

 

Cheers -Anthony

 

[RevEng]

Yeah, you can't use complex statements (math in brackets) as statement arguments in 7800basic, which is why you're getting the error.

 

You need to redo the pixel-to-tile division for each point anyway, unless your points are exactly [TILE WIDTH] pixels away from your center point. Adding N to your center point only looks exactly N tiles to the right of the tile your center point occupies, but if your character's toe is located [NON TILE WIDTH] pixels away from the center point, your method can't reliably detect when your character's toe is actually over a tile or not.

 

Honestly this isn't a large number of cycles in the grand scheme of things, and it's premature to worry about it. No reason to waste memory - you can reuse your tileunderx and tileundery variables between the peekchar statements, and just maintain unique tile ID variables. That way you can also use the fact that you have pairs of points on the same Y coordinate to reuse some of the Y pixel-to-tile calculations.

[+TwentySixHundred]

22 minutes ago, RevEng said:

Yeah, you can't use complex statements (math in brackets) as statement arguments in 7800basic, which is why you're getting the error.

 

You need to redo the pixel-to-tile division for each point anyway, unless your points are exactly [TILE WIDTH] pixels away from your center point. Adding N to your center point only looks exactly N tiles to the right of the tile your center point occupies, but if your character's toe is located [NON TILE WIDTH] pixels away from the center point, your method can't reliably detect when your character's toe is actually over a tile or not.

 

Honestly this isn't a large number of cycles in the grand scheme of things, and it's premature to worry about it. No reason to waste memory - you can reuse your tileunderx and tileundery variables between the peekchar statements, and just maintain unique tile ID variables. That way you can also use the fact that you have pairs of points on the same Y coordinate to reuse some of the Y pixel-to-tile calculations.

Thanks for the explanation about complex statements mike ?

 

Yeah im always trying to save RAM and save cycles to take as much load off the main game engine as possible. Probably not really worth worrying too much about saving a few cycles here and there at this point until the game matures.

 

Never thought to reuse the tileunder x and y variables then just maintain the tile ID variables. Makes sense though as they only really need to be temps once i have stored the ID values. Move onto the next then rinse and repeat

 

Might go have a play around with reusing those variables, once again cheers ?

[+TwentySixHundred]

Ok so i went back and reused the xpos and ypos variables which literally took about 2 min to alter the code. Works flawless, saved 7 variables and halved the amount of code from before... It's staring at me clear as day as to why i never thought of this earlier. So simple and elegant im feeling like such a boofhead for even asking the question lol.

 

Anyway atleast i learnt something tonight ?

[RevEng]

You need to be comfortable with the landscape before those kinds of optimisations pop out at you, and yeah, they always seem obvious in retrospect.

[Lavalamp]

Actually this was very timely, solved a problem I had with Morf