GLBasic forum

Main forum => GLBasic - en => Topic started by: gregbug on 2010-Jan-29

Title: Polyvector advantages....
Post by: gregbug on 2010-Jan-29
Excuse the beginner question ....  ::)
What are the advantages of using PolyVector instead of DrawSprite?
There are advantages in terms of speed? (and if there are ... as you can 'optimize everything to get the maximum speed of drawing?)

Thanks to all who have the time and patience to answer me ...  :P
Title: Re: Polyvector advantages....
Post by: Moru on 2010-Jan-29
With polyvector you can specify the color of all corners which means flashing sprites in different colors, you can stretch in different angles, rotate and do whatever you like to the poor little things, Drawsprite just ... draws a sprite :-)
Title: Re: Polyvector advantages....
Post by: gregbug on 2010-Jan-30
Quote from: Moru on 2010-Jan-29
With polyvector you can specify the color of all corners which means flashing sprites in different colors, you can stretch in different angles, rotate and do whatever you like to the poor little things, Drawsprite just ... draws a sprite :-)

ah ok. thanks Moru!
but how about the speed? polyvector is faster?
Title: Re: Polyvector advantages....
Post by: Moru on 2010-Jan-30
No, polyvector should be slower in most cases but I don't think the difference is big. Should hardly be noticable even with thousands of sprites/polys
Title: Re: Polyvector advantages....
Post by: Kitty Hello on 2010-Feb-01
On the iPhone, a huge polyvector batch can be rendered faster than lots of drawsprite calls.
Title: Re: Polyvector advantages....
Post by: Serge on 2010-Feb-13
Hi,

I am trying to use POLYVECTOR in order to draw a Polygon, but I noted that it is not filled as I expected. I need that the polygon is filled only by inside, but instead, the polygon is filled drawing a triangle from the first edge to the rest of them, so concave polygons are not filled correctly (i.e. when drawing a star, please see my attached image).

I found that there are some algorythms to do it (i.e. scanline algorythm) , but before implement it I would like to know it this is already implemented for GLBasic.

Thanks and regards

Serge
www.tiptapgames.com

