Best C++ game programming book recommendations

I am currently reading 'Core Techniques and Algorithms in Game
Programming' publsihed by New Riders. So far its the best book on
game programming that I have read, better than TOTWGPG.

You won't become an expert in one area of game programming, but it
gives good understanding of so many different areas of game
programming so that you are prepeared to tackle more indepth texts on
specific issues.

john_20_28_2000@yahoo.com (jm) wrote in message news:<c67e4bdd.0402231955.5aac84cb@posting.google. com>...
> I know there are many different possibilities here, but first let me
> say:
>
> I am not an expert C++ programmer - not even close.
>
> I do know the language or at least can follow it. I feel comfortable
> enough to use the a help file, Internet, etc. I understand basic
> Win32 programming (I understand on a basic level what is going on,
> winmain, messages, etc.). I am an experienced programmer in other
> language, mostly of the scripting type, however, perl, javascript,
> some C, VB.NET, other odds and ends.
>
> I am *not* looking to make 3D games or the next greatest game in the
> universe. I understand some basic concepts like recursion.
>
> That's about where it ends.
>
> I am yet another web page server side database driven kind of
> "programmer." But hey, I get paid for it (and I like it).
>
> I want to make graphical games, but as I said - 2D (DirectX or OpenGL,
> but prefer the former - no offense)
>
> I had the book "Game Programming: All in One." The C++ primer was
> okay (took that there and on the Internet a million times, nothing
> new), but when the "game" programming starts it's just line after line
> with no explanation. I do not want that again.
>
> I am on WinXP Pro. and own VS 6.0.
>
> Hope you understand where I am coming from and thanks for any advice
> on what book to get. Thanks.

In article <gfD1c.5452$rb.64431@news.indigo.ie>, gerryq@indigo.ie
says...
> >> [...]
> >What you said amounted to a nonsensical "there was no reply to
> >article X therefore article X was irrefutable". A pretty baffling
> >"deduction" from someone who is keen on accusing others of
> >argumentative fallacies. (Still, pretty much in line with what
> >could be expected.)
>
> I simply pointed out that Alexandrescu was unable or unwilling to reply.

Again you play the game of excluding other possibilities that do
not fit the conclusion you want to draw. If you wanted, I'm sure
you could tell us the name given to that particular fallacy of
arguing.

PS. The post you're referring to was authored by Terje Slettebø,
not Terry Sletebo. Of course, you knew that and were just
americanizing it for the hell of it, right.

Christer Ericson
Sony Computer Entertainment, Santa Monica

In article <cIr1c.5409$rb.64342@news.indigo.ie>, gerryq@indigo.ie
says...
> [...]
> I think both your example and your proposed solutions are absurd.

Humor me and reply to the point I made. Given a large number
(not necessarily 10,000) of convenience functions (ie. functions
not requiring private access to class members), and given the two
options:

a) adding them to the class
b) adding them to a namespace outside the class

Do you really think the former is better encapsulation? Why?


Christer Ericson
Sony Computer Entertainment, Santa Monica

In article <MPG.1ab1a7abd14f6634989748@news.verizon.net>, Christer Ericson <christer_ericson@NOTplayTHISstationBIT.sony.com > wrote:
>In article <gfD1c.5452$rb.64431@news.indigo.ie>, gerryq@indigo.ie=20
>
>PS. The post you're referring to was authored by Terje Sletteb=F8,
>not Terry Sletebo. Of course, you knew that and were just
>americanizing it for the hell of it, right.

No, just running on memory. And I'm not American - if I had changed him
to Terence O'Sleathabain you might have a case...

- Gerry Quinn

In article <MPG.1ab1ab0c4d556d76989749@news.verizon.net>, Christer Ericson <christer_ericson@NOTplayTHISstationBIT.sony.com > wrote:
>In article <cIr1c.5409$rb.64342@news.indigo.ie>, gerryq@indigo.ie
>says...
>> [...]
>> I think both your example and your proposed solutions are absurd.
>
>Humor me and reply to the point I made. Given a large number
>(not necessarily 10,000) of convenience functions (ie. functions
>not requiring private access to class members), and given the two
>options:

I'll accept your definition of convenience functions as meaning the
above for the purposes of this post.

>a) adding them to the class
>b) adding them to a namespace outside the class

Not enough data is given, but as far as I can see they are both likely
to be very bad solutions, neither of which I could approve. If the
"convenience functions" are not going to be part of other uses of the
original class, they require a class of their own. There are various
ways to achieve this:
- a derived class
- a helper class that acts as an interface (or part of an interface) to
the original class

Using a namespace is just a bad way to attempt the same functionality as
the latter.

>Do you really think the former is better encapsulation? Why?

Sun defines encapsulation:
"The localization of knowledge within a module. Because objects
encapsulate data and implementation, the user of an object can view the
object as a black box that provides services. Instance variables and
methods can be added, deleted, or changed, but if the services provided
by the object remain the same, code that uses the object can continue to
use it without being rewritten."

HyperDictionary defines encapsulation:
"The ability to provide users with a well-defined interface to a set of
functions in a way which hides their internal workings. In
object-oriented programming, the technique of keeping together data
structures and the methods (procedures) which act on them."

Sensibly, neither definition mentions "class". However, in C++, it is
classes which are the primary (and very flexible) means of achieving
this, and clearly encapsulation is best served by using a class.
Given the implied context, putting all these functions in the original
class is probably not a good idea, though if they can be systematised it
might well have support functions. One or more new classes should be
defined to deal with them appropriately.

Namespaces fail as a tool for encapsulation - for a start they are not
localised. They have a valid function, but it is a subsidiary one.

If you want me to say that in certain circumstances putting 10000
convenience functions in a namespace might be slightly less bad* than
putting them in the original class, I will agree. But neither option is
to be countenanced, IMO.

*If only because a small part of the program remains undamaged.

- Gerry Quinn

In article <2sZ1c.5557$rb.64877@news.indigo.ie>, gerryq@indigo.ie
says...
> [...]
> No, just running on memory. And I'm not American - if I had changed him
> to Terence O'Sleathabain you might have a case...

I was just americanizing you for the hell of it.


Christer Ericson
Sony Computer Entertainment, Santa Monica

Rainer Deyke wrote:

> Peter Ashford wrote:
>
>>I don't see the point of your post
>
>
> 1. Using subclasses to add convenience functions leads to an overly verbose
> and messy style of coding. Taken to the extreme, the subclasses effectively
> act as external functions with worse syntax. Compare f(x) to
> subclass_with_f(x).f().

Almost *anything* in programming taken to an extreme is bad. Your point
doesn't apply to 'client clasesses' anymore than any other programming
idiom or feature you could name.

> 2. Using subclasses to add convenience functions just plain doesn't work if
> you need to apply the convenience function to an existing object, not a
> copy.

Youll have to give me an example