Archived

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

Slow D3D application

This topic is 5516 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

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

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites