Speeding up sprites...

BlitzMax Forums/MiniB3D Module/Speeding up sprites...

jkrankie

(Posted 2010) [#1]

I'm using Sprites with collisions for bullets in my game, but i'm finding them to be the cause of quite a bit of slowdown. From reading through the forums, i spotted that Simon had mentioned he'd implemented a batching system for Sprites in iMiniB3D that he had yet to add to MiniB3D. What are the chances this could be added? Or how easily could i add it myself (baring in mind i'm pretty rubbish at OpenGL coding)

Just to clarify, i don't need the sprites for particles as i've already written something for that, it's purely for TSprites that need collisions.

Cheers
Charlie

jkrankie

(Posted 2010) [#2]

Ok, i *think* i've got a handle on this now after taking a look at the iMiniB3d source. I'll have a go at it later on today. It looks like rather than just adding the sprite meshes to the main entitiy list, they are added to their own list, but i haven't worked out where yet...

Cheers
Charlie

jkrankie

(Posted 2010) [#3]

Right, it looks like the existing method/functions i need to be dealing with are in tcamera.bmx and t global, where i need to add a few lines. I'll also need to add the sprite batch class.

updateentityrender
rendercam

Are there any gotchas i need to look out for i wonder...

Cheers
Charlie

jkrankie

(Posted 2010) [#4]

Right, i've confused myself completely! there are too many structural differences between MB3D and iMB3D that i can't get my head around!

Cheers
Charlie

Kryzon

(Posted 2010) [#5]

Hmm, try using a single surface system. People did that with Blitz3D alone (look at ParticleCandy's performance, it's awesome).
So you can get a crude version going only using pure MiniB3D commands (it won't be the best solution but it would be definitely faster than 1 surf for each sprite).

I also want to create a good single surface particle system for my MiniB3D projects, but time is precious!

I think one essencial thing to understand is that special matrix mat_sp that is exclusive to sprite-entities. Once I get my head around that I should be able to go further (if anybody would like to share any insights, don't hesitate!).
If I'm thinking correctly, that mat_sp is nothing more than the inverse camera matrix so the mesh can point towards it correctly, the fundamental feature of sprites.

Problem is, how to turn every quad by that matrix within a single surface?
The sprite functionallity works as it is because every quad is a different entity, so the matrix acts on a quad-level.
But what about an entire surface of quads?

EDIT: could you benchmark the slowdown that regular sprites caused in your program? the "before" and "after"?

Sledge

(Posted 2010) [#6]

I'm using Sprites with collisions for bullets in my game, but i'm finding them to be the cause of quite a bit of slowdown.

Are you sure it's the rendering that is the bottleneck and not the collision system?

Robert Cummings

(Posted 2010) [#7]

sprites typically have one state change per sprite, so it will very fast be the bottleneck on any system but only if he's using different images per sprite. Else its probably fill rate.

The clue is he is using them for bullets, right? well that only one state change if its just the one bullet texture... so perhaps it is fillrate?

jkrankie

(Posted 2010) [#8]

I'm using several different images for bullets.

Cheers
Charlie

Kryzon

(Posted 2010) [#9]

I think one essencial thing to understand is that special matrix mat_sp that is exclusive to sprite-entities. Once I get my head around that I should be able to go further (if anybody would like to share any insights, don't hesitate!).
If I'm thinking correctly, that mat_sp is nothing more than the inverse camera matrix so the mesh can point towards it correctly, the fundamental feature of sprites.

Problem is, how to turn every quad by that matrix within a single surface?
The sprite functionallity works as it is because every quad is a different entity, so the matrix acts on a quad-level.
But what about an entire surface of quads?

Can anybody help me with this?

jkrankie

(Posted 2010) [#10]

Actually, the game space is 2D, with an orthographic camera so the sprites only need to be facing in one direction. I suppose that *might* be helpful...

Cheers
Charlie

Kryzon

(Posted 2010) [#11]

That's great, but I'd still like to know what anyone has to say for the problem above.

Sledge

(Posted 2010) [#12]

That's great, but I'd still like to know what anyone has to say for the problem above.

This might be dumb, but I'd question why you are trying to build an optimised system on top of MiniB3D. As I understand it, the fastest (fixed function) way to render sprites in OpenGL is to express them as a vertex array and cane through it with glDrawArrays(). If optimising sprite rendering is really *that* important then surely sidestepping MiniB3D's class hierarchy is going to be preferable to reverse-engineering it. ie Build a reduced 2D system that does only what you require, only in the order you require it, and drop into it as needed.

Kryzon

(Posted 2010) [#13]

I'm not looking for 2D\orthographic sprites, if that is what you are saying. I'm speaking of sprites as they are known in the Blitz3D universe: quad meshes that always face the camera, and can have 3D transformations applied to them.

I didn't quite get what you meant with sidestepping the class hierarchy. In the same way single-surface particles were achieved with Blitz3D (with individual vertex manipulation), the same can be achieved in mB3D (and it "should" be achieved, since single surface is much faster than 1 surf for each particle).
I want to know if someone can explain to me how does that mat_sp matrix work, and how could one apply that matrix in a mesh that has more than just one quad. From then on, I could build my own sprite class that acts as a single surface holder for all the 3D particles.
I don't know if a Vertex Array is needed, since mB3D already uses VBOs for high polygon meshes. It's probably the theory that's the tricky part.

jkrankie

(Posted 2010) [#14]

If you're just after faster particles, you could try this code i posted before, just rename the texture file. I can render about 25,000 blended, textured quads at 60fps on my Mac Mini.

Import sidesign.minib3d

Graphics3D 640,480,32,7,60

cam=CreateCamera();PositionEntity cam,0,0,-30

light=CreateLight();PositionEntity light,0,0,-15

'load textures
pix = LoadPixmap("testtex.bmp") ;tex = TexFromPixmap(pix)

list:TList=New TList

Local old_ms=MilliSecs(),renders,fps

cube=CreateCube()

While Not KeyHit(key_escape)
	
	TurnEntity cube,0,0,1
	MoveEntity cube,0.1,0,0
	RenderWorld
	
	renders:+1
	If MilliSecs()-old_ms>=1000
		old_ms=MilliSecs(); fps=renders;	renders=0
	EndIf
	
	'addmore stuff to the list
	For Local n:Int = 0 To 49
		Local r:Int=Rand(0,3)
		If r=0 list.AddLast New glsprite.Create(EntityX(cube), EntityY(cube), tex, Rand(0, 359), 0.3)
		If r=1 
			list.Addlast New glsprite.Create(EntityX(cube), EntityY(cube), tex, Rand(0, 359), 0.3,0.5,0)
			glsprite(list.last()).scale(2.5,2.5)
		EndIf
		If r=2 list.AddLast New glsprite.Create(EntityX(cube), EntityY(cube), tex, Rand(0, 359), 0.3,0,0.5)
		If r=3 list.AddLast New glsprite.Create(EntityX(cube), EntityY(cube), tex, Rand(0, 359), 0.3,0.5,0.5)
		
	Next
	
	'enable/disable stuff
	glenable(GL_COLOR_MATERIAL)
	glShadeModel(GL_SMOOTH);							
	glDisable(GL_DEPTH_TEST);							
	glEnable(GL_BLEND);								
	glBlendFunc(GL_SRC_ALPHA,GL_ONE);												
	glEnable(GL_TEXTURE_2D);						
	
	'update sprites
	Local currenttexture:Int
	Local count:Int=0
	
	glbegin(gl_quads)
	
	For Local g:glsprite=EachIn list
		
		If g.update(currenttexture)=True Then list.remove g
		count:+1
		currenttexture=g.tex
	Next
	glend()
	
	beginmax2d()
		DrawText"FPS: "+String(fps)	,10,10
		DrawText "Sprites: " + String(list.count()), 10, 20
	endmax2d()
	
	Flip 
	If KeyHit (key_space) Then SavePixmapPNG(GrabPixmap(0,0,640,480),"savedpic.png",0)
Wend


Type glsprite
	
	Field tex:Int
	Field x:Float,y:Float,z:Float=0
	Field angle:Float=0
	Field life:Float=1.0
	Field rot:Float=Rnd(-2,2)
	Field xscale:Float=1,yscale:Float=1
	Field r:Int=255,g:Int=255,b:Int=255
	Field speed:Float
	Field texoffsetx:Float=0,texoffsety:Float=0
	Field texwidth:Float=0.5,texheight:Float=0.5
	
	Function Create:glsprite(inx:Float,iny:Float,intex:Int,angle:Float,speed:Float,tox:Float=0,toy:Float=0)
		Local n:glsprite=New glsprite
		n.x=inx
		n.y=iny
		n.tex=intex
		n.angle=angle
		n.speed=speed
		n.texoffsetx=tox
		n.texoffsety=toy
		Return n
	EndFunction
	
	Method scale(sx:Float,sy:Float)
		xscale=sx;yscale=sy
	EndMethod
	
	Method update:Int(currenttexture)
		
		life:-0.01
		
		x:+speed*Cos(angle)
		y:+speed*Sin(angle)
		
		glcolor4f(r,g,b,life)
		
		If currenttexture<>tex
			glend()
		 glbindtexture(GL_TEXTURE_2D,tex)
		glbegin(gl_quads)
		EndIf	
		
		'bottom right
		glTexCoord2d(texoffsetx+texwidth, texoffsety+texheight)
		glvertex3f(x+((1*xscale)*Cos(angle+135)),y+((1*yscale)*Sin(angle+135)),z)
		
		'bottomleft
		glTexCoord2d(texoffsetx,texoffsety+texheight)
		glvertex3f(x+((1*xscale)*Cos(angle+225)),y+((1*yscale)*Sin(angle+225)),z)
			
		'topleft
		glTexCoord2d(texoffsetx, texoffsety)
		glvertex3f(x+((1*xscale)*Cos(angle+315)),y+((1*yscale)*Sin(angle+315)),z)
		
		'topright	
		glTexCoord2d(texoffsetx+texwidth, texoffsety)
		glvertex3f(x+((1*xscale)*Cos(angle+45)),y+((1*yscale)*Sin(angle+45)),z)

		If life<0 Then Return True	
		Return False
		
	EndMethod
	
End Type

Function AdjustTexSize(width:Int Var, Height:Int Var)
	Function Pow2Size:Int(N:Int)
		Local Size:Int

		Size = 1
		While Size < N
			Size = Size Shl 1
		Wend

		Return Size
	End Function

	Width  = Pow2Size(Width)
	Height = Pow2Size(Height)
End Function

Function TexFromPixmap:Int(pixmap:TPixmap, mipmap:Int = True)
	If pixmap.format<>PF_RGBA8888 pixmap=pixmap.Convert( PF_RGBA8888 )
	Local width:Int=pixmap.width,height:Int=pixmap.height
	AdjustTexSize width,height
	If width<>pixmap.width Or height<>pixmap.height pixmap=ResizePixmap( pixmap,width,height )
	
	Local old_name:Int,old_row_len:Int
	glGetIntegerv GL_TEXTURE_BINDING_2D,Varptr old_name
	glGetIntegerv GL_UNPACK_ROW_LENGTH,Varptr old_row_len

	Local name:Int
	glGenTextures 1,Varptr name
	glBindtexture GL_TEXTURE_2D,name
	
	Local mip_level:Int
	Repeat
		glPixelStorei GL_UNPACK_ROW_LENGTH,pixmap.pitch/BytesPerPixel[pixmap.format]
		glTexImage2D GL_TEXTURE_2D,mip_level,GL_RGBA8,width,height,0,GL_RGBA,GL_UNSIGNED_BYTE,pixmap.pixels
		If Not mipmap Exit
		If width=1 And height=1 Exit
		If width>1 width:/2
		If height>1 height:/2
		pixmap=ResizePixmap( pixmap,width,height )
		mip_level:+1
	Forever
	
	glBindTexture GL_TEXTURE_2D,old_name
	glPixelStorei GL_UNPACK_ROW_LENGTH,old_row_len

	Return name
End Function

However, it doesn't take into account anything done by minib3d.

Cheers
Charlie

Sledge

(Posted 2010) [#15]

I'm not looking for 2D\orthographic sprites...I didn't quite get what you meant with sidestepping the class hierarchy.

I meant minimizing state changes with "raw" OpenGL calls rather than manipulating the entity system to do so. Just a thought.

klepto2

(Posted 2010) [#16]

Hi, I'm currently not at home, but i will post a small sample as soon as i'm home. The keyword are pointsprites. if you're interrested in really fast sprites you will love it. The downside is the missing ability to scale them properly.

Here is a small screen with minib3d using pointsprites (150001 sprites at 43fps on a ATI Radeon X800)

Another way to speed up the the existing sprites would be to use shaders to manipulate the orientation instead of doing it via cpu.

jkrankie

(Posted 2010) [#17]

That looks cool!

The only issue with point sprites is that they won't work on many laptops as they are usually OpenGL 1.4 or less.

Didn't you have a fast sprite thing in your extended version Klepto2? I'll have to have a look...

Cheers
Charlie

klepto2

(Posted 2010) [#18]

In my old extended Version was a single Surface Particle System which you can try to use. A fast sprite system was planned but not really finished.

An alternative would be to check for the ARB_PointSprite extension and use pointsprites or single surface according to the result.

As a side note, you should not use Sprites for collision. Try Linepicking instead. Ok, it depends on your needs but i think the major slowdown will be caused by collision detection for this many sprites not the sprite alignment itself.

jkrankie

(Posted 2010) [#19]

I'm only using the collisions for when the sprites hit the arena walls, so yes i guess it does seem a bit much to be using collisions for this. I'll see if i can work out how to do linepicking...

I'll dig out the extended version (i'm sure i've got it somewhere...) and see if the SS sprites make a difference.

Cheers
Charlie

jkrankie

(Posted 2010) [#20]

Where abouts in the extended version code would i find the SS sprite stuff? I can't find it!

Cheers
Charlie

Kryzon

(Posted 2010) [#21]

From what I noticed from demos, Point Sprites seem to grow smaller the closer the camera is (this won't happen to quads). Is there a way to disable that?

_Skully

(Posted 2010) [#22]

I've found that encapsulating the parameter data into an array referenced by constants speeds things up quite a bit. I used this in my particle system. Using this method there is one lookup for the array reference and then just an offset within it for each parameter. The code doesn't look pretty but its easy to offset using getters/setters but use the constant-array reference for sprite updates.

klepto2

(Posted 2010) [#23]

The SSS part is not included directly in minib3dext it is a seperate module (something with particles) also contined in the package at www.minib3d.com .

@Kryzon: Yes, thats the reason why i haven't continued it. the best way is really to go the shader way but this have other consequences (using shaders will deactivate most of the fixed function pipeline).

Kryzon

(Posted 2010) [#24]

I see Klepto2, thanks for the posts.

Another way to speed up the the existing sprites would be to use shaders to manipulate the orientation instead of doing it via cpu.

This definitely sounds like a good way. I'll investigate further (it wouldn't be much of a cost because I'll replace most of the fixed function anyway).

SLotman

(Posted 2010) [#25]

Point sprites doesn't work for billboards, which is what B3D sprites actually are.

For particle systems it's fine - since particles always faces the camera, but for trees or other things that actually should be parallel to a plane (ex: if the camera goes up, it shouldn't face the camera) it won't help at all.