Provide evidence to support your claim.

This is one case where I do know what I'm talking about. The source engine was not coded from scratch. It heavily relies on the legacy code from the goldsrc engine, which is a modification of the quakeworld engine.

I did not say that they used the engine directly, but that most games (especially in the fps genre) use legacy code from the original id Tech. (Engine behind doom and quake.)

If by "relies heavily" you mean "all the quake code has been replaced", then yes. The source engine started out as a fork of GoldSrc (hence where the name comes from), but there is very little (if any) Quake code left. Certainly nothing that would prevent a language transition. In fact, there was a minor language transition. Quake and Doom engines are written in C, the Source engine is C++.

No, they don't. Very few games use Quake or Doom derivatives. An extreme minority of games. Even id games don't use old id code. The Doom 3 engine was a complete rewrite from scratch. Graphics APIs have changed DRASTICALLY since Quake and Doom (and by that I mean there *ARE* graphics APIs now).

Of course, you are also implying that Quake and Doom used the same engine. They most certainly did not. Not only is it not the same engine, it isn't even the same rendering method. The two engines are *extremely* different.

How about this, you take a look into the source code. There is a whole set of legacy files that include basic things (like brush constrution) from goldsrc and the original id Tech.

If games didn't use legacy code from the old id Tech, why are we still using brushes? Polygon mapping is much better for both the artist and the engine. (See: Fallout 3)

I am referring to id Tech 1, the polished and distrubed version of the engine running quake. It retains legacy code from doom. It would be a horrible decision to recode every last piece of code when upgrading an engine.

Hello SigFig

Sure, send me the source code. I'm assuming you have it, right? I'm sure you, someone who doesn't know C++ and thinks you can make a competitive game engine in Python, has gone and licensed the Source engine and can actually understand the code

We are using algorithms and optimizations techniques from the old days, but not the code. Things like BSP trees are still used today, but the original implementation is most definitely NOT still used.

I can prove this by simply pointing out that Quake I, II, and III and Doom I and II have all been released under the GNU GPL. Any games still using Doom or Quake code either has a license to use it (which they don't because id doesn't publish the code until it stops selling) or is required to publish their own source code.

Of course, what you are claiming is similar to trying to say that every implementation of a linked list is really just a piece of legacy code that has been carried forward. No one other than the inventor has ever created their own linked list - its really just been the same piece of code

Doom I and Quake I share nothing in regards to rendering and level layout. The two engines powering those games are night and day different. id Tech 1 was the engine that resulted from Quake I.

You don't have to license the engine to get access to the source code. Valve openly supports free modding of the Source engine. If you have a Source-based game, you can access the code for it.

Note: When did I say anything about a python game engine being "competitive"? I said it would draw developer attention.

So everyone recoded the entire process, and made it completely new without using older code, but decided to name it the exact same thing and use it the exact same way.

Sounds plausible.

So having access to the code of an older game somehow discourages the developers from a newer game from using it?

I am "claiming" that games retain legacy code from older games. If the BSP method had been completely recoded as many times as you suggested, why is it still called BSP, and why does it retain the same original function?

So, in a blast of innovation, id Software rethought their entire approach to rending a brush, but decided they would make the second, completely new renderer, make things look like the old one.

Nope, not the core engines themselves. Graphics rendering, sound, networking, all those engines aren't provided by the Source SDK. I know this because I have USED the Source SDK. You, clearly, haven't. Which makes sense, since you already admitted you DON'T EVEN KNOW THE LANGUAGE YOU ARE DISCUSSING.

The only attention it would draw would be people saying "Huh, that sure is stupid. Who would waste their time with that?"

http://en.wikipedia.org/wiki/Algorithm

*facepalm*

http://en.wikipedia.org/wiki/GNU_General_Public_License

Could it be because it still does the same thing?
http://en.wikipedia.org/wiki/Binary_space_partitioning

Also, game engines don't all behave and work the same way. Crysis, for example, uses Voxels for its terrain system, not BSPs.

