Members - Reputation: 100
Posted 29 February 2012 - 06:10 PM
How much C is enough to start programming games, though? Will finishing this book leave me with enough know-how to start working on something simple (say, a breakout clone)? Should I pick through a book on algorithms and data structures or, perhaps, a more advanced C book before moving on?
NOTE: Yes, I know C++ is more popular for game development. Yes, I'm well aware that Python and C# are easier languages to learn. Yes, I'm going to stick with C. Comments concerning the previous statements will be ignored. Cheers!
Members - Reputation: 962
Posted 29 February 2012 - 06:39 PM
Crossbones+ - Reputation: 3034
Posted 29 February 2012 - 08:20 PM
If you use Windows, try using SDL.
Crossbones+ - Reputation: 4616
Crossbones+ - Reputation: 4118
Posted 01 March 2012 - 12:33 PM
BTW, learning from K&R (which I still have from my 1994 CS class) seems odd, as it's mainly a reference document. You might want to check out some C tutorials to help fill out your understanding of programming.
---(Old Blog, still has good info): 2dGameMaking
"No one ever posts on that message board; it's too crowded." - Yoga Berra (sorta)
Crossbones+ - Reputation: 11711
Posted 01 March 2012 - 01:01 PM
So is OpenGL code under windows and Linux, with the only difference creating the context as far as I am aware, after that the code for rendering should be the same on win/linux/mac.
That's more or less correct - the actual rendering parts of the API are completely OS-neutral. It's not the full story however as OpenGL is very hardware-dependent (on it's own OpenGL doesn't do anything aside from pass rendering commands to your graphics hardware, which is what does the actual drawing). By that I mean that you need to be aware of what features are available on the graphics hardware you're targetting and either code to a common baseline or implement workarounds where they're not available.
There is one exception to the "OpenGL doesn't do anything..." thing I mentioned, and that is where the driver reports support for a certain GL_VERSION, but features of that version are not available in hardware - in that case they must be emulated in software by the driver. Sometimes (not always) that can come at a performance cost, and sometimes (not always) that performance cost can be extreme. Generally the cost increases the deeper into the pipeline you go - pre-vertex-shader emulation will be cheap, fragment shader emulation will be expensive (may drop you to less that 1 fps).
You may also encounter buggy drivers and have to be aware of what the bugs are and what the consensus is for working around them.
So once you have your context up you can treat OS as being totally irrelevant, and focus on driver quality and hardware features as being the key differentiators.
It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.
Members - Reputation: 143
Posted 03 March 2012 - 03:43 PM
Members - Reputation: 604
Posted 03 March 2012 - 10:58 PM
but don't expect to impress anyone as as mentioned since C itself doesn't have any sort of graphics support built in you are still going to have to learn more stuff namely an API like ncurses to get something on the screen other than text.