SpritesMind.Net

I continue my journey ... and I'm stuck.

I have enemy ship on screen how can shoot into player direction. I use the cosFix32 and sinFix32 table (0 .. 1024) like this for my 2D Vector / Velocity in x and y, and add them to enemy position (I use fix32 value for float) :
But I don't know how calculate the angle between the enemy ship and my player, like my example : cosFix32(128) = cosFix32(angle value) = cosFix32(45°) ?

P.S. I know the formula of a rectangle triangle : atan(length oposite side / length adjacent side) or inv tan (...) but I don't know how call atan. And if there is a more optimized version for this calcul.

how to scroll a sprite layer?

I don't think we can scroll the sprite layer. If you want to simulate you need to add the other two plans speed to your sprite.

I don't yet find a way to calculate the angle between two points ...

dub wrote: I don't yet find a way to calculate the angle between two points ...

Unless another member has a better method, check out PuckMove() and PuckCollision() in main.c for Ultra Air Hockey (Retro) for some example code of how to calculate angles between two points and then move a sprite in that direction. TMK, there are no arc-trigonometric functions in SGDK ATM to handle directly finding an angle between two points using right triangle-trig (and if there were, it would have probably been in SGDK's maths.h).

However, there is a rudimentary workaround. Recall that, mathematically, an angle is a dy/dx slope (a change in y direction vs. a change in x direction). Using Calculus 3/Vector Calculus techniques, you can compute a resultant vector "R" between 2 points by the "tip-to-tail" method (I think that's the terminology IIRC); i.e., subtract the x and y components of the source point vector "A" from the destination vector point "B". Do the vector subtraction, and store the x and y components of the resultant vector "R" into a vector variable type. Make a code block that will offset the sprite by the x and y components every frame and update the sprite, so that it will move according to that angle . As for handling speed for the movement, my method does not really handle that. Multiplying the resultant vector "R" by a constant "c" value would make it move "faster", but would make the sprite more likely to clip for collision. Hope that makes sense!

Thank you for vectors, I had not seen that in the doc. I used my 2 variables struct for speed velocity so I can change that.

For calculating vectors, I will not have a velocity speed problem. Maybe I should add a value for distance ratio between two points.

If my two points are close (2,2) - (1,1), the X velocity will be 1 pixel per frame and if it is far (10,2) - (1,1) : the X velocity become 9 pixel per frame ?
So I have bullets with different speed.



I think I need to add a distance for the same speed : velX / distance & velY / distance.

Is possible to adjust the priority draw a sprites between themselves?
sprites[2] atop sprites[1]. And vice versa.

I don't think we can juste change the number of the sprite list when you want but some hardcoder can explain if we can.

For now, I just make a new SPR_init (x, ...) and change the number of the first value.

How to cache an animation of sprite in VDP_RAM ?

Currently you need to upload all tilesets from your SpriteDefinition structure to a specific area in VRAM then use the SPR_setVRAMTileIndex(...) method on the Sprite structure to manually set the current index in VRAM of tile data. If you do that, you then need to update the VRAM index as soon you change the animation frame of your sprite.

default sprite engine sometimes glitches.



For an animation I use SPR setFrame (sprites , num);

In action:
http://s8.hostingkartinok.com/uploads/i ... ff0626.gif

Try to increase the allocated tile in sprite engine, it can help. But indeed i also observed these problems happening sometime and i'm not really sure about what happen. I believe the update can be too slow and start on 1 frame and end during the next one. Problme is that sprite list and tile index can have completely changed in the meantime, leading to that issue. I'm currently rewriting the sprite engine, to improve performance and also fix that kind of problem.

Stef wrote:Try to increase the allocated tile in sprite engine, it can help.

I don't understand how it will help.
location of the sprites in memory is always changing.




is necessary somehow make sprites cache. In order to they are statically stored in the VRAM.

Yeah that is the point of the rewrite
Currently allowing more VRAM can help to avoid longer update due to missed allocation but anyway i believe it will always have glitch in some situations :-/

thanx. it worked!
sprite glitch disappeared.

but now the problem with the background.



I initialize the sprites in the following way
And background:

which address the is necessary to prescribe to background is not corrupted ?
SPR_setVRAMTileIndex (&sprites,[addr ?]);