• Advertisement

Archived

This topic is now archived and is closed to further replies.

Drive object example

This topic is 5991 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Chris, I was playing around with the drive object example. It runs really really slow on my Matrox Millinium card. It is 99% slow because the car.pro is fairly large. But even at around 9,700 vertices, it should still display at a decent frame rate. What kind of optimizations, can we introduce to increase frame rate? Is back face culling turned off? Can we tell pro''s, chr''s, textures, etc.. to reside on the card, if at all possible? What about Z buffer. Could we use it to perhaps reject many vertices? In a game, having a camera constantly on a very detailed item is realistic. Without suggestions, the engine is too slow to use. 10 objects on the screen at 10,000 vertices total is not asking too much. And this slow frame rate is before physics, AI, sound, collision detections, etc...

Share this post


Link to post
Share on other sites
Advertisement
>Is back face culling turned off?

No it''s turned on.

>Can we tell pro''s, chr''s, textures, etc.. to reside on the >card, if at all possible?

Not on a G400. Cards that have hardware T&L store the vertices on the card and are much faster.

>What about Z buffer. Could we use it to perhaps reject many >vertices?

Zbuffer works on pixels not vertices.

Keep in mind that 10,000 polys for a legacy card like G400 is going to be transformed by the CPU. Your CPU speed is probably going to be the biggest bottleneck.




Share this post


Link to post
Share on other sites
I was playing with the example a little more after I wrote.
I did notice back face culling was working.

I was under the assumption, that a G400 could do that via DX8.
Are you sure? It seems the that a Vertex buffer created with a FVF set to the right type would enable vertices to reside on hardware.

About the z buffer, I saw it too was on. Even thought, like you state, it does not reject vertices, it does reject a part of the pipeline. So it should run faster with it on.

So is how do we at least try to guarantee that at least textures reside on the card?

Also, the function PR_SetFogRange, does not do like it says.
The near_dist value has very little effect. When set to a high number, it does not seem to effect the fog as you drive around.
It''s almost like the fog is set in place, yet when you drive around, you can encounter heavier fog in patches, then have no close fog a few seconds later.
The far_dist works fine.

Share this post


Link to post
Share on other sites
are you running with 4 viewports ?

with 4 viewports, then i think you are transforming more than 10000 polys.

Share this post


Link to post
Share on other sites
No, the 4 viewports are almost irrelevant.
The program slows down a little more with 4, but not that much.

It''s the single viewport part that I was concerned with.

Strangely, if I set the PR_SetD3DPipline() function to zero instead of 1, it seems to run faster?

Chris, if you ever show us how to optimize an example with more FPS, this is the one I would like to see.

Share this post


Link to post
Share on other sites
I can''t really optimize D3D. When you''re using the D3D pipeline you''re giving it a list of vertices and indices and telling it to draw them. Not much I can do to speed that up.

If the PR pipeline is faster than the D3D one it sounds like poorly implemented drivers. The D3D pipeline should always be faster because it can batch primitives together and draw them all using one DrawPrimitive call, and the PR pipeline uses a DrawPrimitive call for each triangle.

The slow speed also could be from the 1024x1024 ground texture would could be made smaller.

Share this post


Link to post
Share on other sites
I wouldn''t be surprised if the drivers are bad.
The card sure is

It''s not the ground. If I replace the car.pro with something like rock.pro, the application moves along very smoothly.

Chris,
If you could give us tips, in document format somewhere (web/user docs) about potential PR optimizations of any kind that we can take advantage of, that would be great

Share this post


Link to post
Share on other sites
I found a bug that can cause vertices to be transformed even when the D3D pipeline is used in some cases. This would affect the drive example and hopefully you''ll have a nice speed up in the next patch.

Share this post


Link to post
Share on other sites

  • Advertisement