Archived

This topic is now archived and is closed to further replies.

Agent__X

Is this noob blues?

Recommended Posts

I am a novice C programmer (and in the process of learning C++). I can write silly little DOS programs like you see used as examples in programming tutorials (you know, address books, feet-to-meter converters, etc.). When I open, hmm...lets say, the Quake3 SDK and start looking at the lines and lines of code I draw a blank. I understand it on a line by line basis...like I find myself thinking "Oh look there''s a pointer to an element of a structure", and "Okay that''s a function definition there", and "Uh-huh, he''s declaring some variables there"...but I don''t have a clue how to go about adding anything of my own or changing anything. Do you guys (the veteran coders out there) have to flowchart the source code out before you start messing with it? How do I know where to start? This is the single greatest hurdle for me. I have thought that after I learn C++, I''d pick up a book on OpenGL or DirectX and start coding my own simple engine to better understand whats what. Any tips would be helpful...

Share this post


Link to post
Share on other sites
A lot of it is planning ahead. A lot of it is also having programmed it yourself. It''s kind of hard to just jump into a several thousand (if not hundred) line program and understand everything.

Share this post


Link to post
Share on other sites
I have been programming for C/C++ 8 years..... it is impossable for me to understand all, if even MUCH, of quakes source. Im not saying there are not those that do, but as the previous poster mentioned, it is alot easier if you wrote it yourself. From personal expirance, when working in a programming group, usualy one individual is required to work on one given procedure, or part of the engine (depending on the size). This then is to cohere to the "API" so to speak of the project. The project specs writen in the design document (reason why design documents are so important) So in the end, that one individual KNOWS what that piece of code does, and just plops what it does, not how it does it, onto nice comments, either in or out of source. Now i believe that somewhere on the net someone has documented most of the quake source code, global variables and such. I am not sure how much, or where, but google for it.

Share this post


Link to post
Share on other sites
I would go with your original plan. Buy some books, look at some good tutorials like NeHe''s OpenGL tutorials and start learning. From what i''ve heard, all the Quake sources are very hard to understand. I messed with the quake2 source a bit in my earlier days and that code is just extremely hard to follow. I only managed to make some changes thanks to a few great quake2 coding tutorials and the changes I made were very basic.

If you want to learn how games work from the inside out, I recommend you pick another game then Quake. See what games have been made by the people here on the forum. Most are indy developers. Their games aren''t that big, easier to grasp, better to follow and most of the time they even have decent commenting in the source

Sander Maréchal
[Lone Wolves Game Development][RoboBlast][Articles][GD Emporium][Webdesign][E-mail]


GSACP: GameDev Society Against Crap Posting
To join: Put these lines in your signature and don''t post crap!

Share this post


Link to post
Share on other sites
also i hear quite often that their sources are pretty horrible to read. it might be doing the job and pretty fast too, but i guess there''s cleaner code out there.

also: dont start looking at c files.. seeing the implementation of a single function wont help at all.. check the header files to get an overview and if any particular function is of interest then go there.

Share this post


Link to post
Share on other sites
Thanks for the advice/thoughts. Looking at the header files for a specific function or object sounds like a good place to start. Then I can trace its path through the code. Thanks again!

Share this post


Link to post
Share on other sites
I understand Quake III. I didn't at first, but then I mapped out the functions Carmack used in my head, and figured out how the whole thing works. It's not too difficult. What you have there in the Quake III code that's available is the DLL part. Quake III uses three DLLs, one for the user interface, and two for the actual game. The DLLs communicate with the Quake III EXE via a callback function, the address of which the EXE sends the DLL when it's loaded (in vmMain, which is really just DllMain). Then, after initialization, the EXE sends the DLL messages every frame, and the DLL deals with them (mods just change the way in which messages are handled). The DLL then passes rendering calls to the EXE, which does all the rendering, using a highly optimized system. The DLL also calls the EXE to load shaders, models and other assets, and EXE returns handles to these which the DLL uses to reference them.

