3D sprite slowdown - heeelllp!!

Blitz3D Forums/Blitz3D Programming/3D sprite slowdown - heeelllp!!

Who was John Galt?

(Posted 2004) [#1]

I'm creating a 2D game and I have just updated it to use 3D (quad) sprites. You have this ship that can fire tons (1000s) of bullets that remain in the air at the same time. Originally these were implemented as single pixel plots, but now they are alpha'd quads, each created using copyentity. When a maximum allowed number are fired, the oldest one is deleted each time a new one is created and the entity freed.

Now I'm not expected to be able to have as many bullets in the air as in the original version, but it seriously slows down once I have fired a couple of hundred and I have seen people have a lot more 3D sprites on screen at a time. The slowdown seems to come in quite sharply, the hard disk starts grinding and the computer eventually complains it's running out of virtual mem. Any ideas?

poopla

(Posted 2004) [#2]

The problems here are your making way to many memory intensive calls in freeing/creating/deleting type instances and quads on the fly. What you need to do is implement a single surface system that recycles your particle type list(and possibly sorts them as well), then all the realtime updating is cleared out.

Who was John Galt?

(Posted 2004) [#3]

Thanks for the feedback. My original system created and deleted type instancces for the bullets with no problems- not ideal perhaps but it worked fine with many more bullets than I have now. I don't know how blitz implements a copyentity internally, but I can hardly believe that creating say 200 copies of a quad, deleting them one at a time while creating say 200 more can bring my machine to its knees for what appears to be lack of memory. This is fragmentation on steroids. Any more ideas? Perhaps its the whole lack of 'single surface' thing?

EOF	(Posted 2004) [#4]

Have a play with Skidracers single surface particle system from the code archives.
I'm working on a single-surface version of my Sprite Control at the moment but it's far from complete.

Who was John Galt?

(Posted 2004) [#5]

Ahh- ok thanx mate I will try that.

Who was John Galt?

(Posted 2004) [#6]

Right I've fixed the problem, but can't figure out why the change makes such a big difference. Look at the 'efinder' loop below. I replaced the commented out Draw3Dimage function call with the positionentity command and the change in speed/memory/not grinding hard disk/not crashing my machine was drastic. Can anyone figure out why this makes such a major difference with say 200 sprites on (or off!) screen?


For efinder1=Each efinder
    ;Draw3Dimage efinder1\im,efinder1\x,efinder1\y
    PositionEntity efinder1\im,efinder1\x,efinder1\y,0
Next

Function draw3Dimage(quad,x,y,frame=0)
	PositionEntity quad,x,y,10
	Brush=GetEntityBrush(quad)
	Tex=GetBrushTexture(Brush)
	EntityTexture quad,Tex,frame
	Return
End Function

I look forward to single surface sprite control!

Neo Genesis10

(Posted 2004) [#7]

I assume you're using the Draw3DImage function as an easy way to change frames. The commands to retrieve the brush store the brush in memory and you aren't freeing them up. Try adding FreeBrush to your function.

Ross C

(Posted 2004) [#8]

Try to re-use your types, instead of deleting them :)

Who was John Galt?

(Posted 2004) [#9]

Ahhhh..........

NeoGenesis- that sounds like it might be the problem. Good pointer ta.

Ross- Yep good tip cheers.

Who was John Galt?

(Posted 2004) [#10]

that fixed it.