Show differencesHistory of post edits
#ActualNik02
Posted 29 January 2013 - 02:46 AM
For a small list of objects this may seem like overkill, but if you have many similar objects you can sort their rendering by the states they use (commonly known as "batching"). This potentially saves a lot of user->kernel transitions (driver calls) - those can eat your cpu cycles fast.
---
Note that if you use ID3DX10Font (this is not apparent in your code), you can use a sprite object that you previously allocated in order to store the font's render states. The sprite object uses a Begin/End pair; the Begin method lets you specify that upon calling End the device state is restored to pre-Begin state. So if you surround the font drawing with the Begin/End of its sprite, you can control whether or not it resets the state for you.
All that said, you can potentially save performance if you still do the state sets manually only when you actually do need to set them. You see, resetting takes the same time or more as setting.
#2Nik02
Posted 29 January 2013 - 02:46 AM
For a small list of objects this may seem like overkill, but if you have many similar objects you can sort their rendering by the states they use (commonly known as "batching"). This potentially saves a lot of user->kernel transitions (driver calls) - those can eat your cpu cycles fast.
---
Note that if you use ID3DX10Font (this is not apparent in your code), you can use a sprite object that you previously allocated in order to store the font's render states. The sprite object uses a Begin/End pair; the Begin method lets you specify that upon calling End the device state is restored to pre-Begin state. So if you surround the font drawing with the Begin/End of its sprite, you can control whether or not it resets the state for you.
All that said, you can potentially save performance if you still do the state sets manually only when you actually do need to set them. You see, resetting takes the same time or more as setting.
#1Nik02
Posted 29 January 2013 - 02:37 AM
Just before you draw your objects (at each frame), set all the states that affect the rendering of said objects. These include input assembler settings, rasterizer state, blend state, output merger state, shaders, views, textures, samplers, buffers, input layout (and some others). Rendering text usually sets some of these states, and in your case the font object isn't apparently resetting some of the states after drawing; this is why you need to do it.
For a small list of objects this may seem like overkill, but if you have many similar objects you can sort their rendering by the states they use (commonly known as "batching"). This potentially saves a lot of user->kernel transitions (driver calls) - those can eat your cpu cycles fast.
---
Note that if you use ID3DX10Font (this is not apparent in your code), you can use a sprite object that you previously allocated in order to store the font's render states. The sprite object uses a Begin/End pair; the Begin method lets you specify that upon calling End the device state is restored to pre-Begin state. So if you surround the font drawing with the Begin/End of its sprite, you can control whether or not it resets the state for you.
All that said, you can potentially save performance if you still do the state sets manually only when you actually do need to set them.