RenderWorld slowdown problem

Blitz3D Forums/Blitz3D Programming/RenderWorld slowdown problem

WildCat(Posted 2009) [#1]
Please, can anyone help me to find out a cause of slowdown of my Blitz3D application? The situation is that everything's fine when I run it alone (25-50 FPS). Then I want to run another Blitz3D app behind it, say it's my gameserver. It doesn't take much CPU time, it doesn't even use Graphics3D mode. After all, it checks if it's in a background and if so, it doesn't draw anything at all!

Well, when I run my game having this 'server' started, the game slows down to 2-3 FPS. Finding a bottleneck shows that the RenderWorld command is executed too long (over 200msecs).

This trouble happen first on this hardware: Intel Pentium 4 CPU 1.6Ghz (single core), nVidia 7600GS AGP 256Mb VRAM, 1Gb RAM. Before this, everything was fine on dual-core computers, even with integrated video...

My scene consists of over 30K tris and there are some heavy textures 2048x2048 and 1024x1024. But the difference is too large to my mind, taking into account that the second application ('server') doesn't use much CPU nor GPU time and doesn't operate with much data...

So, who can tell me where should I find the clues?


WildCat(Posted 2009) [#2]
And there's one funny addition. If I run my 'server' _after_ the game, this doesn't slow it down absolutely!! Both apps run well!


GIB3D(Posted 2009) [#3]
I'm not sure where I got this from but it helps. You can run more than one program at the same time without totally slowing your computer down. I'm guessing you can add this to your program yourself ;)




big10p(Posted 2009) [#4]
Blitz3D apps hog as much CPU time as they can get, even if they don't need it. You can return CPU time to other apps by putting a small Delay in you main loop/s.


WildCat(Posted 2009) [#5]
Of course I do Delay in both apps. When I detect if it runs background I do Delay twice ;)


jfk EO-11110(Posted 2009) [#6]
Seems to be Renderworld is interrupted by the other app frequently. No surprise, cause in a real game the whole loop with renderworld takes easily 17ms, sometimes 33. If the gameserver is using Delay 1 or 2 then it's likely rendering will be interrupted. What you could do is (well just an idea) use a variable that is accessible by both apps, somewhere in the ram. May be an enviroment variable, or use RtlMoveMemory with a userlib, however. Before you start Renderworld you set it to 1, then after the Render to zero again. The server may then check the variable and use a delay of the expected render time instead, if the variable was set to 1 recently (or, as a further approach: if it was set to the expected render time, instead of 1).

But as I said, if this is gonna help, that's really only a guess.


WildCat(Posted 2009) [#7]
Thank you, JFK, you're giving good direction to explore! Well, if we'll suggest that the game app is being interrupted, why no other commands take more time to execute, only this damn RenderWorld? :) Ok, ok, researcher's blood should be cold :)

Please, if you can, explain also why we've got no slowdown when we run the game first? I have to discover which specific action of the server does interrupt render process...


jfk EO-11110(Posted 2009) [#8]
I have absolutely no idea why there is no slowdown the other way round. It sounds strange. Probably some Priority fights.

Basicly you should be aware that there are 2 DirectX Windows running. Windows must combine both for one graphicscard. I am no expert on this special subject, but I guess there is some kind of List of things to render, including the 2D stuff. Although this behaviour is bugous, it may play a role if you render 2D after 3D or 3D after 2D.

I would suggest you reduce a set of two testapps to the min, in order to isolate the bad stuff, and to get clear reproducable results. EG. A simple cube/camera 3D app and an other simple cls/rect 2D app. (Does your server do any 2D graphics anyway??).

You may also try to Hide the server window using the WinAPI commands (wasn't that HideWindow?? however) and see if it makes a diffrence.