Efficient Coding in C++

Started by
7 comments, last by vbvalkyr 15 years, 1 month ago
Hey everyone, I've been a member of this site for a while mostly just reading, but today I'm asking for help. I've been reading up a lot and have been coding in C++ for quite some time now, doing DirectX and some OpenGL, but I'm afraid I'm learning it the wrong way. I have many books and they all seem to teach different libraries to use and different methods of efficiency. What I'm interested in is staying with OpenGL, remaining as cross-platform as possible, and programming my games as efficient as possible. Anyone know of any tutorials you could link or maybe even a book I could get that teaches the management, organization and formats of professional game programming? I'd hate to continue teaching myself seven different ways to do things when I'm guessing they're just trying to make it easy for me to learn and not teaching me how to make things as efficient as possible. I'd like to eventually get into the industry, and I know that every developer/company/team has their ways, but I'm sure there are a lot of things I'm doing that are big NO-NO's. Thanks!
- Skyler (VBValkyr)
Advertisement
If you think you know enough about your language and have some decent practice in object-oriented programming, you might want to look into a book on design patterns. I recommend Head First: Design Patterns personally, because I just bought it myself and it helped a lot. [smile] The language the book uses is Java, but there's nothing preventing you from applying it in C++ without more than a few minor changes. I think the concepts are a bit more clearer in Java, anyways. [grin]

Try doing some console projects that are more complex than you're used to. The console lets you leave out the graphical part and just focus on structure and design. If you feel like something's wrong as you go, refactor it! I'm doing a console game right now, actually, except I'm also doing graphics based on each character cell in the console (see my journal - scroll down a ways). It's not terribly hard either, and it's lighter-weight - in my humble opinion - than a 3D library. Great way to learn how to structure things. [smile]

Hope I helped!
~Jonathan
1) Just program it. Who really cares untill you have stuff to show off that you know how to program something that isn't buggy.

2) Pick up a book on algorithms and data structures. 90% of the improvements you will want to make are in better ways to store and access your data.

3) Once you start to get larger, full projects, determine if you want to do gameplay, tools, or engine type code.
Each one represents a vastly different feature set and coding style.

Engine code: Focus on cutting instructions from tight loops, memory management, time management, threading, networking, graphics, resource managment. All with a focus on stability and speed. Assembly code knowledge is a huge help here. Different platforms have different instuctions, alignments, sizes etc that cause things to run best. Learn to read the processor docs and focus down the code to work well on the designated platform.

Gameplay: Modular designs, dispatch patterns, using engine code, effects, AI. Focus on fast to read(other team members will need to edit your code), fast to edit code(designs change, make it easy to cut and replace effects and behaviors). Focus on exposing all numbers as variables for fast iteration using the debugger/scripts/console to edit the look and behavior of objects at runtime(no rebuilding data or recompiling code). Focus on debugability, 90% of the problems in the game will relate to gameplay code, expose/assert/log enough information to make finding behavior/interaction bugs easier.

Tools: Focus on usability and automation. Code should be usable by coders and non-coders. Code should have ways to run it without user interaction (for build servers and other scripts). Iteration time is 90% tools, 10% compile times, so tools should also be quick to allow small edits (moving something in a level editor) to quickly be propagated into the game.

(probably an oversimplification, but each part of the team has a completely different focus on what is the best design for their code)
Thank you both for the replies.

@Twisol:

Oh man, I really feel like I've made enough ridiculously complex console games (command based, RPG, even stock market simulations) to give myself a minor myocardial infarction. The thing about those games is that you could have the worst programming habits known to man and still make console games that run smooth (no CPU whatsoever) and not have any difference in your final product. I will definitely check out that book, though. I know my share of Java to translate just fine, but I think I'll search for a C++ version first.

@KulSeran:

I do actually have a copy of Data Structures and Algorithms for Game Developers and that has been a big help in making more efficient and well performing code, and now that I am actually having it suggested it to me, I will take its structuring a little more to heart. Also, thanks a lot for the breakdown on my possible focuses. It's rough being an aspiring programmer with no one locally guide, teach or team up with me to correct me or help me progress. I guess the way that I'd like to lean would be toward either engine or tools focus, but I twitched uncontrollably when I read "Assembly". Looks like I'm going back to the book store to find a book titled: "Going in Over Your Head". I'll try to find the one with "For Dummies" after it. Kidding, I knew I couldn't avoid assembly forever with what I'm doing.

I'm pretty sure that I'm at that stage where I want to start rebuilding on what I make instead of restarting from scratch EVERY time, so I guess you could say I'm trying to devise my own "engine" of sorts. I know that's an ideal yet sometimes unrealistic goal, but I'm not afraid to get dangerous. The big thing is that I am trying to do a stupid amount of this by myself (good, even very basic, games take a team) and I just need some more tools to help steer me in a good/better direction. I'm trying to push myself past hobbyist status so I'm trying to get into the deep nitty-gritty.

