6 hours ago, ferreiradaselva said:

In addition to what @Oberon_Command, we have good version control software for that task.

Yes but those tools did not exist back then, or if so it's unlikely they used them.

6 hours ago, ferreiradaselva said:

To let it be clear: I'm not shitting on Carmack (or his team) work, but I can't help to feel bothered when I see the DOOM/Quake code being pushed as holy to beginners. And it's not.

I think it's worth to learn how the algorithms work, it's not even necessary to look at the code for this reason.

I'm sorry for turning down your post point by point. I assume you have not done a project of that size yourself yet? If so your critique is much too hard to be justified. I also assume you base your critique on things you learned from others, and not on terrible experience with those 'bad coding practices'. Correct me if i'm wrong and sorry again if so.

There is one point i really disagree with others here:

If id code is not recommended to beginners, what alternatives do they have? Is none better than imperfect?

But most importantly:

After reading this post i have the intention learning HOW to write code is more important than problem solving skills, and this sucks. A beginner programmer should learn to solve problems first. It's easy to follow coding standarts after this, it's a never ending trail of failure trying to write reusable code with reasonable effort, but what matters are problem solving skills. If you don't like he uses global variables, just tell him he shouldn't. Done. If you you don't like the fact he does not know what a BSP tree is, well, have fun in explaining him.

Quake was for DOS.

DOS is way better for game programming then Windows, thats why DirectX exists to make fast games.

So as it looks now you have to learn not only Quake code, you also have to learn the Windows API, and DirectX API.

Maybe for your own learning purpose you could use DOS ?, i dont know if that is still possible.

1 hour ago, the incredible smoker said:

DOS is way better for game programming then Windows, thats why DirectX exists to make fast games.

Why do you think this?

21 hours ago, Infinisearch said:

Why do you think this?

Think what ?, DOS better then Windows ?, or why DirextX exists ?

Its both true, why do you think something else ?

DirectX is mainly a abstraction to access GPU. DOS had this too, remember 3Dfx Glide.

It's easier to use DirectX than to write a software rasterizer, and today better spend your time on learning something else than software rasterization (except you have a good reason or you are Bruce Dell  )

It's also MUCH easier to work with Windows than with DOS. Remember those horrible close to metal tricks with VGA / EGA modes, Soundblaster vs. Gravis Ultrasound. Just annoying and nothing to learn at all.

Windows does a lot things inefficient and even in the background which is bad for games, but this has nothing to do with learning.

2 hours ago, the incredible smoker said:

Think what ?, DOS better then Windows ?, or why DirextX exists ?

Its both true, why do you think something else ?

On 11/8/2017 at 10:37 AM, the incredible smoker said:

DOS is way better for game programming then Windows, thats why DirectX exists to make fast games.

Why do you think that "DOS is way better for game programming then Windows"?  I'm asking you to justify it on a technical level.

And yes I do think something else.

2 hours ago, JoeJ said:

It's easier to use DirectX than to write a software rasterizer,

Its also easier to use DirectX than it is to write to the metal on different 3d hardware or even one piece of 3d hardware.

2 hours ago, JoeJ said:

Windows does a lot things inefficient and even in the background which is bad for games, but this has nothing to do with learning.

The background stuff I agree with but besides that what exactly is 'inefficient' for games?

5 minutes ago, Infinisearch said:

The background stuff I agree with but besides that what exactly is 'inefficient' for games?

For example the memory allocation issue you linked for some time in a APG thread. The issue was introduced with creators update, probably got fixed with the current update, and now everybody praises MS because they increased game performance
 

Another (much worse) issue is MSVC compiler, see http://newtondynamics.com/forum/viewtopic.php?f=9&t=7580&sid=1f438d585be593e62506e7cd5e6411cc&start=45

7 minutes ago, JoeJ said:

For example the memory allocation issue you linked for some time in a APG thread.

Could you link that thread?  I don't remember it.

7 minutes ago, JoeJ said:

and now everybody praises MS because they increased game performance

In what way?  Are you talking about game mode (or whatever it was called)?  IIRC that has actually decreased performance last time I checked.

edit - I also wouldn't consider a compiler issue a windows issue.

1 hour ago, Infinisearch said:

Could you link that thread?  I don't remember it.

It linked to this IIRC (don't know if they really fixed tis, just guessing): https://forum.beyond3d.com/threads/efficient-memory-mapping-page-fault-performance-bugs.60401/

But i can't find the test of improved game performance with Fall Creators Update anymore, i remember to read it on 2 sites, test with 10 games, something about 10% better performance. At least Forza7 is known to have no more stuttering. But while searching i found also reports of decreasing performance.

1 hour ago, Infinisearch said:

edit - I also wouldn't consider a compiler issue a windows issue.

They compile Windows with it, so it affects both OS and games.

On 11/6/2017 at 11:03 PM, JoeJ said:

Yes but those tools did not exist back then, or if so it's unlikely they used them.

We have the tools now. We shouldn't keep around practices that are built around obsolete development paradigms. We certainly shouldn't teach them to beginners.

On 11/6/2017 at 11:03 PM, JoeJ said:

If id code is not recommended to beginners, what alternatives do they have? Is none better than imperfect?

There is no such thing as "holy" code. There are no perfect codebases. That's just the nature of software "engineering." I would never tell a beginner that any particular codebase represents the canonical way to structure and implement a game. There is no such thing. I would go so far as to suggest that anyone who tells you they have a perfect codebase is selling you something.

If such a thing even existed, it certainly wouldn't be from the mid-'90s. It has been 20 years since Quake came out. Approaches that were optimal then are no longer optimal on modern hardware, for modern games. Our understanding of what constitutes "good design" has evolved considerably. I strongly doubt anybody would write a modern game the way Quake was written.

There may well be instances where I could recommend that a beginner look over a part of a larger codebase for inspiration or as a reference for implementing a particular algorithm. I struggle to think of any specific example of such offhand and I definitely wouldn't recommend an entire codebase as an example.

I recall encountering someone on the GDNet chat who structured their code in a complex, boilerplate-y way (for what they were doing) who when asked why they chose that approach, said "that's how Unreal/CryEngine does it." That's not an attitude I want to encourage.

On 11/6/2017 at 11:03 PM, JoeJ said:

A beginner programmer should learn to solve problems first. It's easy to follow coding standarts after this, it's a never ending trail of failure trying to write reusable code with reasonable effort, but what matters are problem solving skills. If you don't like he uses global variables, just tell him he shouldn't. Done. If you you don't like the fact he does not know what a BSP tree is, well, have fun in explaining him.

Broadly-speaking, I would agree that beginners should start off by learning to solve problems, but we should also actively discourage bad habits from forming while they're still learning. Overuse of global state (or use of any global state, depending on whom you ask) is widely considered to be a bad habit. So are deep inheritance hierarchies and the use of inheritance for code reuse, which are widely caricatured features of a lot of late '90s codebases.