Things like this just make it obvious you've never worked with OpenGL or DirectX. Also, you keep using "brush". Do understand that a brush is *not* a primitive type. A brush is simply a piece of geometry which is itself made up of polygons. Games render using polygons. A brush is an abstract term that has no real meaning to a graphics engine. Also, games don't actually render polygons. They hand the polygons over to OpenGL or DirectX, which in turn passes it on to the driver where it is then rendered by the video card.

Also, optimizations and corner cutting that was needed in the Doom and Quake days aren't needed anymore. Hardware and APIs have changed over the years. Graphics engines must change as well. Heck, even the formats for storing models and textures have changed drastically.

The graphics is standard D3D. Networking is run through steam.

The legacy code, the stuff we're referring to in this argument , is in there.

I, however, fail to see how this pertains to the usage of legacy code in modern video games.

So you're saying that if someone found a way to make it, you would call them an idiot?

I know what an algorithm is. I'm not that misinformed.

Oh look it's that freeware license that I obviously knew about before. Someone want to elaborate on how a link to a wikipedia article I've already read is related to this discussion?

If it's still going to do the exact same thing in the exact same way, why make it again?

I understand what a brush is. I understand that it is not a geometric shape. I've mapped for Source for a hell of a long time.

I also understand that it is not needed with todays graphics processors. If game developers decided to recode absolutely everything when they started a new project, we wouldn't be using them. A solely polygon-based format is much more efficient for both art design and rendering.

That's what I said. If we don't need them now, why are we still using them?

Yeah, uh, no, no, not at all. The major components of the source engine are not included in the SDK. The graphics engine, sound engine, networking engine (which is *NOT* steam by the way) are where any "legacy" code (if it existed) would be.

Proof. I have the steam SDK. Point me to a file where this legacy code exists.

Because you can't code with modern code much less know what is legacy code and what isn't. If you can't read the code, you can't know what the hell it is.

*sigh* Python is slow. Extremely slow. It cannot make a decent graphics engine, or even a decent game engine.

There are OpenGL bindings for Python, go give it a shot. I've only seen it used once, and that was for the 3D for a chess game where the slow performance was irrelevant.

Then why did you ask such a question if you knew it didn't make sense?

Because it *isn't* a freeware license, and you obviously *don't* know what the GPL involves. Go read the article and then re-read your comment. If you posses a brain, you should be able to figure out why what you said is wrong.

There are many reasons. For one, its not the exact same way. Also, it is often coded to fit the system. Then there are things like legality issues. You cannot simply use old code in a commercial product. There are also cases where the algorithm is tweaked or improved, or in the case of Source's use of the BSP file format, heavily modified.

Wait wait wait, so you are claiming you know how graphics engines work internally because you can make a map? Bwahahahaha, yeah, I'm done with this.

3D graphics engines have *ALWAYS* been solely polygon based (most exclusively use triangles, actually). There have *NEVER* been renders that worked directly on abstract concepts like "brushes".

*facepalm* we AREN'T using them. That is what you don't seem to get. *NOBODY* is using Quake I and Doom I code.

From a basic search, I found one that even has "legacy" in it's filename. c_te_legacytempents.cpp/h From that same basic code search, I received a page of results full of implementation of legacy code or the containment of it. For example: in vtf.cpp/h (used for the material system) you can see pieces of code left over from when the game mounted from .wad files.

I don't think my inferior knowledge of C++ impairs my ability to see "//THIS IS CODE FROM GOLDSRC"

When did I refer to the usage of algorithms in games?

"The GNU General Public License (GNU GPL or simply GPL) is a widely used free software license,"

Maybe I'm using the wrong terminology. "Freeware" means free software, correct?

So using the exact same name for a piece of code with the exact same purpose isn't copyright infringement?

If you're going to modify it, wouldn't that be a modification? It doesn't seem like a good idea to me to erase your entire code when optimizing it.

I said I knew what a brush is. You can't map for a game that uses them for long without figuring out what they are, and how the engine uses them.

I'm not talking about the renderer here. The game code in newer games are still using brushes to record where a polygon should be drawn. It seems a much better choice to use solely models.

The fact that engines now use brushes, as we have discussed above, means that unnecessary optimization from older games is being done in modern engines.