What's a good approach to the main program?

Started by
3 comments, last by ToohrVyk 16 years ago
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
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.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

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.
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?
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.

This topic is closed to new replies.

Advertisement