4 ms·

Any advice on how to dive into reading this codebase?

by gcv 15y ago

deleted 15y ago
[deleted]
- JonnieCache 15y ago
  It's more a legal thing which you will see with any commercially released codebase. The iD hackers have to jump through innumerable hoops with their publishers' legal department to get this code out to us at all, so it kinda sounds ungrateful to moan about the licenses. Also, different parts of the code are covered by many different licenses and the copyright on them belongs to many different people, so it is important to be very explicit about everything. When it's an OSS project owned and operated by a small group of people, there's little motivation to worry about this stuff. Also when you choose a license like the MIT one which basically says "I really don't give a fuck what you do unless you sue me," you have a lot less incentive to plaster it over everything, because you're one step away from being in the public domain anyway. When you're releasing the doom3 code, things are very different.
  - frou_dh 15y ago
    EDIT: Deleted my GP post to stem conflict. What I meant (probably poorly phrased) is that for readability for personal study (like gcv was asking about), I think it's worth stripping huge license preambles from source files. There's obviously good legal reason for them being present to start with.
    - jerf 15y ago
      You're a quick couple of shell commands away from stripping them off yourself, if it's that big a deal.
cobrausn 15y ago
I've heard the best way to tackle the Quake codebase was to pick a 'component', such as the renderer, and start to understand how that works. Work your way out, one component at a time. Eventually the bigger picture comes together. The same would probably work for this, though unless you're well versed in game and graphics programming nomenclature some of it will go over your head, which is expected - when you see something like that, think of it as an opportunity to learn a new concept and look it up.
corysama 15y ago
My favorite technique is to run the code, place breakpoints in interesting locations and manually type out psuedocode descriptions of each function up the callstacks. That's the fastest way I know to get an understanding of the structure of a new code base. Barring running the code... I prefer to start with a quick scan through the foundation code. What does the math library look like? How about the file and network I/O? Next, locate the top-level main loop, then the top-level Update Everything/Render Everything functions. At that point, you'll understand the general theme of the code and you'll have spotted lots of interesting avenues to explore.
JabavuAdams 15y ago
doxygen EXTRACT_ALL
mqqq 15y ago
Don't waste your time. It doen't have anything ground breaking.

Any advice on how to dive into reading this codebase?

by gcv 15y ago

Any advice on how to dive into reading this codebase?

deleted 15y ago

[deleted]

JonnieCache 15y ago
It's more a legal thing which you will see with any commercially released codebase. The iD hackers have to jump through innumerable hoops with their publishers' legal department to get this code out to us at all, so it kinda sounds ungrateful to moan about the licenses. Also, different parts of the code are covered by many different licenses and the copyright on them belongs to many different people, so it is important to be very explicit about everything. When it's an OSS project owned and operated by a small group of people, there's little motivation to worry about this stuff. Also when you choose a license like the MIT one which basically says "I really don't give a fuck what you do unless you sue me," you have a lot less incentive to plaster it over everything, because you're one step away from being in the public domain anyway. When you're releasing the doom3 code, things are very different.
- frou_dh 15y ago
  EDIT: Deleted my GP post to stem conflict. What I meant (probably poorly phrased) is that for readability for personal study (like gcv was asking about), I think it's worth stripping huge license preambles from source files. There's obviously good legal reason for them being present to start with.
  - jerf 15y ago
    You're a quick couple of shell commands away from stripping them off yourself, if it's that big a deal.

cobrausn 15y ago

I've heard the best way to tackle the Quake codebase was to pick a 'component', such as the renderer, and start to understand how that works. Work your way out, one component at a time. Eventually the bigger picture comes together. The same would probably work for this, though unless you're well versed in game and graphics programming nomenclature some of it will go over your head, which is expected - when you see something like that, think of it as an opportunity to learn a new concept and look it up.

corysama 15y ago

My favorite technique is to run the code, place breakpoints in interesting locations and manually type out psuedocode descriptions of each function up the callstacks. That's the fastest way I know to get an understanding of the structure of a new code base. Barring running the code... I prefer to start with a quick scan through the foundation code. What does the math library look like? How about the file and network I/O? Next, locate the top-level main loop, then the top-level Update Everything/Render Everything functions. At that point, you'll understand the general theme of the code and you'll have spotted lots of interesting avenues to explore.

JabavuAdams 15y ago

doxygen EXTRACT_ALL

mqqq 15y ago

Don't waste your time. It doen't have anything ground breaking.