X_SPRITE replacement - (faster) 3D sprite with rotation (billboards)

[Hemlos]

I cant just add it to my lib...i have over 4000 commands to sort out

[kanonet]

If you dont want to copy it together from this posts here, download full lib from my website, copy test program from here, add lib and run it.

Btw come to IRC if you want.

[djtoon]

when i try to compile to iphone i get this
/cygdrive/q/Compiler/platform/iPhone/bin/arm-apple-darwin9-libtool: file: gpc_temp2.o has no symbols
/cygdrive/c/Program Files (x86)/GLBasic/Compiler/platform/iPhone/bin/arm-apple-darwin9-libtool: file: C:\Users\dan\AppData\Local\Temp\glbasic\output.obj(gpc_temp2.o) has no symbols
any ideas? whats wrong?

[kanonet]

I have no idea. I dont have an iDevice and i never compiled something for one. So i just dont know. In theory this here should work on iPhone if you have all dependencies, but i have never tested it on iOS. I just tested under Windows and Linux and if i remember right someone else tested under Android(?). Had you compiled with native opengl calls before? Sorry that i cant help you here, hopefully someone else can.

[Hemlos]

I'm giving this another whirl.and im trying to put it all together and get errors.


this is a bug report.

using the pieces libsprite and libmath on your website, and the gl.gbas that you indicated at the top of the thread.
I unremarked the define in the libSprite, so that this is declared:

Code (glbasic) Select Expand

?DEFINE gl_gbas 1

I downloaded this from your website: libSPRITE.gbas libMATH.gbas

I get this error message:

"..\..\KanonetLibs\libSPRITE.gbas"(26) error : syntax error

Inside the TYPE TSprite, the arrow is pointing to this symbol in the first INLINE:

Code (glbasic) Select Expand

}im using ver.10.238

I know you put together a package, i dont know why i like to do things the hard way, but i thinkfound a bug.

[Hemlos]

sorry for the spam

BTW, which is newer? thread code or the one on your site?

