Speed optimization question!

Is the object a single (same) color at each vertex? If so it would be a lot faster to just change the Material
As for the other answer, it would definitely be faster to have each colored object defined itself, but you''re trading speed for memory. If geometry has to be stored in non-local memory (AGP) then you will suffer a speed hit having to transfer the data across the bus, but if you''re locking to change the vertex colours you''re going to be sending a lot of data across the bus anyway, but not quite as much. But you also need to add the cost of the buffer lock, which may be quick or very slow depending on if the gfx card is currently accessing the buffer or not.
Short answer, don''t lock a static buffer every frame!
CYer, Blitz

Needs more detail. Remember that you can also adjust the memory offset.

Ok each vertex inside an object has the same color.
So i guess that means i should use materials.
Maybe you could give me a short code example cause im not too familiar with materials.
Thanks a bucnch in advance

-CProgrammer

dont even worry about it. make the vertices white (or just drop the color at all because obviously you dont need it). call glColor with the color you want and draw your object. if its not enabled by default enable colormaterial. if using d3d it should be the same (i hope) with different names.

Thanks but i dont use opengl.
Anyone got a code example for d3d.

D3DMATERIAL myMat;
ZeroMemory( &myMat, sizeof(D3DMATERIAL) );

// set the emissive colour to the colour you want, and all the

// others (diffuse, ambient, specular) to 0.0 (done with

// ZeroMemory). This means the object will always be the same

// colour regardless of any lighting

myMat.emissive.r = 0.5f;
myMat.emissive.g = 0.1f;
myMat.emissive.b = 0.6f;
myMat.emissive.a = 1.0f;
// etc.


// Lighting must be on to use materials

D3DDevice->SetRenderState( D3DRS_LIGHTING, TRUE );

// Set the material to use

D3DDevice->SetMaterial( &myMat );

// render your stuff here


// You should set the material back to the default material after

// you have finished rendering in case other objects want to

// use the default material

D3DDevice->SetMaterial( &defaultMaterialSeeD3DDocsForInfo );

Thats pretty much it. The only *bad* thing about materials is that lighting must be on to use them. However, if you have zero lights added to the device, i can't see that it would cause much of a performance hit. And you don't have to include 4 bytes of vertex colour data with each vertex! saving you 4 bytes/vertex of video memory!
CYer, Blitz

[Edit] PS. One last thing, when setting back to the default material, don't (as i once did naively) just call SetMaterial( NULL ) as this will just result in an INVALID_CALL error.

[edited by - Blitz_Krieg on September 7, 2003 10:09:02 AM]

Many older cards don''t support TFactor. And publishers still want support for those cards. Material colors is the better option. And if you can get away with using vertex-shaders you can define colors however you want.

quote:

---

Original post by Namethatnobodyelsetook
Many older cards don''t support TFactor.

---

IMO that should be:

"Though many older cards do support TFactor in hardware, older drivers were particularly flaky in handling it - in one driver revision it''d work fine. In another only the first TFactor of the frame would be used for the rest of the frame regardless of subsequent sets. In another it''d be intermittent and so on"



--
Simon O''Connor
3D Game Programmer &
Microsoft DirectX MVP

I don''t have a complete list of cards, but I do know of one specific card (because the publisher wanted us to support it). ATI RagePro cards (XPert98, and similar cards) using the latest drivers. Our product went out late last year. I''m assuming ATI hasn''t done new drivers for such an old card within the last year.

So, old in this case means 5 years old. There are still lots of people with those cards. If your game isn''t taking advantage of all the latest tech, and is more a casual gamer type game, or a kids game (kids usually get handed their parents old hardware) you''ve got to make sure you support all the weirdness of cards from that era.

Thanks a bunch everybody.
Well compatibility is important to me so i guys ill have to use the materials. One question though! Will me Enabling Lighting make the game less compatible? Are there cards that dont support DX8 lighting?

edit: Aw changed my mind TFactor's more elegant because it just uses much less lines of code. So ill stick to TFactor.
Thanks again

[edited by - CProgrammer on September 8, 2003 5:15:32 AM]

There are cards that don''t support trasforms and lighting in hardware (everything pre GF256?) but, if you set your device to use software vertex processing, then the transforms and lighting are done by D3D on the cpu, so no problems, it''s just slower than on hardware
CYer, Blitz

Thnaks Blitz_Krieg

AP: Your absolutely right. My app doesn''t use lighting. All i need is colored vertices, so i''ll go with TFactor. Is there a way to check whether TFactor is supported on a comp. Using caps maybe?

-CProgrammer