I don't see why performance degrades so rapidly when loading objects. This example program loads 4000 planes sequentially and hides them.
A few questions come to mind:
* Why is program fps impacted so severely when nothing is being drawn on the screen?
* If object x takes y seconds to load why should the 4000th iteration of object x take many more times the amount of time to load than the first? 4000 objects isn't all that many, really.
Object detail does not seem to affect frame rate. Comparing 4000 plains against 4000 spheres I get the same 97 fps.
This is quite sad, I think. There should be no reason for such abysmal performance as this.
sync on: sync rate 0
autocam off
global var
for n = 1 to 4000
make object sphere n,3
hide object n
var=n
UpdateScreen()
next n
do
UpdateScreen()
loop
function UpdateScreen()
text 10,10,str$(screen fps())
text 10,25,str$(var)
sync
endfunction
I'm running a Core 2 Duo E4300 with 4GB of DDR2 800 and a GeForce 8800 GTS and I get 97fps with 4000 objects sitting idle in memory and six characters being drawn on the screen.
I would like to bring back
this post for discussion. Performance is even worse when adding limbs.
sync on: sync rate 0
autocam off
make object plain 1,2,2
make mesh from object 1,1
hide object 1
make object plain 2,2,2
hide object 2
global var
for n = 1 to 200
add limb 1,n,1
link limb 1,0,n
UpdateScreen()
var=n
next n
for n = 1 to 200
add limb 2,n,1
link limb 2,0,n
UpdateScreen()
var=n
next n
do
UpdateScreen()
loop
function UpdateScreen()
text 10,10,str$(screen fps())
text 10,25,str$(var)
sync
endfunction
Because for whatever reason object loading is painfully slow and screen performance drops considerably even with idle objects, I considered using limbs instead because DBP seems to care less about the number of idle limbs there are than objects and does not suffer a considerable loss of fps.
Limbs however seem to have a compounded problem when loading too many onto a single object.
Quote: "Lee: Not convinced over the 'limbs rule, objects go home' argument. It is not recommended making any significant object construction code in your main game loop where performance is a factor. You do not want your end users waiting around for stuff that could have been done during a pre-processing step, or suffering lag due to run-time building of matter that could have easily been done before the tight game loop."
In my situation I tried to pre-process limbs but cannot create them in any significant quantity to provide a useful alternative to objects. Limbs are considerably slower to create than objects.
Oh, I suppose I could create 100 objects which hold 40 limbs each and cross-reference them to a different parent but that would be a ridiculous (although viable) work-around. That would allow me to link 4000 limbs to a single object in a fraction of the time. And for those of you who would disagree please bear in mind that I am speaking theory based upon what I believe DBP should be (more than) capable of handling.
http://3dfolio.com