ps. this is what specifically caused the exception:
}
       extern "C" {
}
       namespace __GLBASIC__ {


More about using the lib after I infused libSPRITE with Spritez3d tonight..

Something is not right.
They dont move after they have been placed once.
They are scaled way too large.
And they dont rotate.

Im doing  asmall test where it is set to handle only one emitter.
It was very easy to setup, init in header, start, draw(xyzsr), stop
But for some reason they dont do anything.
I had to declare the sprite as a global, because of the scope didnt work with local in the header.
The call to draw, is in a function, in a for loop.
This shouldnt matter but hey idlike to see this thing work....the variables passed into the sprite.draw(x,y,z,s,r) function call are are declared local in my function and scope into the for loop no problem.

The particle engine runs great as it were, i dont think there is any problem with how i am implementing it because i did exactly how you did your array of particles in your sample....the only real main  betwen your sample and my routine are:
1GLOBAL sprite
2draw is in a function in a for loop
3they move and change scale dynamically.


I am almost ready to publish it, but i was hoping to make a few final tweaks for speed.


Which lib should i be using?

[kanonet]

Thank you for your feedback.

1st: all my libs have a version date in the header so you always know which one is newest. Unfortunatly i forgot to add that header in the start post. But in this Thread was a very old version and you always find the newest version on my website (its easier to maintain than several threads). I update 1st post.

2nd: you found something strange there. It did work with the earlier V11 beta that i used to create it. But i seems that its not allowed to do it that way in V10 and the current V11 beta. Strange, but easy to fix, just get new version. Btw. if you dont need gl.gbas, dont use it, my INLINE is a tiny bit faster - and it compiles faster too.

3rd: Scale factor is differently calculated from the original X_SPRITE one, which is why you dont get particles in the same size without tweaking scale#.
X_SPRITE: scale=1 is based on texture size (and screen resolution?), so if you decide to use a higher resolution texture your sprite gets bigger!
my replacement: scale=1 is always 1 unit in 3D world, no matter what texture size you've got. In my opinion this is more useful and more logical. Just call it with the absolute size that you want your particle to be.

4th: when i use the test program from 1st post i can not confirm your problem. Scale ->see 3rd and rotation works perfectly for me. Btw. you need to keep in mind that you dont tell the sprite to turn/rotate, you call it with the absolute rotation that you want! So if you call it one time with 30 and next time with 30 again it will be stucked at 30°! If you want to turn it you need to do this manuall, like: call it with 30 1st time and with 60 next time, so you get  a rotation.
Just for you the test program from 1st post, but with rotation:

Code (glbasic) Select Expand

// --------------------------------- //
// Project: TSprite
// Start: Sunday, July 24, 2011
// Autor: Kanonet
// Last Update: November 17, 2012

SETSCREEN 800,600,0
SYSTEMPOINTER TRUE
ALLOWESCAPE FALSE
AUTOPAUSE FALSE
LIMITFPS -1

// number of sprites to draw:
LOCAL count%=1000

LOCAL root%=SQR(count)/2, line%, row%, fps, timer, mx, my=15, mz=-4, selected%=1, rot%

// texture
DRAWRECT 0,0, 16, 16, RGB(0,0,255)
DRAWRECT 12,0, 4,8, RGB(255,127,0)
DRAWRECT 0,12, 4,4, RGB(255,0,63)
DRAWLINE 0,0, 16,16, 0xffffff
DRAWLINE 0,16, 16,0, 0xffffff
GRABSPRITE 0, 0,0, 16,16

// sprite
LOCAL sprite AS TSprite
sprite.Init()


// mainloop
REPEAT

line=-root; row=-root; INC rot

// mouse for camera control:
mx = mx + MOUSEAXIS(0)
my = my + MOUSEAXIS(1)
mz = mz + MOUSEAXIS(2)
IF KEY(27) // + more sprites
INC count
root=SQR(count)/2
ENDIF
IF KEY(53) AND count>1 // - less sprites
DEC count
root=SQR(count)/2
ENDIF
IF KEY(2) THEN selected=1
IF KEY(3) THEN selected=2
IF KEY(4) THEN selected=3

X_MAKE3D 0.1, 1000, 45
X_CAMERA my*COS(mx)*root*0.2,mz*2,my*SIN(mx)*root*0.2, 0,0,0

IF selected=1
FOR i=1 TO count

X_SPRITE 0, 0, line, row, 0.06

INC row
IF row>root
row=-root
INC line
ENDIF
NEXT
ELSEIF selected=2
sprite.Start()
FOR i=1 TO count

X_SETTEXTURE 0, -1
sprite.Draw(0, line, row, 0.5, rot)

INC row
IF row>root
row=-root
INC line
ENDIF
NEXT
sprite.Stop()
ELSE
sprite.Start()
X_SETTEXTURE 0, -1
FOR i=1 TO count

sprite.Draw(0, line, row, 0.5, rot)

INC row
IF row>root
row=-root
INC line
ENDIF
NEXT
sprite.Stop()
ENDIF

X_MAKE2D
ALPHAMODE 0.9
DRAWRECT 0,0,800,60,RGB(70,70,70)
PRINT "CAMERA CONTROL: MOVE MOUSE / MOUSE WHEEL    |    FPS: "+INTEGER(1000/(timer-fps)), 0,0
PRINT "SPRITES CURRENTLY: "+count+"    |    PRESS (+) FOR MORE SPRITES AND (-) FOR LESS", 0,15
PRINT "SELECT: (1) X_SPRITE    |    (2) TSPRITE    |    (3) TSPRITE WITH TEXTURE ORDERING", 0, 30
PRINT "SELECTED: "+selected, 0, 45

SHOWSCREEN
  fps=timer
timer=GETTIMERALL()
UNTIL KEY(1)
END
Or more in general: they do not move/ rotate/ scale, you call them with the absolute position, rotation, scaling. If you want to move it,you need to do this in your engine and just call the sprite with absolute positions, same like you do with XSPRITE. 

5th: If you just draw the sprites in one function you can keep sprite local. But if you call it in different functions you need to make it global, or create a local sprite type for each function. You need to try for your self whats faster in your case. Btw. if you really want to speed up things, you need to use texture ordering (or just one texture atlas for all particles), X_SETTEXTURE is slow, so try to use it as few as possible. If you use an texture atlas with all particles in one sprite you save much speed. I can write you a function to change texture coordinates like with POLYVECTOR in 2D, this is faster that X_SETTEXTURE, but if you still sort your particles to avoid unnecessary function calls it would be even faster, obviously.

Hope this helps you.

[Hemlos]

Ok crash fixed...

The only problems are, alpha and cameraup isnt matching.

Edit: Nice work btw kano, it is an IMPRESSIVE amount faster!
Running 15k particles is WAY overkill for any effect, but thats about the max amount of total particles i can run on my slow machine, without dropping below 30fps.

[Hemlos]

Any idea why the alpha isnt working kano?

[djtoon]

what about compile for the iphone? any ideas?

[Hemlos]

Try the new libSPRITE.gbas on his site.
And try using OpenGLES i think this is for mobile devices...i really dont know if iphone uses it or not though.

[kanonet]

@Hemlos: uff many posts you gave me there...

1. Nice you got it to work and gratz on your speed increase! Yes i think 15k Particles should be enough. 
Btw. thank you for your kind words. I will be happy to see it used in a working particle engine.

2. What is the problem with alpha value? Do you change alpha with ALPHAMODE or using alphachannel on your texture? Or both? Can you please send me one of your textures that has problems (and maybe a short description) so i can have a look on it?

3. I cant confirm your problems with cameraup, i tested it before i published it in the first time and now i tested it again, and it definitely works perfect no matter how i spin around the camera. Not sure, but maybe your problem is related to the following:

I assumed the rotation was done for me, like x_sprite
No worry here, i have the vector for this already calculated.

I dont really understand what you mean with this. The rotation gets done for you! You just need to input the rotation angle in degrees, it automatically calculates the rotation vector (and complete matrix), its designed to work without bothering you with evil math. If you input an already precalculated vector (how do you do this?!?), thinks will go horribly wrong! If you did it that way it would explain why your up vector does not work properly.


@djtoon: sorry cant help you there. Btw. which way did you use it, with gl.gbas or without (maybe try both, dont forget the ?DEFINE)? Can you try to just compile my test program for iphone (just change resolution)?

[Hemlos]

2. What is the problem with alpha value? Do you change alpha with ALPHAMODE or using alphachannel on your texture? Or both? Can you please send me one of your textures that has problems (and maybe a short description) so i can have a look on it?

I use both.

Btw. you need to keep in mind that you dont tell the sprite to turn/rotate, you call it with the absolute rotation that you want!

Edit: ah this statement confused me."absolute rotation"....that input you is to rotate on the local z axis.
And this i put back to 0, and it works as expected.....not sure why i needed to do this, earlier tests showed improper roations, now they work fine.

And about the alpha more...i use a color input to color my old quads vertices so they can be used without a texture and be dynamically colored.

[djtoon]

on iphone i get the error in somecode
in

GLrunVertexSumbitARM
weird bug that pops up in the xCode debugger


i was wishing to see if i could get a speed boost in my game

[Hemlos]

@Kano: I ran my first test demo for 8 hours straight without a problem, no memory leaks or anything, working good.
I was looking around on the net, i noticed there is another command that can be used with the glarrays, a color command, any idea how to implement it?
I think this might be why there is a difference with brightness and color.

@djtoon: did you try to use the opengl.gbas gles version too? Did you try without that file, and use the builtin code?