Any suggestions? Thanks again.
- Skyler (VBValkyr)
you could look into books like "Code Complete", this one in paticular is a must have, as it is focused on improving your C++ code, and expanding your understanding of the language.

The C++ Programming Language is also a great book, I own it and it has served me well, it's not a light read by any means, but the depth of the book is insane.

Another thing you could do - if you haven't already - is look into the C++ standard library, learn to make good use of the container classes and their iterators, templates, the standard algorithms, these are important tools, and if there's one thing I've started to learn as I'm working through my degree it's how impotant delegating to standard libraries is, as the code is reliable, and it really increases productivity.

If you're really looking to sqeeze performance out of your coding, dive into some assembly, it's obviously not practical to use assembly anymore, but it really will give you a great idea of how your C++ code will perform, "Think low-level, write high-level".

hope this helps
--------------------------------------Not All Martyrs See Divinity, But At Least You Tried
I'm reading 'Code Complete' at the moment. It's pretty good so far, pretty extensive. But it's not C++ specific (nor does it need to be ;)).

'The Pragmatic Programmer' is also a good read.

As for C++ specific books, 'Effective C++' by Scott Meyers is definitely one you should get if you're serious about C++. He also wrote books about the standard library.


As for assembly, I doubt if it's worth the hassle to learn it nowadays. I haven't worked with it at all and that hasn't hindered me so far, even though I'm working on rather limited systems. From what I'm hearing, it's pretty hard to outperform modern-day compilers, and it's better to optimize at the algorithmic level anyway. I think learning a higher-level language is a much better investment, as it can make writing tools much easier and faster (tools, as in, I need to combine some images together and extract some data from them, or I need to convert some files, etc.).

As for good practices, maybe you could show some code for a peer review. There's some guys here that are especially good at dissecting code, if you're willing to learn and don't mind having your code being shred to pieces. :)
Create-ivity - a game development blog Mouseover for more information.
Quote:Original post by Captain P
As for C++ specific books, 'Effective C++' by Scott Meyers is definitely one you should get if you're serious about C++. He also wrote books about the standard library.


Personally, I recommend "Common C++ Knowledge", by S. Dewhurst, and "C++ Coding Standards" by H. Sutter and A. Alexandrescu.

"Common C++ Knowledge" is a very good "second C++ book" to read once you've gone through a book dealing with the language itself.
"C++ Coding Standards" will show you some good C++ practices, the reason why they exist, and when and why you might want to deviate from them.
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan
Quote:
As for assembly, I doubt if it's worth the hassle to learn it nowadays. I haven't worked with it at all and that hasn't hindered me so far, even though I'm working on rather limited systems. From what I'm hearing, it's pretty hard to outperform modern-day compilers, and it's better to optimize at the algorithmic level anyway.


That isn't at all what i was getting it. Sorry for not being clear.
1) Not all compilers properly support all the instructions a chipset exposes. For instance most vector processors don't have good support (intrinsics are nice, but amount to 1:1 asm operations, with help of possible optimizations)

2) You don't release your debug exe and debugger symbols. You release your release optimized builds. You don't test your debug builds, you test the release builds. For C++ development, this means that you will have to end up debugging your code in an environment where the output doesn't look like the input source code. And learning to match ASM to C++ and trace flow in ASM is invaluable for figuring out what happened on a client machine you have limited information from. Expecially when huge blocks of code get inlined and folded in release, causing variables and function calls to vanish.
Thanks again for the replies.

I'll probably end up getting a few more books that were suggested to me and have a look through them and see what I can do to optimize my own code. I haven't nearly brushed the surface of debugging at a very low level, so I think I'll keep the assembly for when I get to the point where I need to squeeze out every last bit of juice.

@godsenddeath :

I took a look at that "Code Complete" book and it looks like a definite purchase for me. However, what do you recommend is the best way to dissect the C++ Standard Library? I feel if I look deeper with improper guidance I may just think a lot of functions, containers and classes are my solution to everything, later to find out they are considered deprecated, improper or inefficient.

@Captain P :

I think I'm gonna hold off on displaying my code publicly until I try harder optimizing it myself. Good idea though, because I may display a few lines once I get things moving down the road. I'll save my "ask the audience" lifeline for a specific problem, not a problem (which might not even be a problem) with the entirety of my code.

@ Kulseran :

Thanks again because I think that when I get to that level assembly will help me out tremendously. When that day comes, I'll probably post my threads on another forum other than "For Beginners". :D

Book store, here I come.
- Skyler (VBValkyr)

This topic is closed to new replies.

Advertisement