sponsors gamedev.net search:

Step 2: Our OpenGL implementation Because we're covering this information as more of a "proof of concept" rather than a full-blown implementation, we're only going to stick to the 1.1 implementation of OpenGL. Therefore, we don't have to concern ourselves with the extension mechanism of the user's hardware. An exercise for the reader might be to implement a vertex array mechanism (if the hardware supports it), within the implementation of our OpenGL vbInterface. Step 3: Our Direct3D implementation Again, there's nothing too advanced for our Direct3D implementation of our vbInterface. The SDK samples as well as the material contained within the MSDN has provided us with a way to create a way to encapsulate the LPDIRECT3DVERTEXBUFFER8 interface. Rather than simply wasting our graphics pipeline by sending one or two primitives at a time, we'll create a way to batch our primitives together (as is the preferred method plainly discussed in SDK documentation as well as vendor developer sites such as nvidia.com). Again, this isn't too hard a task. We'll set a boundary variable, and keep adding primitives until we hit the boundary. Then we send that batch off to the graphics pipeline, while setting up the object to receive new triangle data. Feel free to browse through the code to get an idea of where we're going. (Note: The only thing to note of importance here is that for our Direct3D implementation I decided to use the D3DXMatrixRH* methods for calculating the resulting projection matrix. Remember that by default Direct3D is Left-Handed, while OpenGL is Right-Handed. To keep the z-plane information the same, I just switched the Direct3D calculations to use the Right-Handed functions). Step 4: Test out the interface! Now that we've finished an OpenGL and Direct3D implementation, it's time to put this thing into gear! We don't really need to do much to get it working within our framework. For the moment, we're just gonna render a simple square to the display. //winmain.cpp //we just need to modify the renderProgram method to include //the newly created vertex buffer interface code //first lock down an area in video memory if(SUCCEEDED(pInterface->m_pVB->lockVB())){ pInterface->m_pVB->addTriToVB(D3DXVECTOR3(-1.0f, -1.0f, -10.0f), 1.0f, 1.0f, 1.0f, 1.0f);//bottom-left vertex pInterface->m_pVB->addTriToVB(D3DXVECTOR3(-1.0f, 1.0f, -10.0f), 1.0f, 1.0f, 1.0f, 1.0f);//upper-left vertex pInterface->m_pVB->addTriToVB(D3DXVECTOR3(1.0f, -1.0f, -10.0f), 1.0f, 1.0f, 1.0f, 1.0f);//lower-right vertex pInterface->m_pVB->addTriToVB(D3DXVECTOR3(1.0f, -1.0f, -10.0f), 1.0f, 1.0f, 1.0f, 1.0f);//lower-right vertex pInterface->m_pVB->addTriToVB(D3DXVECTOR3(-1.0f, 1.0f, -10.0f), 1.0f, 1.0f, 1.0f, 1.0f);//upper-left vertex pInterface->m_pVB->addTriToVB(D3DXVECTOR3(1.0f, 1.0f, -10.0f), 1.0f, 1.0f, 1.0f, 1.0f);//upper-right vertex //we're done with the video memory, so unlock it pInterface->m_pVB->unlockVB(); } Once we run the code (with either Graphics DLL specified in the .ini file), we'll see our main window with a white square centered on a blue background! Conclusion As you can see, this isn't a bad way to go for our cross-graphics API rendering DLL system. We've made an attempt at providing a solution to render triangle primitives in both OpenGL and Direct3D.

Contents   Introduction   Conclusion   Source code   Printable version   Discuss this article The Series   Part I   Part II   Part III   Part IV