- Forum
- Windows Programming
- Programming 2D Games (Book)
Programming 2D Games (Book)
I was wondering if the book Programming 2D Games - Charles Kelly is a good book to learn how to make a simple 2D game. I have the book already as i have lent it from a friend.
Will I learn how to make a simple 2D game, on my own, from it? Or will it not help at all?
Will I learn how to make a simple 2D game, on my own, from it? Or will it not help at all?
I'm not familiar with that book, but when it comes to general game structure, I can still find useful info and techniques in 30-year-old books about making DOS games. So if you're new to it, then you probably will find lots of useful stuff in there, even if it isn't the most up-to-date info around.
2-D graphics techniques haven't really changed all that much since the days of the Apple II and Commodore 64. And these days it's easy to get your hands on some really nice, free libraries which handle all the low-level bit twiddling for you.
2-D graphics techniques haven't really changed all that much since the days of the Apple II and Commodore 64. And these days it's easy to get your hands on some really nice, free libraries which handle all the low-level bit twiddling for you.
Well, not off the top of my head. The point I was trying to make is that just about any book on 2D stuff ought to be useful as the techniques are so well established, so go ahead and read the one you have.
But since I made the claim, I may as well back it up. Back in 1990 or so, I got a book called "Graphics Gems" edited by Andrew Glassner. It's a rather encyclopedic catalog of graphics techniques, mostly 2D but some 3D as well.
Around the same time there was a series of books published called "Game Programming Gems" which were largely collections of articles by many industry pros covering various aspects of game programming.
I wouldn't recommend hunting down a copy of any of the above, as there's almost certainly more recent books which have the same info and wouldn't require having to update/translate all the examples. But if you come across them at a garage sale for a few bucks, you could do a lot worse.
But since I made the claim, I may as well back it up. Back in 1990 or so, I got a book called "Graphics Gems" edited by Andrew Glassner. It's a rather encyclopedic catalog of graphics techniques, mostly 2D but some 3D as well.
Around the same time there was a series of books published called "Game Programming Gems" which were largely collections of articles by many industry pros covering various aspects of game programming.
I wouldn't recommend hunting down a copy of any of the above, as there's almost certainly more recent books which have the same info and wouldn't require having to update/translate all the examples. But if you come across them at a garage sale for a few bucks, you could do a lot worse.
Last edited on
| 2-D graphics techniques haven't really changed all that much since the days of the Apple II and Commodore 64. |
Waaaaat?
I have to step in here.... 2D graphics have changed tremendously.
2D graphics techniques back in the day focus on blitting, dirty rects, and color keying. If you are reading anything that uses any of those terms, you should throw it in the garbage. None of that applies today. Everything now is polygon rendering and programmable shaders. It's an entirely different world.
Modern 2D graphics aren't even really 2D graphics. They are 3D graphics set to an orthagonal view to give the appearance of 2D.
2D graphic libs abstract drawing to be simpler so you don't have to deal with the complexities that the 3D environment adds, but a lot of the concepts come from 3D.
Books on DOS in particular are horrid because DOS had a lot of restrictions on graphics and setting up graphic modes and stuff that simply do not apply on modern computers. In fact many techniques used to speed up DOS graphics will actually significantly slow down your program if you attempt them on modern hardware.
An old book might give you insight on non-graphical areas of game organization... but even those I would question as better techniques probably have come along since then. But you definitely should not take any cues on graphics from anything that old.
Really... a 20 year old computer book is a dinosaur and is practically worthless -- look how much computers have changed in that time. Let alone the C++ language.
Well, you said it yourself, most 2D graphics these days aren't really 2D, they're 3D. But if you are doing true 2D, then bressenhams line drawing algorithm hasn't changed a bit.
I'll admit that if you ever find yourself actually writing code for this algorithm, you're probably wasting your time, as there's a host of libraries out there that handle all that low level stuff for you. But if you're curious about how to actually do it yourself...
Also, most of the techniques I had in mind when I wrote that are methods for doing thing like tile-map edge blending, or drawing 2D isometric maps (think old-school X-Com), which are also just as valid today as they were then. I suppose the distinction would be lost on someone new to this stuff, so I apologize for any confusion.
I'll admit that if you ever find yourself actually writing code for this algorithm, you're probably wasting your time, as there's a host of libraries out there that handle all that low level stuff for you. But if you're curious about how to actually do it yourself...
Also, most of the techniques I had in mind when I wrote that are methods for doing thing like tile-map edge blending, or drawing 2D isometric maps (think old-school X-Com), which are also just as valid today as they were then. I suppose the distinction would be lost on someone new to this stuff, so I apologize for any confusion.
Last edited on
| Well, you said it yourself, most 2D graphics these days aren't really 2D, they're 3D |
Which is why learning old 2D techniques from old books is a waste of time. None of that applies to modern graphics programming.
Unless you are writing programs for 20 year old computers.
I'll admit that if you ever find yourself actually writing code for this algorithm, you're probably wasting your time, as there's a host of libraries out there that handle all that low level stuff for you. |
The hardware does that for you. Graphics cards are designed to render lines/shapes quickly. Your program should take advantage, and should not try to do in software what the hardware already does for free.
| But if you're curious about how to actually do it yourself... |
You would never do that in a 2D game.
I can see learning these techniques for graphics processing outside of the display (where the image never actually gets to the graphics hardware and must be done fully in software -- like in a photoshop style program), but OP specifically said he wants to make a game.
No game written in 2014 should be plotting individual pixels on a line. Or at least... not in the same way you'd do it on DOS.
@ OP:
My advice: Don't even entertain any book on graphics techniques that is older than 5 years unless it has been highly recommended as a classic by development circles.
While I haven't read it, a quick google search tells me the Charles Kelley book you mentioned in your post was published in 2012, so it's probably fine. It's certainly going to be 100x more relevant than anything that even mentions DOS.
I never recommended that he/she learn from old books, I was just trying to make a point that there was still useful info that could be gleaned from them. As that is only true for an experienced programmer, I'll admit it was a mistake for doing so in this context.
No, you were right to do so. Avoiding adding to the confusion of new programmers should be a priority. I wasn't properly considering the audience, and probably being a little bucolic in my recollections. I just pulled down one of the books I mentioned and looked through it. Some of this code is pure dog-shit :)
Last edited on
Thanks guys, i guess ill get started with this book. Any problems ill just ask about in the forums again :) Thanks @Esslercuffi and @Disch!
Topic archived. No new replies allowed.