How can i make it faster?

Started by
5 comments, last by Pet123 21 years, 2 months ago
Several days ago i found an interesting demo piece which was written in opengl. it was a dynamic-created tunnel. so i decided to rewrite it with directx and i made it(vc++ 6.0). but the thing annoying is that the framerate is only 26 much lower than the 76 of its original opengl version(delphi). this thing also cause me to think why the game cs is much faster when using opengl and the texture quality is also better. i dont want to give up using directx but can here anyone explain why directx is slower in many ways? and how can i make it faster by using directx(at least as fast as in opengl)? thank you. 1.the tunnel has 32x12x4 vertices and 32x12x2 faces, 2.the vertex format is {x, y, z, diffuse, u, v} 3.all vertices will be updated every frame. /// Methods Intro Starts here Method 1 : Using a mesh 1. create a mesh with apporiate face number and vertex number. (using D3DMESH_WRITEONLY Flag, and 'mixed-vertex-processing' used when create the direct3d device) 2. optimize the mesh in place 3. call lockVertexBuffer every frame and fill in with new updated vertex info then unlockVertexBuffer. drawSubet(0) (only one texture applied) Method 2 : using DrawPrimitive 1. create a vertex buffer with required vertex number 2. call lock method on the vertex buffer each frame and fill in new vertex info, and unlock the buffer, then SetStreamSource, DrawPrimitive method 3 : using Transformed vertex same as method 2, but using DrawPrimitiveUp /// Intro Ends here thats all i have used to draw the tunnel, nothing special really. and all three methods i get a framerate of 26, fullscreen or windowed. [edited by - Pet123 on January 29, 2003 12:36:52 PM]
Advertisement
Well i dont really know what to say. The way you use a vertex buffer is not the only thing that could effect performance. Maybe your bottleneck is somewhere else in your code. Maybe the drivers your gfx card is using is optimised more for opengl then d3d. maybe the card manufacturer is anti-d3d ... i dunno.

look at other stuff. Maybe you''re not handling the vertex buffer as best as you can. although there really isnt a best. You''ll just have to experiment and test until your eyes become all red and puffy and by the time your white blood cells have adapted to caffeine ... well ....lets hope that never happens


:::Al::: [Triple Buffer V2.0] - Resource leak imminent. Memory status: Fragile
[size=2]aliak.net
@ Pet123, depending on the number of vertices that you are passing several bottlenecks can occur. First make sure you let D3D know that you need a dynamic VB, it''ll make some internal optimizations that will grant you speed. Next, and this is something i have only noticed when cycling a BUNCH of point sprites. Sometimes it is faster to allocate X number of vertices and draw, then X more and draw, etc... sometimes you can have your CPU dogging along while your GPU is waiting for something to do, which is non-optimal. experiment with different percentages being sent and drawn and compare that with a single lock, populate, and draw routine. Finally, unless you are looking at the raw Cpp code itself, keep in mind that Cpp optimizations are the closest thing to witchcraft a good programmer will ever delve into, you can pass by ref, and by pointer till your blue in the face, each time picking up a bit of speed, and then you ask yourself "OK, now what to inline?"
"Let Us Now Try Liberty"-- Frederick Bastiat
The speed of DX or GL is greatly dependant on your video card drivers.

That said if your seeing a preformance decrease like that I''d suggest that you are doing something you weren''t supposed to do. Examples of this would be doing some rendering ops out of order. Check your code and make sure your not using vsync.
Be sure you are compiling to Release mode and using the retail version of DirectX. If you have been using the debug versions, you should see a increase in performance after the switch.
IFooBar:

I have two rules for my free anonymous FTP

1. Put the files in the right directory
2. Link using http://www.icarusindie.com/ftp/

guess which one you didn''t follow.* Fix it.

Thanks,

Ben

*number 2


IcarusIndie.com [ The Labyrinth | DevZone | Indie Mail | Hosting | Tiberian Merchandise | GameShot | Fun With Cutouts ]
quote:Next, and this is something i have only noticed when cycling a BUNCH of point sprites. Sometimes it is faster to allocate X number of vertices and draw, then X more and draw, etc...


yeah, I noticed this with my particle system. I was pushing all the point sprites into the buffer, and when i pushed ~250 at a time, there was quite a difference in performance, so this does infact have quite an effect. Also make sure you are using NOOVERRIGHT and DISCARD flags appropriately. I didnt use it for my particle system, but if I had, Im told I wouldve gotten even more performance.

if( maxSize > ( vbSize + vertsToRender )
use NOOVERWRITE flag;
if( maxSize <= ( vbSize + vertsToRender )
use DISCARD flag;


You have include how many vertices you are going to render _this_ frame in the calculations...

quote:
IFooBar:

I have two rules for my free anonymous FTP

1. Put the files in the right directory
2. Link using http://www.icarusindie.com/ftp/

guess which one you didn't follow.* Fix it.

Thanks,

Ben

*number 2


sorry ben, my mistake

[edit] other linkage not working [/edit]

foo screams at kALVINb telling him to die, but he gets a heart attack from screming too loud and dies

::: Al::: [Triple Buffer V2.0] - Resource leak imminent. Memory status: Fragile


[edited by - IFooBar on January 30, 2003 5:16:12 AM]
[size=2]aliak.net

This topic is closed to new replies.

Advertisement