Jump to content
Sign in to follow this  
  • entries
  • comments
  • views


Sign in to follow this  


Just came home from the exam, to be honest it was quite a weird test. Some of the wording in the test itself I did not understand. Hopefully its a pass, but i am a little "neutral" on the result of the test. I know I got the C++ pretty spot on. But i think the DirectX questions were a bit too deep for me to figure out without having the documentation with me.

In an interesting talk with the other groups we program with, we had one programming group who basically uses 8 buffers to stimulate multiple windows. I was a bit unsure on why the heck he done that, Back buffers are more meant to be used in animation and for a smooth screen transistion but using 8 for that is just flat out impossible, it means you limit your possibilities extremely, and the performance inpact would be dire on your videocard.

Our group went with a Windows API approach using a linked list to keep track of the multiple windows, and creating multiple D3D Objects for each window meaning that they all have their own Rendering device, but they share Textures, and Meshes using the pointers in another linked list called the Mesh Manager, and Texture Manager. These 2 get combined into another Linked list called Entity Manager which keeps track of all the entities flying around on the map. Our approach is basically the same thing, but we went with it through different paths. I personally think our approach is faster, but I have no clue. I might have misunderstood what was said.

I am just playing world of warcraft the Burning Crusade before delving back into vyper hopefulyl I can release a new batch of code for people to look at. this release MIGHT have the textured battlestar with it. Next monday is the release meaning we have to get our act together and done. Probably this will be done without too much hassles.

Sign in to follow this  


Recommended Comments

Does Direct3D not have a glViewport equivalent? Maybe I'm mistaking your problem.

Share this comment

Link to comment
the goal of our 3D engine is basically to have multiple windows each with its own scene. and one class the kernel basically manages everything what windows are focused etc.

What we did was just make a new instance of each windows procedure and then stored the HwnD and then we just kept on telling the Direct3D object what Hwnd to update with new information. so basically what we have is multiple instances going through the same 3D engine.

The group basically used buffers to solve their problem. Each new window opened is basically aa new buffer.

Share this comment

Link to comment
Guest Anonymous Poster


Why didn't you use swap chains?

Share this comment

Link to comment
Guest Anonymous Poster



They are used for rendering to multiple windows.

Share this comment

Link to comment
ah, no we did not use that as a way to do it.

What we basically done was as follows, first we create a console through the Windows API, from there we fetch its HwND and designate that the parent window. For every Window we want to create we make a new WNDclass with the same name and basically put the HwND it outputs from the Create Window function into a LinkedList.

Now our DirectX gets initialized once, basically when one of the Windows need to be update we fetch its HwND and send it to directX along with anything else that needs to be programmed in. I dunno which of the two is faster, my goal is ofcourse to go for speed, but i would think this would speed things up as the windows will not be updated unless they have focus, and they are getting instructions otherwise the world is just static. In the actual game ofcourse, you want one window open and one console for debugging only :)


Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!