Theorical question about the sprites

SGDK only sub forum

Moderator: Stef

dub
Very interested
Posts: 101
Joined: Thu Mar 19, 2015 1:26 pm

Re: Theorical question about the sprites

Post by dub » Fri Dec 25, 2015 5:13 pm

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) :

Code: Select all

gameObject[i].speedX2 = cosFix32(128);
gameObject[i].speedY2 = sinFix32(128);
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.

alko
Very interested
Posts: 172
Joined: Thu Aug 07, 2014 9:31 am
Location: Russian Federation

Re: Theorical question about the sprites

Post by alko » Sat Dec 26, 2015 4:05 pm

how to scroll a sprite layer?
Image

dub
Very interested
Posts: 101
Joined: Thu Mar 19, 2015 1:26 pm

Re: Theorical question about the sprites

Post by dub » Sat Dec 26, 2015 5:23 pm

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 ... :mrgreen:

MrTamk1s
Very interested
Posts: 75
Joined: Sun Jan 04, 2015 10:27 pm
Location: Pennsylvania
Contact:

Re: Theorical question about the sprites

Post by MrTamk1s » Sat Dec 26, 2015 6:45 pm

dub wrote: I don't yet find a way to calculate the angle between two points ... :mrgreen:
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!
Vector.png
Tip-to-tail vector subtraction
Vector.png (2.3 KiB) Viewed 8979 times
SGDK homebrew dev and Unity3D Indie dev.
Sega does what Nintendont!

dub
Very interested
Posts: 101
Joined: Thu Mar 19, 2015 1:26 pm

Re: Theorical question about the sprites

Post by dub » Sun Dec 27, 2015 8:38 am

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.

Image

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

alko
Very interested
Posts: 172
Joined: Thu Aug 07, 2014 9:31 am
Location: Russian Federation

Re: Theorical question about the sprites

Post by alko » Sun Dec 27, 2015 9:00 am

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

dub
Very interested
Posts: 101
Joined: Thu Mar 19, 2015 1:26 pm

Re: Theorical question about the sprites

Post by dub » Sun Dec 27, 2015 10:51 am

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.

alko
Very interested
Posts: 172
Joined: Thu Aug 07, 2014 9:31 am
Location: Russian Federation

Re: Theorical question about the sprites

Post by alko » Mon Feb 15, 2016 7:38 am

How to cache an animation of sprite in VDP_RAM ?
Image

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: Theorical question about the sprites

Post by Stef » Mon Feb 15, 2016 11:25 am

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.

alko
Very interested
Posts: 172
Joined: Thu Aug 07, 2014 9:31 am
Location: Russian Federation

Re: Theorical question about the sprites

Post by alko » Tue Feb 16, 2016 7:32 pm

default sprite engine sometimes glitches.

Image

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

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

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: Theorical question about the sprites

Post by Stef » Tue Feb 16, 2016 7:59 pm

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.

alko
Very interested
Posts: 172
Joined: Thu Aug 07, 2014 9:31 am
Location: Russian Federation

Re: Theorical question about the sprites

Post by alko » Wed Feb 17, 2016 5:53 pm

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.

Image


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

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: Theorical question about the sprites

Post by Stef » Wed Feb 17, 2016 9:34 pm

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 :-/

alko
Very interested
Posts: 172
Joined: Thu Aug 07, 2014 9:31 am
Location: Russian Federation

Re: Theorical question about the sprites

Post by alko » Sat Feb 20, 2016 7:11 pm

thanx. it worked! :o
sprite glitch disappeared.

but now the problem with the background.

Image

I initialize the sprites in the following way

Code: Select all

     for(i=1; i<8; i++)
        {
            SPR_setVRAMTileIndex	(&sprites[i],30000+i); 

            coord[i].dy=random()%3+1;
            coord[i].x=i*50-48;
            coord[i].y=10;
            SPR_initSprite(&sprites[i], &spider1,  coord[i].x,  coord[i].y, TILE_ATTR(PAL1, TRUE, FALSE, FALSE));
        }
And background:

Code: Select all

        VDP_setPalette(PAL0, rebrol.palette->data);
        ind = TILE_USERINDEX;
        VDP_clearPlan	(VDP_PLAN_A,1);
        VDP_clearPlan	(VDP_PLAN_B,1);

        Map *map1;
        Map *map2;
        u16 ind1= ind ;
        VDP_loadTileSet(rebrol.tileset, ind, TRUE);
        map1 = unpackMap(rebrol.map, NULL);
        ind += rebrol.tileset->numTile;
        u16 ind2 = ind ;
        VDP_loadTileSet(rebror.tileset, ind, TRUE);
        map2 = unpackMap(rebror.map, NULL);
        ind += rebror.tileset->numTile;

        VDP_setMap(VDP_PLAN_B, map1, TILE_ATTR_FULL(PAL0, FALSE, FALSE, FALSE, ind1), 14,0 );
        VDP_setMap(VDP_PLAN_B, map1, TILE_ATTR_FULL(PAL0, FALSE, FALSE, FALSE, ind1), 33,0 );
        VDP_setMap(VDP_PLAN_A, map2, TILE_ATTR_FULL(PAL0, FALSE, FALSE, FALSE, ind2), 0,0 );
        VDP_setMap(VDP_PLAN_A, map1, TILE_ATTR_FULL(PAL0, FALSE, FALSE, FALSE, ind1), 28,0 );

Image

alko
Very interested
Posts: 172
Joined: Thu Aug 07, 2014 9:31 am
Location: Russian Federation

Re: Theorical question about the sprites

Post by alko » Mon Feb 22, 2016 12:17 pm

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

Post Reply