[attachment deleted by admin]
Title: Re: Polyvector advantages....
Post by: Ian Price on 2010-Feb-14
Can you not just use a star image texture on a square polyvector? That will produce the same result surely?
Title: Re: Polyvector advantages....
Post by: Serge on 2010-Feb-14
Well, i used the star just an a example of what I am trying to do, in fact I need to be able to draw any irregular polygon and fill it. So,since the polygons will be randomly created I can not use the approach of using images. :(

thanks and regards
Title: Re: Polyvector advantages....
Post by: Kitty Hello on 2010-Feb-15
do a triangle fan, and start with the center point
Title: Re: Polyvector advantages....
Post by: gregbug on 2010-Apr-18
again on polyvector...  =D

I'm trying to optimize my code... to render sprites using polyvector... for iPhone 3GS

using simple polyvector the speed is the same that using Drawsprite... (tested on 250 sprites 32x32 pixel)  :zzz:
using polyvector if i modify the color param the speed or alphamode on my iPhone is very very very slow... (30fps -> 1-2 Fps!!!)  :'(

I tried to use POLYNEWSTRIP and i had an huge speed boost! (solid 60fps) even if i change the color param or alphamode of polyvector...  :good:

now... my questions are:

1. is possible to change the alphamode of a sigle sprite using POLYNEWSTRIP ? ... if i change a sigle alpha value on a sprite all sprite change the alpha value... !

2. why on normal polyvector the color param or alphamode is so slow? (on iPhone) and on POLYNEWSTRIP do not slow ?

thanks!

Gianluca.

Title: Re: Polyvector advantages....
Post by: yaKC on 2010-Apr-22
I'm having trouble understanding how to use PolyVector, I can't seem to see
what coordinates are being given and how to draw a simple oblong sprite :(


from the help file

STARTPOLY 1001 // Bitmap = No.0
  POLYVECTOR   0,   0,  0,  0, RGB(255, 255, 255)
  POLYVECTOR   0, 300,  0, 64, RGB (255, 255, 255)
  POLYVECTOR 300, 300, 64, 64, RGB(255, 255, 255)
  POLYVECTOR 250,  50, 64,  0, RGB(  255, 255,   255)
ENDPOLY

All I would like to be able to do is draw a sprite that is say
160 pixels by 110, but don't know what the above is doing, do
I have to draw a box/square/oblong using triangles as I
thin? It says you have to enter coordinates anti clocwise too..

Would be VERY VERY grateful if someone could help me please :)

sorry, figured it now now :D With not nowing anything about this command and 3D etc I had
the idea that You had to use triangles, which I didn't need, can't belive I was confused hehe :D


Title: Re: Polyvector advantages....
Post by: Kitty Hello on 2010-Apr-23
Quote from: gregbug on 2010-Apr-18
1. is possible to change the alphamode
2. why on normal polyvector the color param or alphamode is so slow?
1. Not, yet. I try to allow that with an ALPHAMODE in between the POLYVECTOR calls.
2. colour pointers are very expensive on OpenGL|ES devices. Use a texture instead wherever applicable.
Title: Re: Polyvector advantages....
Post by: Scott_AW on 2010-Apr-23
I noticed using only colors instead of a texture in 3d and 2d polygons can slow things down on certain systems, which is wierd in a way.  Think it would be possible to have an alternate polyvector and x_objaddvertex with an alpha flag?  I know from working with Direct X in Game Maker I was able to setup polygons with alpha values to create some nice effects like gradual opacity from transparent.
Title: Re: Polyvector advantages....
Post by: gregbug on 2010-Apr-23
please... please... add polyvector with alpha!!!!  =D
i need it in my sprite lib (iPhone) that use polyvector and POLYNEWSTRIP

thanks!.
Title: Re: Polyvector advantages....
Post by: Moru on 2010-Apr-23
If possible I too would love to be able to set alpha per polyvector point instead, that would be very nice.
Title: Re: Polyvector advantages....
Post by: Kyo on 2010-Apr-23
QuoteKitty Hello
1. Not, yet. I try to allow that with an ALPHAMODE in between the POLYVECTOR calls.


Great News  :good:
Title: Re: Polyvector advantages....
Post by: monono on 2010-Apr-23
A different alpha within the polyvector definition works for me. I always change alphamode after newgroup. But it doesnÃ,´t works in the full range from -1 to 1. Just -1 to 0 and 0 to1 within the same polyvec.

My pros and cons to the opening question:

Pros
Cons
Title: Re: Polyvector advantages....
Post by: Kyo on 2010-Apr-23
Quote from: monono on 2010-Apr-23
A different alpha within the polyvector definition works for me. I always change alphamode after newgroup. But it doesnÃ,´t works in the full range from -1 to 1. Just -1 to 0 and 0 to1 within the same polyvec.

My pros and cons to the opening question:

Pros

  • I can have all the spritegraphics on one huge texture and just change the texture coords per polynewgroup
  • There is still hope it is faster.
  • You canÃ,´t deform-scale and rotate at the same time with the sprite commands.
Cons

  • The far I know there is no pixelperfect collusion using polyvecs !....???

you use:

Code (glbasic) Select


STARTPOLY 0,2

ALPHAMODE -.4

LOCAL c%=RGB(255,255,255)
POLYVECTOR  0, 0, 0,0,c
POLYVECTOR  0,40, 0,0,c
POLYVECTOR 40,20, 0,0,c
POLYVECTOR 40,40, 0,0,c

POLYNEWSTRIP

ALPHAMODE 0

// same at 100,100
POLYVECTOR 100,100, 0,0,c
POLYVECTOR 100,140, 0,0,c
POLYVECTOR 140,120, 0,0,c
POLYVECTOR 140,140, 0,0,c

ENDPOLY


and it works?
Title: Re: Polyvector advantages....
Post by: Scott_AW on 2010-Apr-23
[qoute]
[/quote]

You can still compare the sprites against each other but it won't include deformations or rotations.  If you are simply drawing with polyvector, to scale, you can use sprcoll to comapre the sprites without having to draw them.
Title: Re: Polyvector advantages....
Post by: monono on 2010-Apr-23
Quoteand it works?
Yes ... but not exactly.
Try -.1 for the second alphamode. 0 seems to disturb the other alpha settings. The problem with the range (blendingmodes) I descriped earlier doesnÃ,´t show up any more. In the code where it happend there were a few hundred polystrips. IÃ,´ll try to reproduce what I did.

@Scott: thanks for your thoughts, but I dont know exactly how to do that. I donÃ,´t draw one polyvector for one sprite. I do draw nearly all sprites with one polyvector. ThatÃ,´s why I canÃ,´t use sprcoll with the image source. ItÃ,´s one big image, with all single graphics together, splitted up all over my polyvector. Can you pls explain what you mean in code. (I hope gregbug is satisfied and this is not too off-topic)
Title: Re: Polyvector advantages....
Post by: gregbug on 2010-Apr-24
Quote from: monono on 2010-Apr-23
Quoteand it works?
@Scott: thanks for your thoughts, but I dont know exactly how to do that. I donÃ,´t draw one polyvector for one sprite. I do draw nearly all sprites with one polyvector. ThatÃ,´s why I canÃ,´t use sprcoll with the image source. ItÃ,´s one big image, with all single graphics together, splitted up all over my polyvector. Can you pls explain what you mean in code. (I hope gregbug is satisfied and this is not too off-topic)

Thanks to all for the explanations!

@Monono I use the same technique to draw my sprites ... (One big texture) (I try to squeeze more fps from my iPhone)
for the collision I have implemented (or rather trying to implement) bbc technique (Bounding box collision) and for the sprites that are rotated OBBC (oriented bounding box collision)

for perfect pixel collision I do not know how to implement them! any suggestions?  (Scott_AW?) =D
Title: Re: Polyvector advantages....
Post by: Scott_AW on 2010-Apr-24
Well it wouldn't work with one big texture holding all the individual sprites, you'd have to have them as individuals to do the checking.  What you could do is keep your sprite based on tile maps and make individual ones that are simple black & white masks.

I've been using CONSTANTs to flag my image starter indexes since I use individual sprites, you can use this to match up to the tilemap with the masks sprites.  To save time but not processing you can have this done on loading.

Assuming you're using a tile/sprite map that has both rows and columns, here is a snip that should convert tilemap to masks.  Just don't use black as a transparent color though.  I wrote it in notepad, so I can only guess if it works.

Code (glbasic) Select

  //Generate masks...
  constant tileimage = # //Set the tilemap image index lower than the masks...
  constant tilemask = #  //Set the masks' index start
  constant tilewidth = ##
  constant tileheight = ##
  constant tilecount = ## //row*col
  constant tilecolcnt = ## //how many columns per row...
 
  loadsprite "image.bmp", tileimage

  local count = 0, x = 0, y = 0
  clearscreen rgb(244,0,244)  //Use your transparent color
  for count = 0 < tilecount
    if count < tilecolcnt
      x = count * tilewidth
    else
      local adjust
      adjust = integer(count / tilecolcnt)
      x = count - (tilecolcnt * count) * tilewidth
      y = adjust * tileheight
    endif
    //Make mask
    startpoly tileimage, 0
      polyvector x, y, x, y, rgb(0,0,0)
      polyvector x, y + tileheight, x, y + tileheight, rgb(0,0,0)
      polyvector x + tilewidth, y + tileheight, x + tilewidth, y + tileheight, rgb(0,0,0)
      polyvector x + tilewidth, y, x + tilewidth, y, rgb(0,0,0)
    endpoly
    //Capture
    grabsprite tilemask + count, 0, 0, tilewidth, tileheight
  next


After you have your masks, assuming you have your sprite positions on the tile map stored you can then matchup that sprite to the correct mask.  Since this method creates a 1d list of indexs and you may be using a 2d list of images, X & Y, you just multiply the x and y values to achieve the index.  If your X & Y values are actual positions on the tilemap, then (x/tilewidth) * (y/tilewidth) to produce the index.  A 1d index that just has X positions for the tiles would just have to be (x/tilewidth).  You can choose to use integer() on them, but if your tile size is constant it shouldn't be needed.
Title: Re: Polyvector advantages....
Post by: Moru on 2010-Apr-24
You can also store the mask-data as animation sheets if your sprites are all the same size. Load them with:

LOADANIM

Specifying the size of the single sprites. Then use:

ANIMCOLL

To test for collisions. Animcoll keeps track of the index into the sprite array so you don't have to do it yourself.

This ofcourse won't work if you have different sizes of sprites all over the place like some of you have :-)
Title: Re: Polyvector advantages....
Post by: Scott_AW on 2010-Apr-24
Forgot about anicoll.  That would make it a lot easier.
Title: Re: Polyvector advantages....
Post by: Dark Schneider on 2010-Apr-24
Quote2. why on normal polyvector the color param or alphamode is so slow?
Quote2. colour pointers are very expensive on OpenGL|ES devices. Use a texture instead wherever applicable.

Please clarify me, that means that setting and ALPHAMODE other than 0 or passing a param col% to POLYVECTOR is slow on iPhone and other OpenGL ES devices?.
Title: Re: Polyvector advantages....
Post by: gregbug on 2010-Apr-24
Quote from: Dark Schneider on 2010-Apr-24
Please clarify me, that means that setting and ALPHAMODE other than 0 or passing a param col% to POLYVECTOR is slow on iPhone and other OpenGL ES devices?.

on my iPhone 3gs passing color param to polyvector the fps pass from solid 30fps at 2-3FPS!!!

alphamode runs fine.
Title: Re: Polyvector advantages....
Post by: monono on 2010-Apr-24
@ Scott and the others: Thanks for the explanation I will try soon.

@ gregbug:
QuoteI have implemented (or rather trying to implement) bbc technique (Bounding box collision) and for the sprites that are rotated OBBC
So we are doing the same thing. I already got a working boxcoll. It even works with deformed, scaled and rotated sprites.
Asume x,y are is one corner of object1 and x1-x4,y1- y4 are the corners of object2:
Code (glbasic) Select

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

If it returns true there is a hit. You can do that with all 4 corners of object1.
For the corners I use some code here from the forum http://www.glbasic.com/forum/index.php?topic=1545.msg10302#msg10302 (http://www.glbasic.com/forum/index.php?topic=1545.msg10302#msg10302)
Code (glbasic) Select


sphi=QSIN(T_Objects[item].ang)
cphi=QCOS(T_Objects[item].ang)
spx = T_Objects[item].width
spy = T_Objects[item].height
dx=spx/2*T_Objects[item].scalex
dy=spy/2*T_Objects[item].scaley

LOCAL hx, hy , _x,_y

hx = (spx/2-T_Objects[item].originx)*T_Objects[item].scalex#
hy= (spy/2-T_Objects[item].originy)*T_Objects[item].scaley#

_x =T_Objects[item].xPos
_y =T_Objects[item].yPos

x1 = _x - cphi*(dx-hx) - sphi* (dy-hy)
y1 = _y - cphi*(dy-hy) + sphi*(dx-hx)
x2 = _x - cphi*(dx-hx) + sphi* (dy+hy)
y2 = _y + cphi*(dy+hy) + sphi*(dx-hx)
x3 = _x + cphi*(dx+hx) + sphi*(dy+hy)
y3 = _y + cphi*(dy+hy) - sphi*(dx+hx)
x4 = _x + cphi*(dx+hx) - sphi*(dy-hy)
y4 = _y - cphi*(dy-hy) - sphi*(dx+hx)

T_Objects[item].cornerx[1]=x1 ; T_Objects[item].cornery[1]=y1
T_Objects[item].cornerx[2]=x2 ; T_Objects[item].cornery[2]=y2
T_Objects[item].cornerx[3]=x3 ; T_Objects[item].cornery[3]=y3
T_Objects[item].cornerx[4]=x4 ; T_Objects[item].cornery[4]=y4


I just slightly modefied it. It regards angle, scale x and y, origin x and y. Maybe you can use that. Especially the origin comes in handy. You can group sprites and let them have all the same origin to for example rotate them around one point.

Another idea for pixelperfect collusion came to my mind. CouldnÃ,´t I just draw all the polystrips belonging to one texture on another screen. To test for collusion I then first check the boxes and secondly check if there is a pixelperfect one with the big createscreen-sprite. Are there any concerns about speed if it is coming to createscreen.
Title: Re: Polyvector advantages....
Post by: Scott_AW on 2010-Apr-24
I believe sprcoll performs a boxcoll first.
Title: Re: Polyvector advantages....
Post by: Kitty Hello on 2010-Apr-26
fixed in the next update.
Title: Re: Polyvector advantages....
Post by: monono on 2010-Apr-26
sorry I canÃ,´t follow  :S What are you going to fix exactly, Gernot?
Title: Re: Polyvector advantages....
Post by: Scott_AW on 2010-Apr-26
Quote from: monono on 2010-Apr-24
Another idea for pixelperfect collusion came to my mind. CouldnÃ,´t I just draw all the polystrips belonging to one texture on another screen. To test for collusion I then first check the boxes and secondly check if there is a pixelperfect one with the big createscreen-sprite. Are there any concerns about speed if it is coming to createscreen.

sprcoll(playerimage, playerx, playery, texture, posx, posy)

just store the pos data instead of creating an image map and you could even have an array of different images.

Since the whole sprite will be checked you'll only need the top left origin to store.  However if you're going to use rotation and scaling you'll have to make masks of various states of the sprite. 

Maybe that's what Gernot is talking about?  A sprcoll with rotation and scaling.
Title: Re: Polyvector advantages....
Post by: Kitty Hello on 2010-Apr-27
Uhm... No.
I was fixing the reduction to 2PFS when you use coloured vertices. It should be slightly faster with the next update.

In deed I did use the rotated image / Sprcoll once in a game. It works very fast for Wiz/WinCE/Win32/Linux/Mac. But on the iPhone, it's too slow, because for pixel collisions I have to read the transparency pixels from the graphics card into consumer memory, and that is slooooooow.
Title: Re: Polyvector advantages....
Post by: gregbug on 2010-Apr-27
Quote from: Kitty Hello on 2010-Apr-27
Uhm... No.
I was fixing the reduction to 2PFS when you use coloured vertices. It should be slightly faster with the next update.

wow thanks!

any news on alphamode with polyvector ?
Title: Re: Polyvector advantages....
Post by: Kitty Hello on 2010-Apr-27
It should work already. Try alphamode -1 at the start and right before the endpoly. And alphamode xxx in between the polyvector calls.
Title: Re: Polyvector advantages....
Post by: gregbug on 2010-Apr-27
Quote from: Kitty Hello on 2010-Apr-27
It should work already. Try alphamode -1 at the start and right before the endpoly. And alphamode xxx in between the polyvector calls.

work fine thanks!
Title: Re: Polyvector advantages....
Post by: Scott_AW on 2010-Apr-27
Quote from: Kitty Hello on 2010-Apr-27
In deed I did use the rotated image / Sprcoll once in a game. It works very fast for Wiz/WinCE/Win32/Linux/Mac. But on the iPhone, it's too slow, because for pixel collisions I have to read the transparency pixels from the graphics card into consumer memory, and that is slooooooow.

You think that's a software or a hardware issue?  I know that the iPad is very similar in some ways, have you had a chance to test out the device?

Anyone else get one lately?
Title: Re: Polyvector advantages....
Post by: monono on 2010-Apr-28
@ gregbug: that idea of yours, is whatr IÃ,´m trying to avoid. thanks anyway!
Title: Re: Polyvector advantages....
Post by: Kitty Hello on 2010-Apr-29
Quote from: Scott_AW on 2010-Apr-27
Quote from: Kitty Hello on 2010-Apr-27
In deed I did use the rotated image / Sprcoll once in a game. It works very fast for Wiz/WinCE/Win32/Linux/Mac. But on the iPhone, it's too slow, because for pixel collisions I have to read the transparency pixels from the graphics card into consumer memory, and that is slooooooow.
You think that's a software or a hardware issue?  I know that the iPad is very similar in some ways, have you had a chance to test out the device?

iPod/iPhone is the very same. Just no phone and no GPS, that's it.
It's a hardware design issue. No problem if you know about it. There's always a workaround.