GP32 Sprite Targeting

[solarice]

Hi all,

Ive got yet another question....well two actually :rolleyes:

In my game the player controls a sprite that can move to the left and right while locked to the centre of the screen, and when the emeny reaches a certain position on screen it stops and shoots, at your character or at least it did when i had a static background. Because the player was moving around in front of the background, but as you'll most likly know that with a tile engine the background moves instead of the charater - or at least thats how mine is working.

Now that i have a tile engine the enemy just walks past ignoring you, and ive tried making the enemy sprites shoot command locked to the centre of the screen minus the distance from you character inorder to shoot, but this is only having effect at one place within the game map, so the rest of the time hes just ignoring you.

and my other problem is the enemy is set to increment its position ny 1 every time across the screen, but if you move left they stop moving and if you move right they move twice as fast.



What id like to know is if anyone has any ideas on how to make the enemy shoot at the same distance from you everytime regardless of where in the game map you are. And if youve got any ideas on making the sprite move the same speed whether you going left or right.

Thanks for bothering to read this far, and if you can spread any light on the situation it would be most appreciated.

 

[ColinR]

What you're doing is updating positions in relation to the screen. You don't want to do this - you need to update the positions relative to the map of the level.

If you need to get the enemies to shoot at the character, you'll also need to get them to work out how close the character is from their position (or hack around it with a screen location (as you're already doing)).

 

[ravuya]

For finding the distance between sprites you can always use the distance formula from geometry, despite involing square roots and so on and so forth (computationally intensive), it's usually quite effective.

sqrt((x2-x1)^2 + (y2-y1)^2)

if memory serves.

 

[ColinR]

Pythagoras' Theorem in practice! Who says you never use school mathematics in real life!

Unfortunately, as you say, there's a pair of multiplications and a squareroot there. Nothing you can do about the mults (I don't think), but can the squareroot be removed into an approximate array? You don't need loads of precision, but a simple basic array would need to have up to 160,000 elements that range from 0 to 400 (320K in one array alone!)

This could be further stripped down to binary as in shoot/don't shoot if the enemies' range was fixed.

160,000 bits set to 1 if they're close enough to the player or 0 if they're out of range. 20K.

 

[ravuya]

Heh, and I thought smart optimization had died. Turns out it's just as alive as ever.

I agree, this would be fine for a PC game but a lookup table is probably better for this particular machine, and it wouldn't be that much harder to implement.

 

[ColinR]

I love optimizations. My brother was doing a 3D starfield thing with other objects going on (true 3D starfield that you could go backwards, forwards, pitch, yaw and roll through) and was doing plenty of divides. I'd been playing around with 68K programming at Uni at the time (on a Sparc running a PC emulator, running a 68K emulator - I have no idea why - we had educational Atari ST racks just up the corridor). Specifically I came across Logical Shift Left and LS Right.

How many divides are you doing?
Loads - it's killing the speed...
And mults?
More, but they don't hurt as much.
Okay, check out the >> and << commands (the equivalents of LSL and LSR in C) - they may help...

Sure enough, they did, and he was able to put in more stuff, and sent him down the path of investigating optimizations and he was soon out of my league. He was looking into coding for the GB (way before the GP32 came out) because it was a "current" system, but with limited power, so bedroom programming was feasible on it. Dunno whether anything came of it...

 

[Moogle]

sqrt((x2-x1)^2 + (y2-y1)^2)

To use this you would set a max distance then compare, like:

if(sqrt((x2-x1)^2 + (y2-y1)^2) < 100){
    //shoot!
}

To avoid the root, just quadratize(is that a word) both sides, so you get:

if((x2-x1)^2 + (y2-y1)^2 < 10000){
    //shoot!
}

Lookup tables are fine, but not if there is an easy solution. Bitshifting won't work here I think, certainly not making it easier. To make it faster you could decide it doesn't really matter if the enemy is within a circle around you but settle for a square:

if(abs(x1-x2) < 100 and abs(y1-y2) < 100){
    //Shoot!
}

Hope that helps!

 

[solarice]

:blink:

looking at this:

if(abs(x1-x2) < 100 and abs(y1-y2) < 100){
   //Shoot!
}

i have no idea what it does.......do i get the feeling that because i didnt really learn c or c++ before starting this, that its coming back to bite me.

well i can see that its checking if x1-x2 < 100 and the same for y1-y2 but can you explain what x1,x2,y1,y2 are or would be.

And with it being a side scroller would i need to be checking the x and y or could i just get away with checking one of them as the y axis never changes its always 210px.

once i get this sorted i can jump onto collision detection then its just about done, apart from sound.

thanks again for the help

 

[Charge]

x1 would be the players x co-ordinate.
y1 would be the players y co-ordinate.

x2 would be the enemies x co-ordinate.
y2 would be the enemies y co-ordinate.

the abs function makes a number posative.
So if x1-x2 was a negative distance eg: -12 (somthing that you don't want to work with) abs(x1-x2) would give you 12.

if x1-x2 was a posative distance eg: 12 , abs(x1-x2) would still give you 12.

 

[solarice]

oh i see now, thanks for that. suppose i'll give it a shot then and see if can get this to work.

fingers crossed

nope still doesnt work.....it either stop the enemy sprite and shoots but then when you move the enemy sprite stays put and get dragged along the screen with you, or it only shoots at the position you started at when the game began.....any ideas.....im completely confused.....

 

[Moogle]

Seems like a problem with the relative coordinates(coordinates on the level map). Even when the enemy stops moving make sure you convert its relative coords to screen coords before rendering them(if you move the main vessel the relative coordinates don't change but the screen ones do!).

 

[solarice]

ok im gonna have to ask.....how do i go about this relative coords idea.

i think ive got the enemy sprite to stop and shoot properly, just checking when its moved one tilesize in from left, then stop and shoot.

Its when player moves thats the problem, if you move right, player stays put on screen instead of being fixed to the location on map area it stopped at, if i move left it does the same until it reaches a new tile width and then starts moving again.

so how do i make the sprite fixed to the map, instead of the screen...other code doesnt sem to help.

sorry if i keep repeating aswell as hassling you lot for help

Also anyone got any ideas on my other question?

my other problem is the enemy is set to increment its position +1px every time across the screen, but if you move left they stop moving and if you move right they move twice as fast.

Thanks Again.......

 

[thejuggler]

On your other problem, sounds like you need to make the movement of the people relative to the direction teh ship is moving in

ie.

if (ship.move = right) player.move = speed/2;
else if (ship.move = left) player.move = speed*2

That's possible an overly simplistic response but from what I can see from your demo, it should do what you need.

BTW. Nice work on the graphics. The game is looking very pretty already.