Modify dxDraw(Material)Primitive to use same queue as other dxDraw functions #565
Conversation
|
|
||
| // Set states | ||
| m_pDevice->SetRenderState(D3DRS_ZENABLE, m_bZTest ? D3DZB_TRUE : D3DZB_FALSE); | ||
| m_pDevice->SetRenderState(D3DRS_ZENABLE, D3DZB_TRUE); |
There was a problem hiding this comment.
Depth-buffering is not required for 2D draws, so D3DRS_ZENABLE should be set to D3DZB_FALSE
There was a problem hiding this comment.
I was thinking about stuff like this: https://www.youtube.com/watch?v=CbJerQJBM0M where 2D images, or in this case primitives are placed in 3D world using shaders.
There was a problem hiding this comment.
By convention, the 2D drawing functions draw in front of the final world render (The video shows the logo always in front of the car). So the depth buffer should be
disabled by default.
For drawing primitives in the 3D world, we could add dxDrawPrimitive3D (similar to dxDrawLine3D)
There was a problem hiding this comment.
no we could, we must add 3d version
There was a problem hiding this comment.
Fair enough, disabled the depth buffering for material primitives :)
|
You did a very great job with refactoring code. Looks much better. |
patrikjuvonen
changed the title
|
Thank you! |
5 participants
This pull requests is my suggestion of fixing #434.
Instead of using separate queues for primitives, they are now processed along with other dxDraws.
I had some problems with not being able to use smart pointers, due to the fact that draw queue items are stored as union, and they ain't that happy with unique/shared_ptr's. I would be glad if someone with more c++ experience looked over the code to confirm that it's the correct way of solving it.
There's a simple screenshot showing that the order is properly processed (rectangle > primitive >primitiveMaterial > rectangle):
This pull request also includes a bit of code cleanup for primitive batchers, as well as CLuaDrawingDefs.cpp primitive functions.