• ### Announcements

#### Archived

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

# Problem with Rendering - very slow

## Recommended Posts

W    122
I just want to display a (static) mesh of 200 vertices. The problem is: it''s awfully slow (1 frame in 2 or 3 seconds) As I know that this mesh can be done much faster on the same machine I''m wondering what''s wrong with my code. I have: D3DRS_CULLMODE=D3DCULL_NONE (which is required) D3DRS_LIGHTING=FALSE D3DRS_ZENABLE=TRUE My device is using AutoStencil, REF and SOFTWARE_VERTEXPROCESSING (but another vertex proc doesn''t do it either) I''m using a 16 bit index buffer. What I have realized is that everything gests faster when I move the object out of sight. Does anyone have an idea hot to it the right way?

##### Share on other sites
CrazedGenius    156
This is the correct behavior for the REF device. Read the docs for the explanations of what each device setting does.

The REF device is a reference device that is very slow.

##### Share on other sites
PiXeLatiOn    122
Use HAL instead of REF and your problem will be solved.

~The fastest polygons are those you don''''t draw...~

##### Share on other sites
Guest Anonymous Poster
HAL behavior is faster indeed, but rendering is done completely wrong and effects don''t show as I want. (Some triangles are drawn, some others are not, if textured, it looks completely rough)
I see that other games are doing perfectly fast rendering (on the same machine of course). Are they using HAL too?
If so, why isnt it working with my prog - that is very simple.

##### Share on other sites
Terren    122
Make sure you are clearing the Z-buffer every frame; you have the z-buffer turned on, so you need to clear it at the same time you clear the color buffer.

I think this could solve your problem

##### Share on other sites
W    122
Thats the code I'm using for clearing:

    lpD3DD8->Clear    (      0,                        // Count      NULL,                     // pRects      D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER,// Flags      D3DCOLOR_XRGB(0, 0, 0),   // Color      1.0f,                     // Z      0                         // Stencil    );

(The use of other Z values than 1.0f causes rendering nothing)

HAL mode is fast -- I have no problems using POINTLISTs, LINELISTs or even TRIANGLELISTs as long as I use
DrawPrimitive(...).
The problem occurs with DrawIndexedPrimitive. Then only "clipped" triangles are drawn properly, all other are invisible. (clipped means that at least one vertex lies out of the visible box)

[edited by - W on May 3, 2002 11:52:27 AM]

[edited by - W on May 3, 2002 11:52:52 AM]

##### Share on other sites
a person    118
well if ref is working right and you are 10092020910192% sure your code is perfect. then blame your drivers. check your devicecaps and make sure your buffers are not too big. also make sure you that you are calling things correctly. i think its an issue of doing things that the card cant handle. check all error messages. ussually if ref is working, hal should work assuming you are not doing anything not supported by your card.

NEVER use REF for anything except testing for an effect. its not meant to be used for anything except testing things your video card cant handle, or to check and make sure the driver you are writing is doing things correctly to spec(not saying you are writing one, but hardware vendors)

btw why is no culling required? you should make sure you have your vertices properly oreinted (ie clockiwse or counterclockwise).

[edited by - a person on May 4, 2002 2:16:31 AM]

##### Share on other sites
W    122
you were absolutely right - i was using 32 bit indices - then I switched to 16 bit and everything worked fine...
The strange thing is that the board signals capability of 32 bit indices.
We already had a similar discussion a few months ago:
"~ 32 bit isn''t really implemented => use 16 bit indices"
I thought this problem was solven with the new card driver release... that was my error