Jump to content
  • Advertisement
Sign in to follow this  
Bob_the_dev

What's a good approach to the main program?

This topic is 3851 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

So I read through (several times) a great introduction to DirectX 9, played around with the books examples, and decided to start building my own DirectX program. Almost immediately I was stumped on how to handle the main functions. The examples from the book wrap everything in a class and simply inherent and overload functions needed for the specific example. But the functions it overloads, including UpdateFrame and RenderFrame functions, are virtuals. Isn't this an inefficient way of handling things? Requiring two vtable lookups every frame? Also, I've been reading about good design lately, and encapsulation is one of the hallmarks of good design. Would this be a slower approach than if the functions were just created and called directly? It seems like it'd make the program faster if things could be directly accessed rather then going through classes and functions that hide everything, but I don't know. What approach is best for handling the main program flow? And just for clarity what I mean by "main" is basically: -Windows specific functions (Initialization/window creation, Message handler) -DirectX specific (Initialization/device creation, clean up, on reset, on lost) -Game flow (update frame, render) Should I wrap everything in classes? Leave everything as free standing functions? Try to encapsulate everything? Thank you

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by Bob_the_dev
Isn't this an inefficient way of handling things? Requiring two vtable lookups every frame?

This isn't even a candidate for optimisation. 2 million vtable lookups per frame might be worth optimising, but 2 is not going to make one whit of difference.

Share this post


Link to post
Share on other sites
2 vtable look ups per frame isn't all that much. Consider a mildly underpowered computer by today's standards at 1500 MHz. At 60 frames per second that works out to 25,000,000 operations per frame. Two extra vtable look ups will work out to something like 4 of those instructions.

Share this post


Link to post
Share on other sites
Hmm, ok, virtual isn't that bad then. Is this a good way to handle things then? An application class that I can inherit and overload for each project?

Share this post


Link to post
Share on other sites
Quote:
Original post by Bob_the_dev
Isn't this an inefficient way of handling things? Requiring two vtable lookups every frame?


You could probably save a nanosecond per frame by removing the two virtual table lookups, if you don't need them. Thus, two obvious questions:

  • Are you certain you don't need them?
  • Is your nanosecond per frame worth the time spent?


The answer to the first question is usually "You're not certain", and the answer to the second question is almost always "Not really". When you're optimizing, you're looking for changes which can improve performance in a reasonable way. Don't spend half an hour gaining one nanosecond per frame, when you can spend half an hour gaining one millisecond per frame elsewhere.

Quote:
Also, I've been reading about good design lately, and encapsulation is one of the hallmarks of good design. Would this be a slower approach than if the functions were just created and called directly? It seems like it'd make the program faster if things could be directly accessed rather then going through classes and functions that hide everything, but I don't know.


It would probably make the program faster. However, unless you're calling a virtual function tens of thousands of times per second, making it non-virtual will not save you anything (assuming you can make it non-virtual). And, aside from virtual functions, using classes causes no performance overhead when compared to free-standing functions (if anything, it will make some things faster).

However, the time you'd spend working on your program without a good design outweighs by far the performance benefits you'd get out of this.

Quote:
-Windows specific functions (Initialization/window creation, Message handler)
-DirectX specific (Initialization/device creation, clean up, on reset, on lost)
-Game flow (update frame, render)


None of these are critical enough to be worth optimizing (you're looking at code which gets executed once per game or once per frame, after all). Instead, use a simple, encapsulated and clean design for these things, and look for code which gets run hundreds of times per frame if you need performance.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • 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!