Slow D3D application

Started by
7 comments, last by Trond A 21 years, 5 months ago
I have created a D3D application, and it''s using ortho projection (2D). I find it odd that it''s so incredibly slow, I get an average of 30fps, and all i draw is a screen covered with 128x128 textures and a couple of sprites at 64x64. Games like Wolfenstein, SOF2, Warcraft 3 and other new games run fine, so it kind of bothers me that my simple program runs so damn slow! I use the drawprimitiveup function, and I do a position transform each time I draw. Are there other ways that will make the program go *very* much faster? The computer is at 1100mhz, and I don''t think the d3d support is bad, the gfx card is an Intel 830 something (laptop). Thanks in advance for any help! -Trond
-Trond
Advertisement
DrawPrimitiveUP is extremely slow, create a static vertex buffer and render with DrawPrimitive. That will be *very* much faster.

If you''re gonna render more advanced scenes, use indexed data and draw with DrawIndexedPrimitive.

-meZ

PS: Heia Norge!
Mange takk! Ufattelig raskt svar
-Trond
Håper det hjelper deg. Det kan jo være andre saker som er feil, men DrawPUP den største av DX-syndene. ;-)
I have a new question on the same topic... Would it work to make one vertexbuffer for each object, since I need different texture for each object(at least most of the time), or would I need to throw them all into as few buffers as possible? Will it be faster than drawprimitiveup anyway? The function "drawprimitive" used to draw vertex buffers kind of indicates that it draws primitives... not necessarily a whole bunch of them? I hear that unlocking and editing of vertex buffers is bad, but it needs to be done if I must have many objects in one buffer...

Thanks again!
-Trond
-Trond
Mostly anything is faster than the UP functions. But just throw them all in a big VB. DrawPrimitive takes startvertex and vertexcount as parameters, so you can just draw a subsection of your VB, change renderstates, then draw another subsection. Do order your data first, though, so you don't end up setting renderstate "A", then "B", then "A" again.

Yup, the DrawPrimitive can draw primitives, in plural. One, or as many as you want.

Why would you need to edit your buffers to have many objects in one buffer? Create your buffer, lock it once, filling it with all your data, unlock it and never touch it again. The really "bad thing" you've heard about is locking the buffer each frame (or even multiple times each frame). Locking the buffer multiple times at load-time is ok (but not ideal, the dx runtime might do something crazy like move your VB from video memory to AGP memory).

Hope this helps.

-meZ



[edited by - meZmo on November 9, 2002 7:29:50 PM]
Ja no kjørvar det åt seg noko ovhuttes
attom smorvkorkjan til dømes
tbh i dont find DrawPrimativeUP that slow, and i feel it''s getting a bad rap here. Maybe it''s just certain graphics cards (im on a matrox g400 16mb).

I was running a game at 70fps with about 30+ calls of DrawPrimativeUP per frame.
And im using a 400mhz with 256mb ram.

HOWEVER, i have recently found my ortho drawprimativeup() game is running about 4 times slower than it did before (i havent changed ANYTHING).

I can only assume this is a problem with DirectX 8.1 / WindowsXP

Aaron.
Both nVidia and MS (and I''m assuming ATI) are very emphatic about NOT using the ..UP functions. They might run fast enough, but they are nowhere near optimal.

Author, "Real Time Rendering Tricks and Techniques in DirectX", "Focus on Curves and Surfaces"
Author, "Real Time Rendering Tricks and Techniques in DirectX", "Focus on Curves and Surfaces", A third book on advanced lighting and materials

This topic is closed to new replies.

Advertisement