GetRenderState

keep your own array of states you are interested in. creaet a macro or function to call instead of SetRenderState which converts the enum into your own array index.

if you want to know how slow it is, i would just create a loop to switch a state from on to off about 1000 times and look at how long it took.

if you want to be dead accurate in terms of CPU cycles, use the RDTSC instruction (inline assembly) before and after

Also be careful when using a pure device. When using a pure device you minimise the state querying ability of your game or application. That is, a lot of the Get* calls will not work.

Regards,
Sharky

How would you know what state everything was in then? The renderstates you could work from the defaults and keep track of any changes, but how would you know what capabilities the card supported? Though I guess you can call GetDeviceCaps from the D3D object, not through a device created from it - that way you get the caps before creating a pure device.
Though why would you want a pure device? All I''ve read about it is that it doesn''t support Get calls - is there any advantage?

---

Read about my game, project #1

NEW: see my progress from last week - join the mailing list to get this and other updates every week!

---

John 3:16

one thing that ive noticed is that when the debug level is at its highest and there is an unnecessary state change, the debug output says that the call has been ignored.

Whether or not this happens for a pure device or in release mode though.....

quote:

---

Original post by d000hg
How would you know what state everything was in then? The renderstates you could work from the defaults and keep track of any changes, but how would you know what capabilities the card supported? Though I guess you can call GetDeviceCaps from the D3D object, not through a device created from it - that way you get the caps before creating a pure device.
Though why would you want a pure device? All I''ve read about it is that it doesn''t support Get calls - is there any advantage?

---

You have answered your own question right there - you can check the device for capabilities, etc. As for states it is a case of setting them to known values that are required by your app and implementing some housekeeping routines to manage/update/set them as desired.

Why would you want a pure device? As with most things it depends on the situation and what you are wanting to achieve. A pure device will give you hardware processing only - which is not a bad thing. And the lack of Get* calls is not too serious an issue. It is generally a lot quicker to (for example) maintain your own transformation matrices (view, world, projection) and get/set them using your own code than it is to use a slower GetTransform call where the state has to be queried from the card and over the bus. The last few commercial D3D games I worked on all happily used pure devices (hardware permitting) and ran without problem. Ok - I am rambling now - has been a long few days.... I hope this makes sense. Zzzz zzz zz

Regards,
Sharky