I've seen some discussions on here about which is faster, DRAWSPRITE or POLYVECTOR.
In my current implementation I'm using POLYVECTORs to draw everything since I'm targeting mobile platforms. I do something like this...
SUB begin_poly_draw:
ENDSUB
FUNCTION draw_poly_vector: // some vars passed in...
ENDFUNCTION
SUB end_poly_draw:
ENDSUB
So this way I should have minimal number of OpenGL texture swaps if I understand this correctly...
But now I'm implementing my collision detection... oh how will I do this? (I ask myself). So now I load all of my images from the texture atlas into sprites at init so I can get sprite to sprite collision detection. If I already have created the sprites in memory, now it's not much more effort for me to go ahead and draw sprites directly rather than using POLYVECTORs. So is there any definite answer as to which is faster, specifically in regards to iPhone and Android if it varies on differing platforms?
Thanks!
hi,
for collisions, you're pretty doomed when it comes to polyvector. If your sprites are on a grid, you should be able to load them with LOADANIM instead of loadsprite. That way the ANIMCOLL commands are open to use.
Beware - don't use SPRCOLL/ANIMCOLL in an open STARTPOLY block. It *might* fail or swap textures.
I'll keep in mind not to use sprcoll in my polyvector blocks. What abort my original question though, will polyvector be faster than drawsprite?
If you have all 4 corner points, you can check for all 4 corners of the first sprite if it´s in the second. It´s pretty fast. Here a starting point
//corner(x,y) in sprite(x1,y1 ... x4,y4)
IF ((y - y1) * (x2 - x1)) - ((x - x1) * (y2 - y1)) <= 0 THEN RETURN FALSE
IF ((y - y2) * (x3 - x2)) - ((x - x2) * (y3 - y2)) <= 0 THEN RETURN FALSE
IF ((y - y3) * (x4 - x3)) - ((x - x3) * (y4 - y3)) <= 0 THEN RETURN FALSE
IF ((y - y4) * (x1 - x4)) - ((x - x4) * (y1 - y4)) <= 0 THEN RETURN FALSE
RETURN TRUE
Quote from: Kitty Hello on 2011-Oct-10
for collisions, you're pretty doomed when it comes to polyvector.
Just to query this, so when a sprite is drawn using POLYVECTOR, we can't use SPRCOLL() to check for a collision?
I've actually just written a routine that does exactly that, except it's checking for a collison between a sprite drawn with POLYVECTOR and a sprite drawn with DRAWSPRITE. And it seems to work, the collison is correctly flagged when they collide. Did this work by luck?
you made your own, using SPRITE2MEM?
Nope, they are simple bitmaps, I used POLYVECTOR in one case as I understand it to be faster.
P.S.
Apologies for hijacking this thread. I would also like to know if POLYVECTOR is faster than DRAWSPRITE.
If I've interpretted Gernot correctly, there might be problems if you put a SPRCOLL command within a STARTPOLY/ENDPOLY block. As long as you haven't done that, it shouldn't matter how you draw them. Regardless if you use POLYVECTORs or DRAWSPRITEs, the images themselves are stored in memory the same way.
Ah I see, yeah, that's the answer I was looking for, thanks Serpent :good:
I didn't even realise you can put non POLYVECTOR statements within the START/ENDPOLY. I imagine it's bad practice to do so (I know the manual states no PRINT or DRAWSPRITE commands).
And yep, I draw one sprite with POLYVECTOR (so I can change it's colour), then another, completely seperately with DRAWSPRITE and then check for collision between the two with SPRCOLL.
With regard to the original question, are POLYVECTORs faster on certain devices, e.g. is it better to use POLVECTORS than say, DRAWSPRITE on an iPhone. I know there's a simple way to find out, but I wonder if anyone has any real world experience with it.