Performance in editor vs Blitzmax

[Imphy]

I’ve created a menu background effect that is quite intensive and it renderes around 3900 particles and on my laptop the editor has a framerate of around 120 FPS in maximized (1680×1050) at effect zoom 100% and update mode=fast.

When in BlitzMax the very same effect runs at 14 FPS in 1180×928 (same size as the editor viewport) with nothing else running in the app but the particles at a logic rate of 30 hz with tweening.

I’ve tried OpenGL, DX7 and DX9 and all three modes offer the same FPS roughly. If I disable debug it goes up to 65 FPS so the debugger is obviously a big thief but still the editor runs much faster?´I’m also using CopyCompiledEffect.

Any thoughts?

[imported_peterigz]

hmm, it should always be a little quicker in blitzmax so there must be something in the implementation causing that I’d have thought. Have you got some sample code I can look at?

[Imphy]

Yes, odd isn’t it?

Import rigz.timelinefx



Include "inc_functions.bmx"



Local fixedRateTween:TFixedRateTween = TFixedRateTween.Create(30)



Local particleManager:tlParticleManager

Local effectLib:tlEffectsLibrary = LoadEffects("assets/effects/effects.eff")

Local effect:tlEffect



'SetGraphicsDriver GLMax2DDriver()

'SetGraphicsDriver D3D7Max2DDriver()

SetGraphicsDriver D3D9Max2DDriver()



Graphics 1680,1050,1



particleManager = CreateParticleManager(5000)

effect = CopyCompiledEffect(effectLib.GetEffect("menu_background"), particleManager)

particleManager.addeffect(effect)

effect.setx(0)

effect.sety(0)

effect.SetAreaSize(GraphicsWidth(),GraphicsHeight())

particleManager.SetScreenSize(GraphicsWidth(),GraphicsHeight())



fixedRateTween.Reset()

While Not KeyDown(KEY_ESCAPE)

Cls

fixedRateTween.SetDeltaTime()

While fixedRateTween.RepeatUpdate()

particleManager.Update()

fixedRateTween.SetExecutionTime()

Wend

fixedRateTween.SetTween()



particleManager.DrawParticles(fixedRateTween.GetTween())

DrawText "FPS: " + fixedRateTween.getFPS(), 10, 10



Flip False

Wend

The tween function is pretty much like any other tween function.

[imported_peterigz]

I didn’t have the functions include so couldn’t properly test, but i did replace the timing code (which I assume is in the include) with rigz.tweener timing module and things seemd to run fine. Although I had to change the graphics line as Graphics 1680, 1050, 1 didn’t work at all here, had to use Graphics 1680, 1050, 32 but doubt that would be causing it?

Anyway, attached is a small test program with a complex effect which runs about 150 fps here which is normal for me. See if it runs ok for you, if it does then maybe there’s an issue somewhere in your timing code?

[Imphy]

Thanks for taking the time to modify the code Pete.

When testing with your version I located the (two) causes:

1) I assume your editor is running in OpenGL and it seems that in windowed mode OpenGL is roughly twice as fast as DX9 for timelineFX whereas in fullscreen mode the OpenGL and DX9 is pertty much identical. My test results were (ifnore the actual FPS as it’s a modified version of the effect, it’s the differences that are relevant):

Resolution		Driver	Virtual Resolution	FPS

1024x76832	OpenGL	VR 1600x1200	240

1024x768x32	DX9	VR 1600x1200	240

1024x768x0	OpenGL	VR 1600x1200	180

1024x768x0	DX9	VR 1600x1200	95

2) I’ve created an effect to fill the screen at 1920×1200 (which is the virtual resolution of my game) and the editor runs in different aspect and the interface covers some of the area so it’s less particles to draw.

Don’t know if the DX9 OpenGL differences are consistent on other machines or if it’s just on this laptop.

[imported_peterigz]

I think the differences can be down to a lot of things like GFX card (ATI/nVidia) driver version, windows version etc. I’ve always found OpenGL to perform better for me overall, but directx 7 will always the better compatibility on windows pc’s, which is a shame because that’s the slowest one for me 🙂

So does your menu effect run fine for you now then? Those FPS scores look a lot better anyway…

[Imphy]

Yes, it runs OK now 🙂 I am also thinking of having 3 effect details for every effect so you can choose level of detail. Would be really cool if it could be benchmarked/automated some way when the game is first run with the option to manually change. I prefer not to use a particle limit as the detail limiter as it doesn’t look too good in an environment where most particle fade in (it starts to pulsate).

I’ve also added a custom method to the tlParticleManager to perform as I wish with multiple viewports at different locations. Without it I couldn’t get the effects to draw correctly in different viewports.

New fields for tlParticleManager

Field vp_x:Float

Field vp_y:Float

New method to set the position of the viewport:

Method SetScreenPosition(x:Int, y:Int)

vp_x = x

vp_y = y

End Method

and in the DrawParticles method I’ve changed the if statement for drawing to:

If px > vp_x - e.Image_Diameter And px  vp_y - e.Image_Diameter And py < vp_y + vp_h + e.Image_Diameter

Not sure if there is another way to solve it using the existing methods but setorigin and setscreensize and setareasize didn’t quite cover it for me .

[imported_peterigz]

Ahh yes, an x and y coord for the viewport of the particle manager makes sense, I’ve just implemented your code and updated via SVN 🙂 So split screen should be more easy now, nice change thanks.

Regarding the particle detail, you might want to try Effect.SetAmount which will affect the amount of particles spawned in the effect. It’s a percentage value, with 1 being the default, so setting it to 0.5 for example will spawn half the amount of particles. You’d need to do it each time you copy an effect and add it to the particle manager, but at least you could have any arbitrary amount set by some global value or something.

I’ll look into seeing about adding this in as a more built in feature that just affects all effects in particle manager, like ParticleManager.SetParticleDetail(), which would also be a percentage value.

[Imphy]

Glad the change made sense 🙂

Nice with the EffectAmount as well – that’ll be the best way to implement it of course. I think what I’ll do is use my intense (yet suttle) menu effect to set the global value by launching it in max detail and monitor the framerate and adjusting the global value accordingly (with the ability to override in the options menu).

Again I must say that your particle editor and mod really rocks. I’ve learned a bit more how to achieve the effects that I want and it packs much more power and flexibility than one might suspect – nice benchmark of what quality software should be like!

[Author]

Posts