Sorry your browser is not supported!

Ive been working with loading in 3d objects and testing to see how they affect framerates. There are some oddities here,..such as,..

1. 3D objects effect frame rates from the time they are loaded into the game?
I dont even have to display the object, DBPro takes a mega hit in fps by just loading in objects,..i test loaded in 3000 objects and the framerate dropped from 148 to 115. None of them were displayed.
Any reason why the fps would be effected like this? Storage of object information should not lower frame rates, unless some testing is happening. Even if I Hide all of those objects,..the frame rate remains the same as when they were loaded. (im using simple textured plane objects.)

2. The Object visible command seems to check to see only if the object is in the SHOW OBJECT state. At first I thought it might check to see if an object is in the cameras path, but it dont. I tried Object In Screen testing to turn off objects that arent viewable to the camera,..but then once they are in the Hide state, they cant be detected by that command to turn them on again,...(bear with me Im learning here) I guess these commands are used to see if u can successfully mouse click on an object.

3. so then I tested Cloneing and deleting objects on the fly but the Delete Object call is mega slow,..so the fps hit drops down to about 35 from 90 while deleting the object....


4. Hide/Show Object is pretty fast, but I found a faster way to hide an object. Y drop the object out through the ground level, instant invisible. Now if there was a Position Object Y command,..hmmmmmm
I cant imagine it is faster,..Hide must use some kind of bit testing by dbpro to see if it is to be rendered or not. bit testing should be infinitely faster than shifting y coordinates,..however it works hehe.

Mind you 3k objects is a lot of objects, however, until the object is turned on it should not represent a fps shock to the game. I cant imagine checking to see if an object is "enabled for rendering" should eat up framerates,...anyone know why??

The objects are not truly static, they are still dynamically changeable and are therefor processed by the DBP engine. I would like the ability to make objects static like in DBC, but the commands where considered obsolete, probably due to internal engine constraints.


Correct, and object in screen() tests whether they are in the view area. Object in screen() should work on an object in the hidden state without problems, it always has for me.


It is probably the clone object that is slow. I have not done a specific speed test on these commands, but I dont find having regular (although never constant) delete object commands slows things down, creating a new object whether by loading, cloning, or assembling in a memblock, always takes a while.


Interesting concept and I will try it, but would better results not be achieved by both hiding the object and repositioning it outside of the viewplane?

1. 3D objects effect frame rates from the time they are loaded into the game?


Yes, I noticed this too. There's really no valid explanation for it. Structurally the created objects are stored in a list/que. During a sync, one thing that might explain a drop, could well be that even while hidden, objects are still translated to the camera before being rejected for rendering, or there's some texture overhead for some reason. Something similar also happens in DB classic.

2.

From memory, you need to position/enable the object as visible, before it'll get a valid in screen result.



3.

if you want to create caches of cloned objects, use the instance object (or something similar) command. It's meant to create a new object that effectively points to the parent objects data. Thus sharing mesh/texture data, while having it's own position/rotation etc. It should be faster to create. Also, Rather than delete object at run time. Hide and cache them.

i.e.

So bullet object numbers for example, would be held a list maintained by you. The list is pre-created with a cache of say 25/50 instanced objects. To get a new object you pop current free object from your cache list. (linked list). If there's none, you instance a new object and add it to the cache list. There's no searching, as object numbers would be handled through a parent list.


4.

It depends on where the object hidden flag is checked during the
translation pass. If the object hidden flag is checked after the bounding volume to camera tests, then positioning it far off camera and hiding could well be faster. Since it'll fail the bounding test first and exit there. But you'd have to assume that Mike would test the hidden state first surely..

Great stuff,..and really helping me confirm some dbpro concepts.
I tested the instance objects today and gained a sizeable 10fps over using clones. The fact that the original objects data is accessed probably saves on object memeory space as well. I assume (hate that word) that dbpro simply redraws the original object and does not actually store a copy of that instance object in memory.

In a loop,..where I loaded in one instance object at a time, the frames dropped by 10 after 320 instances were created. I tried that using hide object,..but will redo it using position object,..where i throw the object right out of the cameras range.

Although, even with all of this,..the frames drop considerably when i try to populate the ground with enough grass objects to make it look realistic. Calculating a reasonable clipping distance so that the grass doesnt just pop out of nowhere,...i would need about 1000 grass objects to do the trick. That pulls about 60 frames minimum out of the loop. (did all the camera tricks to,..and fog,..hmmm fog doesnt seem to do anything to the framerate at all, except maybe drop it by one!!,.. - another curiosity)
Now if the grassy bits were actually sprites,..and i could prioritize the sprites with the 3dobjects then i could easily map in that many sprites between the ground and player objects to create a realistic look. Using the spirte as a 3d object just incurs too much overhead. Prioritizing the draw in of objects and sprites should be possible,..i think a few other packages do that. as it is now,..we get two priorities only,..Under the 3d objects or over them. Under is ludicrous unless u dont have a ground map,..and over can only be used to simulate panels, text etc,...
hmmm maybe ill try making the ground out of sprites,...(hehe)