|
On November 29 2012 03:48 CecilSunkure wrote:Show nested quote +On November 29 2012 01:56 spinesheath wrote:On November 28 2012 05:29 CecilSunkure wrote:
As for optimization, I only talked about delayed construction and said not to pass-by-value. These are the sort of things I learned my first semester working in C. They aren't really something you can get lost in while programming in a bad way as you'll be learning fundamentals essential to programming in general. Not using pass by value to improve speed is a trap too. Sometimes you want to pass by value, sometimes you don't. See: http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/Generally you never even want to think of optimization until after you ran a detailed performance analysis. Before that point all your efforts should be spent on producing simple, readable, understandable, reusable, testable and maintainable code. You know, intentionally setting up RVO is in and of itself programming while being mindful of optimizations. Some optimization really is just low hanging fruit you can be sure of.
It's stuff that you'll do automatically more and more as you gain experience, but it still has pretty much zero impact on performance for the vast majority of code. You will still need to optimize bottlenecks, and only those matter.
For example, I always write ++i instead of i++ unless I specifically need i++ (and even then I prefer to split the statement into two lines because it's easier to read/understand and maintain), but it never makes a difference with most of it being optimized by the compiler, and the rest simply not being in a critical section.
All I'm saying is: The optimizations without drawbacks are nice and all, but it's not something one should prioritize (especially beginners!). Optimize bottlenecks after performance analysis. Saves time, money, and your sanity.
|
On November 28 2012 03:43 Random() wrote:
While this is a great article, I think you are overemphasizing the "internals" of game programming. Those parts that work with the hardware and all the low-level implementation details are, of course, quite important, but in all honesty they have little to do with your actual game.
When you look at it this way, then game development (as in implementing the actual gameplay mechanics) is very often done in a higher-level language. People use all sorts of languages (Python, Lua, Java, C#, ...) to abstract themselves away from the engine internals and the horrors of C++, and that is a very good thing. Writing good C++ programs is extremely difficult, and even the state-of-the-art engines written by the most talented programmers in the world are ridden with bugs. C++ programs written by average programmers are a minefield.
So unless you are determined to be a very technical sort of developer, working on the engine, I don't agree that you HAVE to use C++ for game development, in fact I would argue that you should try to avoid it at all if that is possible within your workflow.
Also, you write "there are a few different simple guidelines that one can follow to ensure their code isn’t running sub-optimally" as if running sub-optimal code is something to be ashamed of. Saying such things, especially to new programmers, is a recipe for disaster. Premature optimization is the root of all evil, and for whatever reason many people really seem to like spending their effort "optimizing" absolutely unimportant stuff which they don't even know to be the bottleneck, while at the same time their program is not working correctly overall.
As far as I know most big name games are done in C++. It's actually not bad if you follow good coding practices and code reviews. Starcraft II for instance is primarily C++, and I also know for sure that every game that comes out of http://www.vvisions.com/ and http://www.1stplayable.com/. At the very least, games on console will likely remain primarily in C++ due to the limited hardware specs.
|
On November 28 2012 03:43 Random() wrote:
While this is a great article, I think you are overemphasizing the "internals" of game programming. Those parts that work with the hardware and all the low-level implementation details are, of course, quite important, but in all honesty they have little to do with your actual game.
When you look at it this way, then game development (as in implementing the actual gameplay mechanics) is very often done in a higher-level language. People use all sorts of languages (Python, Lua, Java, C#, ...) to abstract themselves away from the engine internals and the horrors of C++, and that is a very good thing. Writing good C++ programs is extremely difficult, and even the state-of-the-art engines written by the most talented programmers in the world are ridden with bugs. C++ programs written by average programmers are a minefield.
So unless you are determined to be a very technical sort of developer, working on the engine, I don't agree that you HAVE to use C++ for game development, in fact I would argue that you should try to avoid it at all if that is possible within your workflow.
[...]
This is just plain wrong. Game programmers do work on C++ too, and although their are more concerned with iterating fast on a feature so that the game designer is happy than with raw performance (as are engine programmers), they need to be excellent at C++. Just read any gameplay programmer job offer (see http://www.gamasutra.com/jobs/board.php?category=16 for instance) you will see than "strong C++ skills" are a pre requisite in 95% of the cases.
Please do avoid to misinform people around here, that are not necessarily schooled with the inner working of the game industry.
[Edit: Ooops actually Cecil already answered pretty much the same thing, sorry about that]
|
Not bad (though rushes through a bit quickly but whatever)
as a note, there's no good reason I can think of to use #define for global ints and things. Use enums or const variables.
You can't for example call the following code snippet:
#define NUM_MAX 256
//...
SomeFunction(&NUM_MAX);
But you can do
const int NUM_MAX = 256;
//...
SomeFunction(&NUM_MAX);
not to mention better error checking and reporting with const vars, and problems if you define the same thing twice.
The only time I'd use #define is when creating some kind of debug and i might want to use ugly macros like __LINE__. something like this:
#define ERROR(x) \
do { \
std::cerr << "ERROR: \"" << x << "\" - Line: " << __LINE__ << ", File: " << __FILE__ << "." << std::endl; \
}while(0)
Or of course if you have a bunch of different flags, you should probably use an enum instead for better type safety and less confusion in parameters and such.
|
Macros are for actual preprocessor operations like include guards and stuff where you select some code based on the architecture you're compiling for (note: use this very sparingly) or debugging (although you should use a logger for that). In some rare occasions you might want to use it to greatly improve readability (for example Typelists). Macros as a replacement for functions, constants, inlining or templates are bad.
|
Kyrgyz Republic1462 Posts
On November 29 2012 23:47 Kerm wrote:Show nested quote +On November 28 2012 03:43 Random() wrote:
While this is a great article, I think you are overemphasizing the "internals" of game programming. Those parts that work with the hardware and all the low-level implementation details are, of course, quite important, but in all honesty they have little to do with your actual game.
When you look at it this way, then game development (as in implementing the actual gameplay mechanics) is very often done in a higher-level language. People use all sorts of languages (Python, Lua, Java, C#, ...) to abstract themselves away from the engine internals and the horrors of C++, and that is a very good thing. Writing good C++ programs is extremely difficult, and even the state-of-the-art engines written by the most talented programmers in the world are ridden with bugs. C++ programs written by average programmers are a minefield.
So unless you are determined to be a very technical sort of developer, working on the engine, I don't agree that you HAVE to use C++ for game development, in fact I would argue that you should try to avoid it at all if that is possible within your workflow.
[...] This is just plain wrong. Game programmers do work on C++ too, and although their are more concerned with iterating fast on a feature so that the game designer is happy than with raw performance (as are engine programmers), they need to be excellent at C++. Just read any gameplay programmer job offer (see http://www.gamasutra.com/jobs/board.php?category=16 for instance) you will see than "strong C++ skills" are a pre requisite in 95% of the cases. Please do avoid to misinform people around here, that are not necessarily schooled with the inner working of the game industry. [Edit: Ooops actually Cecil already answered pretty much the same thing, sorry about that]
EDIT: Nevermind.
|
yeh man nice thread i have a Bsc in computer game development
|
Yikes. This is impressive.
I've dabbled in Python and C++, but I'm still a complete novice. Brilliant stuff.
|
Wow.. this is like the entire contents of first and 2nd year CSC in one spot. Amazing.
|
Posts like your help give me motivation to pursue programming. I'm actually going to buy those books.
Thanks a lot!
|
Tons of people use Java all the time - there are plenty of hobbyist games built in Java. I absolutely think making a few smaller games in e.g. Python or Java is a great idea. Arguably, while you're learning, the python/java implementation can be faster than your C++ implementation as long as you do things somewhat reasonably. You will be a far better programmer (especially in C++) by experiencing what other languages can do for you. Even getting in to some functional concepts is powerful because a lot of those ideas fit really well in to building parallelizable systems.
Plus, let's face it, there's a really solid chance most people in this thread won't enjoy doing gamedev for a living. It's a very taxing, very difficult, and very competitive industry with low pay and horrific hours. Very rewarding if you're the type of person who likes making games, but, as someone who is strong in C++, I can assure you having a C++ background isn't really an ultra-desired skill set right now. You can make do (and good money) but your industries are limited (basically you can kiss startups goodbye).
Arrays cannot be passed around from one location to another directly. If attempted, the name of an array will be converted to a pointer to the first element in the array. This incurs a loss of information, as a pointer stores information about location and type, whereas an array stores location of first element, type of the elements and number of elements. This “feature” of C and C++ can actually be viewed as a “language bug”.
In C++, references to arrays are not decayed when passed. This allows you to eliminate this decay at no cost with a parameter that looks similar to the below. Just a sample from an implementation of one of those internet question things, but demonstrates the prototype:
template <size_t Sz>
Node* TreeFromSortedArray(int (&arrayList)[Sz], int start, int end)
With this, sizeof does work correctly (which means you can use _countof or ARRAY_SIZE). You can even replace int with a template if you wanted and that works, too.
I'd probably suggest striking the optimization section entirely; I agree with everything in it but I think it would be stronger in a "Coding for the future" type of section. i.e. postfix/prefix - I use the prefix operator too but it hasn't reasonably mattered in years and I've literally never had a line of code's speed increased by any measurable factor by a postfix ++ operator even in the one situation I can think of where it create unnecessary copies, delayed construction is more just a code organization thing - it can be the right answer in some situations but only if you've done the necessary legwork (profiling and analysis) to know why. And so on with the remaining things. They're all great suggestions but also they're all premature optimizations. More important is focusing on complexity (avoiding n^2 or worse - especially in a loop), profiling, and timing. Every foray in to game making I've made usually involves a section where I forget I only have like 15ms or something to complete the game loop.
Overall it's a great article. I liked the sections on design patterns and data structures. I definitely feel like the #1 mistake I see at work is people overlooking both of those things.
|
One thing... Do you need to learn C and C++ side by side or is learning just C++ enough?
|
I would advice learning either C or C++, not the abomination that is C/C++ or C with classes.
|
Just learn C++. C is used only in some rare and very specific circumstances nowadays.
|
oh my, i'm working on whac a mole program in java, i'm totally lost now..
|
I have Visual Studio 2012 and I can't figure out how to set it up for C programming. Options for C++ and C# are pretty obvious but allegedly I can use it for plan C ( I think). I was using codeblocks on my old computer, which I liked a lot, but I have a class that is using C# and I would like to us VS for both languages if I can.
|
On December 10 2012 18:58 Azerbaijan wrote:
I have Visual Studio 2012 and I can't figure out how to set it up for C programming. Options for C++ and C# are pretty obvious but allegedly I can use it for plan C ( I think). I was using codeblocks on my old computer, which I liked a lot, but I have a class that is using C# and I would like to us VS for both languages if I can.
Create a C++ console project, and code away in C. You may get warnings for including C headers like <stdio.h> instead of their C++ counterparts <cstdio>, but it won't be a big deal for the foreseeable future.
|
On December 10 2012 18:58 Azerbaijan wrote:
I have Visual Studio 2012 and I can't figure out how to set it up for C programming. Options for C++ and C# are pretty obvious but allegedly I can use it for plan C ( I think). I was using codeblocks on my old computer, which I liked a lot, but I have a class that is using C# and I would like to us VS for both languages if I can.
Just create your file as a .c file.
|
Ah, thanks. And thanks for the article; I'm hoping to pick up the C and C++ books for christmas and I've just grabbed the Code one from the library. Should keep me busy for a while.
|
CecilSunkure just curious, what compilers do you use to program with and what compilers have you used to program with in the past? Any short reviews you would be willing to give of a few?
edit: Also, when reading through this I noticed this odd sentence
In the first sentence about Heap:
The heap is memory is a large location of memory that dynamic memory can be requested from.
|
|
|
|
|
|
EPT