The point is, I started out knowing nothing about the Quake III source code, what it did, or how it did it. I simply looked through the code, and began to understand what everything did. I wrote stuff down, and drew little box diagrams to figure out which functions called other functions, and gradually, I began to understand. When you look at the big picture for Quake III, you understand how it was planned out, and the principles of the engine design. It's a very clever system. However, as it's been mentioned, learning from other people's source can be extremely difficult. You get the end product, but none of the steps it took to get there. I've got used to this, though. I look at other people's code (tutorials, professional code, etc.), and figure out my own steps. But I can only do this because I've been programming for ages. I didn't even try to figure out the Quake III source until I felt I was ready. This has happened a few times, but it's only been recently that I could do it. And anyway, I started out coding silly little DOS programs, so did John Carmack, and pretty much everyone else who codes in C and C++ today, so keep at it ...

EDIT: btw, if you're looking for a decent OpenGL book, take a look at The OpenGL SuperBible...



Coding Stuff ->  [ iNsAn1tY Games | DarkVertex | How To Do CSG | Direct3D Vs. OpenGL | Google ]
Fun Stuff    ->  [ Evil T-Shirts | Stick-Based Comedy | You're Already Here | The Best Film Reviews ]


[edited by - iNsAn1tY on July 4, 2003 8:05:15 AM]

Share this post


Link to post
Share on other sites
quote:
Original post by iNsAn1tY
I understand Quake III. I didn''t at first, but then I mapped out the functions Carmack used in my head, and figured out how the whole thing works. It''s not too difficult. What you have there in the Quake III code that''s available is the DLL part. Quake III uses three DLLs, one for the user interface, and two for the actual game. The DLLs communicate with the Quake III EXE via a callback function, the address of which the EXE sends the DLL when it''s loaded (in vmMain, which is really just DllMain). Then, after initialization, the EXE sends the DLL messages every frame, and the DLL deals with them (mods just change the way in which messages are handled). The DLL then passes rendering calls to the EXE, which does all the rendering, using a highly optimized system. The DLL also calls the EXE to load shaders, models and other assets, and EXE returns handles to these which the DLL uses to reference them.

The point is, I started out knowing nothing about the Quake III source code, what it did, or how it did it. I simply looked through the code, and began to understand what everything did. I wrote stuff down, and drew little box diagrams to figure out which functions called other functions, and gradually, I began to understand. When you look at the big picture for Quake III, you understand how it was planned out, and the principles of the engine design. It''s a very clever system. However, as it''s been mentioned, learning from other people''s source can be extremely difficult. You get the end product, but none of the steps it took to get there. I''ve got used to this, though. I look at other people''s code (tutorials, professional code, etc.), and figure out my own steps. But I can only do this because I''ve been programming for ages. I didn''t even try to figure out the Quake III source until I felt I was ready. This has happened a few times, but it''s only been recently that I could do it. And anyway, I started out coding silly little DOS programs, so did John Carmack, and pretty much everyone else who codes in C and C++ today, so keep at it ...

EDIT: btw, if you''re looking for a decent OpenGL book, take a look at The OpenGL SuperBible...



Coding Stuff ->  [ iNsAn1tY Games | DarkVertex | How To Do CSG | Direct3D Vs. OpenGL | Google ]
Fun Stuff    ->  [ Evil T-Shirts | Stick-Based Comedy | You''re Already Here | The Best Film Reviews ]


[edited by - iNsAn1tY on July 4, 2003 8:05:15 AM]


An outstanding post!



Beginners and experts will find answers here.

Share this post


Link to post
Share on other sites
quote:
Original post by iNsAn1tY
Why thank you [takes a little bow]



Coding Stuff -> [ iNsAn1tY Games | DarkVertex | How To Do CSG | Direct3D Vs. OpenGL | Google ]
Fun Stuff -> [ Evil T-Shirts | Stick-Based Comedy | You''re Already Here | The Best Film Reviews ]


[edited by - iNsAn1tY on July 4, 2003 2:57:26 PM]



R E C S P E T - rescept. Man you deserve it

.lick

Share this post


Link to post
Share on other sites