Calculating current position

[johnon]

Okay, so I'm trying to set up my movement system so that what ends up happening is that I get the current position, calculate the new position, reset position to that position and store the position to a memory register to be altered later.

 

Is there any way at all to calculate the initial position of the player after drawing it and then storing it to a register, unlike in Kirk Israel's tutorial where he sets the current Y position before drawing the player?

 

EDIT: I also wanted to do this for Horizontal position, as well, for use with the code Omegamatrix gave me when I asked for ways to handle movement, but I'm pretty sure I can just use sleep and calculate out the cycles. It'd be sloppy, but it'd work.

Edited April 7, 2010 by johnon

[johnon]

I also need a way to stop a player from going past a certain position without having to do collision detection with another object.

 

As of right now, I have my screen set up in a way that the background color is going to change at the bottom of the screen and the score is going to be shown at that point. When that happens, I've got to figure out some way to manage the score, which will be displayed over this background color change. I don't want the player walking over the background.

[SeaGtGruff]

Is there any way at all to calculate the initial position of the player after drawing it and then storing it to a register, unlike in Kirk Israel's tutorial where he sets the current Y position before drawing the player?

 

EDIT: I also wanted to do this for Horizontal position, as well

You need to set the desired (X,Y) position first, then draw the player at that position. When the player moves, you change the known (X,Y) position accordingly, draw the player at the new position, and repeat (update the position, draw the player there, update the position, draw the player there, etc.).

 

The idea of first drawing the player "somewhere" on the screen, then trying to figure out what position you just drew the player at, is backwards.

 

As for keeping the player from going past some point on the screen without using collision detection, that's just a matter of comparing the new position against the position you don't want to go past. With regard to displaying the score at the bottom of the screen, and wanting to keep the player from wandering into that area, it couldn't happen if you're using the two players to draw the score, because your kernel's drawing routine would have to change at that point to draw the score, and it won't even try to draw one of the players as a ship, enemy, or whatever while the code is specifically drawing the score.

 

But if you draw the score using the playfield (as in Space Invaders, for example), then you might be able to move the player into the score display region if your code is designed to allow that.

 

Michael

[johnon]

You need to set the desired (X,Y) position first, then draw the player at that position. When the player moves, you change the known (X,Y) position accordingly, draw the player at the new position, and repeat (update the position, draw the player there, update the position, draw the player there, etc.).

 

The idea of first drawing the player "somewhere" on the screen, then trying to figure out what position you just drew the player at, is backwards.

Ah, I get it. ^^

 

As for keeping the player from going past some point on the screen without using collision detection, that's just a matter of comparing the new position against the position you don't want to go past. With regard to displaying the score at the bottom of the screen, and wanting to keep the player from wandering into that area, it couldn't happen if you're using the two players to draw the score, because your kernel's drawing routine would have to change at that point to draw the score, and it won't even try to draw one of the players as a ship, enemy, or whatever while the code is specifically drawing the score.

So, effectively, I could just re-route the players from their current use to use as the score, and then back again, granted I get my timing right?

 

But if you draw the score using the playfield (as in Space Invaders, for example), then you might be able to move the player into the score display region if your code is designed to allow that.

I was actually thinking about not doing it that way so that the player can have the enjoyment of standing on their score, haha.

[SeaGtGruff]

As for keeping the player from going past some point on the screen without using collision detection, that's just a matter of comparing the new position against the position you don't want to go past. With regard to displaying the score at the bottom of the screen, and wanting to keep the player from wandering into that area, it couldn't happen if you're using the two players to draw the score, because your kernel's drawing routine would have to change at that point to draw the score, and it won't even try to draw one of the players as a ship, enemy, or whatever while the code is specifically drawing the score.

So, effectively, I could just re-route the players from their current use to use as the score, and then back again, granted I get my timing right?

Yes. The part of the kernel that draws the ship, aliens, monsters, etc. will be loading the graphics from one table or set of tables (wherever you tell it to load from), then the code for the score display will load the graphics for the digits from another set of graphics tables. The only way to draw both "at the same time" would be (1) to use flicker-- draw the ships/aliens/etc. on one frame, then draw the score on the next frame-- or (2) use one player for the score (which would have to be a small score) and the other player for the ship/alien.

 

And now I crash.

 

Michael

Edited April 7, 2010 by SeaGtGruff