Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualPolarist

Posted 08 February 2013 - 07:17 AM

Wow this is a cool topic!  I joined up just to post this.

 

I learned graphics programming when I was in 10th grade or so.  mostly because it seemed like everyone on IRC was programming games back then.  So I started off with some OpenGL tutorials.. which led me to look into the OpenGL redbook, Windows API, X11 Libraries, etc.  Sooner or later I was going through the Doom and Quake source code trying to understand everything line by line.  After enough of that, it just started to click, and I put together a homegrown physics engine, rendering engine, and some basic multiplayer code.  Resulted in some "tech demo"-like games back then.  When I hit college, I went a completely different (and non-technical) route, only doing non-game programming on weekends as a hobby.

 

Then after about a decade, I began picking it all back up again... but the landscape is completely different now from back then.  People are using C++ instead of C, forward rendering is out, immediate rendering is out, fixed function pipeline is out, so I had to relearn most of the stuff from scratch, again.  On top of that, there are new priorities now: multicore, async, mobile, crossplatform.  The only thing that has seemingly stayed the same for the most part was Win32 API (and even now, that seems like it's on its way out with Win9).

 

The beautiful thing about learning game programming these days is that resources are everywhere, from beginner to expert level, the modern internet has it all.

 

Now here's a bit of unconventional advice, but also the best advice I can give.  To get good at graphics programming quickly, really throw yourself into the deep end; and the deepest information comes from looking at high-quality (professional and production-level) source code.  So once you have your basic syntax principles down, just choose a good graphics library, choose an interesting section, and go through it line-by-line until you understand _everything_ about it.  Then repeat.  This approach is probably the most grueling, but it'll get you there the fastest.  If you can't do that, the second fastest way is literally reading and memorizing documentation.

 

Like I said, it's unconventional wisdom, but it has worked really well for me and for everyone I know who has tried it.  I only have a limited amount of time to work on this sort of thing, but I feel my grasp of these technologies is pretty deep.  If those approaches don't work for you, then you'll have to settle for the conventional approaches: trying to code a bunch of projects, and (the slowest) reading and learning from tutorials.  These last two approaches are probably the easiest to do as a beginner, but learning that way is generally really slow (there's a lot of boilerplate and overhead to learning those ways).

 

Oh and to answer your question: I do it (mostly) as a hobby.  I'm working on a game engine built from the ground up with high-level bindings for easy prototyping and high mod-ability.. and also I'm incorporating a bunch of neat "cutting edge" tech from articles and papers I found interesting.


#2Polarist

Posted 08 February 2013 - 07:07 AM

Wow this is a cool topic!  I joined up just to post this.

 

I learned graphics programming when I was in 10th grade or so.  mostly because it seemed like everyone on IRC was programming games back then.  So I started off with some OpenGL tutorials.. which led me to look into the OpenGL redbook, Windows API, X11 Libraries, etc.  Sooner or later I was going through the Doom and Quake source code trying to understand everything line by line.  After enough of that, it just started to click, and I put together a homegrown physics engine, rendering engine, and some basic multiplayer code.  Resulted in some "tech demo"-like games back then.  When I hit college, I went a completely different (and non-technical) route, only doing non-game programming on weekends as a hobby.

 

Then after about a decade, I began picking it all back up again... but the landscape is completely different now from back then.  People are using C++ instead of C, forward rendering is out, immediate rendering is out, fixed function pipeline is out, so I had to relearn most of the stuff from scratch, again.  On top of that, there are new priorities now: multicore, async, mobile, crossplatform.  The only thing that has seemingly stayed the same for the most part was Win32 API (and even now, that seems like it's on its way out with Win9).

 

The beautiful thing about learning game programming these days is that resources are everywhere, from beginner to expert level, the modern internet has it all.

 

Now here's a bit of unconventional advice, but also the best advice I can give.  To get good at graphics programming quickly, really throw yourself into the deep end; and the deepest information comes from looking at high-quality (professional and production-level) source code.  So once you have your basic syntax principles down, just choose a good graphics library, choose an interesting section, and go through it line-by-line until you understand _everything_ about it.  Then repeat.  This approach is probably the most grueling, but it'll get you there the fastest.  If you can't do that, the second fastest way is literally reading and memorizing documentation.

 

Like I said, it's unconventional wisdom, but it has worked really well for me and for everyone I know who has tried it.  I only have a limited amount of time to work on this sort of thing, but I feel my grasp of these technologies is pretty deep.  If those approaches don't work for you, then you'll have to settle for the conventional approaches: trying to code a bunch of projects, and (the slowest) reading and learning from tutorials.  These last two approaches are probably the easiest to do as a beginner, but learning that way is generally really slow (there's a lot of boilerplate and overhead to learning those ways).


#1Polarist

Posted 08 February 2013 - 07:04 AM

Wow this is a cool topic!  I joined up just to post this.

 

I learned graphics programming when I was in 10th grade or so.  mostly because it seemed like everyone on IRC was programming games back then.  So I started off with some OpenGL tutorials.. which led me to look into the OpenGL redbook, Windows API, X11 Libraries, etc.  Sooner or later I was going through the Doom and Quake source code trying to understand everything line by line.  After enough of that, it just started to click, and I put together a homegrown physics engine, rendering engine, and some basic multiplayer code.  Resulted in some "tech demo"-like games back then.  When I hit college, I went a completely different (and non-technical) route, only doing non-game programming on weekends as a hobby.

 

Then after about a decade, I began picking it all back up again... but the landscape is completely different now from back then.  People are using C++ instead of C, forward rendering is out, immediate rendering is out, fixed function pipeline is out, so I had to relearn most of the stuff from scratch, again.  On top of that, there are new priorities now: multicore, async, mobile, crossplatform.  The only thing that has seemingly stayed the same for the most part was Win32 API (and even now, that seems like it's on its way out with Win9).

 

The beautiful thing about learning game programming these days is that resources are everywhere, from beginner to expert level, the modern internet has it all.

 

Now here's a bit of unconventional advice, but also the best advice I can give.  To get good at graphics programming quickly, really throw yourself into the deep end; and the deepest information comes from looking at high-quality (professional and production-level) source code.  So once you have your basic syntax principles down, just choose a good graphics library, choose an interesting section, and go through it line-by-line until you understand _everything_ about it.  Then repeat.  This approach is probably the most grueling, but it'll get you there the fastest.  If you can't do that, the second fastest way is literally reading and memorizing documentation.

 

Like I said, it's unconventional wisdom, but it has worked really well for me and for everyone I know who has tried it.  I only have a limited amount of time to work on this sort of thing, but I feel my grasp of these technologies is pretty deep.  If that doesn't work for you, then the next fastest would be trying to code a bunch of projects, and the slowest would be reading and learning from tutorials.  These last two approaches are probably the easiest to do as a beginner, but learning that way is generally really slow (there's a lot of boilerplate and overhead to learning those ways).


PARTNERS