I am planning to learn C++ so I could code for quake 4. Here's the book I plan to use. Can you tell me which chapters I need to go through before I can start working on the code

if it's anything like the doom3 SDK, it's a mixture of C and C++, written in several different styles, and no book will really help you with that..

If you've never programmed before, any book will help you, but it's more important that you learn how to use the debugger in your IDE, so you can STEP INTO/THROUGH/OUT of whatever code you're looking at. It's how you can watch it execute line by line, to help you understand what each line does until you start to really understand everything written in the SDK.

I'd recommend learning the syntax of the language first, and then learn to use your debugger. Set some breakpoints, then hit the Play button, and see exactly what happens in the game during each frame. That will give you the best tutor-age of any book.

All of book 1.

From book 2 it is worth understanding classes (a key concept which you need to understand). You don't necessarily need to understand how to use UML since you don't have UML diagrams describing the Q4 codebase, but it might help you understand classes better, so maybe worth you reading.

All of book 3.

All of book 4, except you shouldn't need to know about exceptions or using the STL (idlib has it's own equivilent of some of the STL containers but they work a bit differently. Maybe skim-read?).

Book 5 covers iostreams, which is not how file access works in D3/Q4. If you want to do file stuff in Q4, then I suggest you read up on the standard C style of file handling from another book, but file handling probably isn't critical.

Book 6 looks like it's not too important as it's delving into templates more than you'll probably need, but there may well be some advanced things mentioned in there that the Q4 codebase does, but you probably wont need to know the detail.

The debugging and how to use the IDE topics of book 7 are critical. Don't worry about MFC.

Appendix A may be required reading if you get as far as trying to build your mod under linux.

Thanks a lot both of you.

Going to start now. Wish me luck

It's not luck that you'll need, it's passion above everything. This, coupled with time and you'll learn many stuff.

My advice: once you'll understand all general syntax & portions of the Q4 SDK, don't fall into the "learn everything" syndrome. To my point of view, it's better to try to reach small goals (such as "add this little feature"), rather to spend too much time reading and studying the code (something that will waste your time, believe me).

Now once you'll try to achieve one single goal, you'll then focus on the problem in itself and you'll be forced to study portions of the code you feel seems the better place.

I don't know if I'm clear, but it's just what I can tell from personal experience...

I am planning to learn C++ so I could code for quake 4. Here's the book I plan to use. Can you tell me which chapters I need to go through before I can start working on the code

if it's anything like the doom3 SDK, it's a mixture of C and C++, written in several different styles, and no book will really help you with that..

If you've never programmed before, any book will help you, but it's more important that you learn how to use the debugger in your IDE, so you can STEP INTO/THROUGH/OUT of whatever code you're looking at. It's how you can watch it execute line by line, to help you understand what each line does until you start to really understand everything written in the SDK.

I'd recommend learning the syntax of the language first, and then learn to use your debugger. Set some breakpoints, then hit the Play button, and see exactly what happens in the game during each frame. That will give you the best tutor-age of any book.

All of book 1.

From book 2 it is worth understanding classes (a key concept which you need to understand). You don't necessarily need to understand how to use UML since you don't have UML diagrams describing the Q4 codebase, but it might help you understand classes better, so maybe worth you reading.

All of book 3.

All of book 4, except you shouldn't need to know about exceptions or using the STL (idlib has it's own equivilent of some of the STL containers but they work a bit differently. Maybe skim-read?).

Book 5 covers iostreams, which is not how file access works in D3/Q4. If you want to do file stuff in Q4, then I suggest you read up on the standard C style of file handling from another book, but file handling probably isn't critical.

Book 6 looks like it's not too important as it's delving into templates more than you'll probably need, but there may well be some advanced things mentioned in there that the Q4 codebase does, but you probably wont need to know the detail.

The debugging and how to use the IDE topics of book 7 are critical. Don't worry about MFC.

Appendix A may be required reading if you get as far as trying to build your mod under linux.

Thanks a lot both of you.

Going to start now. Wish me luck

It's not luck that you'll need, it's passion above everything. This, coupled with time and you'll learn many stuff.

My advice: once you'll understand all general syntax & portions of the Q4 SDK, don't fall into the "learn everything" syndrome. To my point of view, it's better to try to reach small goals (such as "add this little feature"), rather to spend too much time reading and studying the code (something that will waste your time, believe me).

Now once you'll try to achieve one single goal, you'll then focus on the problem in itself and you'll be forced to study portions of the code you feel seems the better place.

I don't know if I'm clear, but it's just what I can tell from personal experience...

I am planning to learn C++ so I could code for quake 4. Here's the book I plan to use. Can you tell me which chapters I need to go through before I can start working on the code

if it's anything like the doom3 SDK, it's a mixture of C and C++, written in several different styles, and no book will really help you with that..

If you've never programmed before, any book will help you, but it's more important that you learn how to use the debugger in your IDE, so you can STEP INTO/THROUGH/OUT of whatever code you're looking at. It's how you can watch it execute line by line, to help you understand what each line does until you start to really understand everything written in the SDK.

I'd recommend learning the syntax of the language first, and then learn to use your debugger. Set some breakpoints, then hit the Play button, and see exactly what happens in the game during each frame. That will give you the best tutor-age of any book.

All of book 1.

From book 2 it is worth understanding classes (a key concept which you need to understand). You don't necessarily need to understand how to use UML since you don't have UML diagrams describing the Q4 codebase, but it might help you understand classes better, so maybe worth you reading.

All of book 3.

All of book 4, except you shouldn't need to know about exceptions or using the STL (idlib has it's own equivilent of some of the STL containers but they work a bit differently. Maybe skim-read?).

Book 5 covers iostreams, which is not how file access works in D3/Q4. If you want to do file stuff in Q4, then I suggest you read up on the standard C style of file handling from another book, but file handling probably isn't critical.

Book 6 looks like it's not too important as it's delving into templates more than you'll probably need, but there may well be some advanced things mentioned in there that the Q4 codebase does, but you probably wont need to know the detail.

The debugging and how to use the IDE topics of book 7 are critical. Don't worry about MFC.

Appendix A may be required reading if you get as far as trying to build your mod under linux.

Thanks a lot both of you.

Going to start now. Wish me luck

It's not luck that you'll need, it's passion above everything. This, coupled with time and you'll learn many stuff.

My advice: once you'll understand all general syntax & portions of the Q4 SDK, don't fall into the "learn everything" syndrome. To my point of view, it's better to try to reach small goals (such as "add this little feature"), rather to spend too much time reading and studying the code (something that will waste your time, believe me).

Now once you'll try to achieve one single goal, you'll then focus on the problem in itself and you'll be forced to study portions of the code you feel seems the better place.

I don't know if I'm clear, but it's just what I can tell from personal experience...