Half Life 1 Engine vs Source Engine

New Member
Joined
Dec 19, 2004
Messages
5
Best answers
0
ESF Final is really looking great, from a graphics perspective. The Half Life 1 engine has been pushed to do things that most thought impossible. That said... we're 9 years since a stable release of ESF, and 9 years from the release of the Source engine (8 years since Half Life 2).

I remember many years ago, the ESF team made the decision to keep the project on the Half Life 1 engine.

In retrospect, was it worth the effort spent trying to hack the Half Life 1 engine into submission so it could look this incredible, or would the ESF team had an easier time/been better off moving ESF to the Source engine? I'd be curious to hear from one of the devs, but feel free to speculate yourselves...

*Disclaimer: This subject is impossible to discuss without sounding like I'm asking when the game is coming out. While I am curious (who isn't!? :) ), that is not the case. It is meant to be a frank discussion on whether the choice not to move ESF to Source, the choice that was made many years ago, was the right choice or the wrong choice.*
 
Judge. Jury. Executioner
👮 Moderator
★ Black Lounger ★
💻 Oldtimer
Joined
Aug 26, 2010
Messages
2,241
Best answers
1
I am curious on this as well. I remember the devs stating that they chose Goldsrc because they had the most experience on it, and that Source was a pain to work with. I wonder if that sentiment has changed.
 
New Member
💻 Oldtimer
Joined
Mar 13, 2005
Messages
3,877
Best answers
0
Well I think they literally just turned the Goldsrc engine into their own engine to be honest. I mean they know the ropes on this engine and have the best looking game on this engine currently.
 

Eon

TeeHee
💻 Oldtimer
Joined
Dec 20, 2002
Messages
5,342
Best answers
0
Source is a nightmare to work with if you want a range of full 3d motion while flying.


Honestly the only knock on still using goldsrc is the limitation of only using 1 CPU
 
I LOVE KITTIES!
Joined
Apr 3, 2013
Messages
56
Best answers
0
Source is a nightmare to work with if you want a range of full 3d motion while flying.


Honestly the only knock on still using goldsrc is the limitation of only using 1 CPU
Well if dev's customized GoldSrc engine to have Wertex weights and animation blends and more, can't they modify the engine to use more than 1 CPU?
Is it above the law or something, if it's coded somehow it can be re-coded too, can it?
 
Freelance Mappzor
💻 Oldtimer
Joined
Nov 21, 2003
Messages
17,065
Best answers
0
Source is great for FPS or similar material. The moment you want to do something extra, it becomes a nightmare due to its limitations and user-friendliness. It literally holds people hand and tells them they cant do something because it might be bad, and that in some cases can lead to greater heights if you know what i mean.

Basically its like comparing C++ to Java.

C++ doesnt hold your hand and lets you do what you want, giving you greater freedom, but also has a risk of doing something really stupid like overwriting a reserved memory location with random data possibly leading to a system crash ^^
Java doesnt let you do that. It tells you that what you are doing may be dangerous and thus wont let you do it. Its a bit more limited for the extra protection (this also depends on the compiler you are using though).

Both are great at what they do, both are used everywhere, yet there are specific cases where you would pick one over the other.

@Arthas we dont have access to the core of HL itself. We are only bypassing systems and substituting them with our own. but because we have no access to the core, we cant really do a thing about the CPU thing.
 
Proud owner of Half-Life
Joined
Jan 24, 2012
Messages
40
Best answers
0
So the conclusion is that GoldSrc engine is much more developer-friendly than Source engine ?
 
Freelance Mappzor
💻 Oldtimer
Joined
Nov 21, 2003
Messages
17,065
Best answers
0
YEsand no. The GoldSRC lets you tinker with it more, while Source is easier for FPS or similar stuff.
 
Super Cool Wicked Guy
Staff Member
Joined
May 27, 2006
Messages
478
Best answers
0
Well you can Bypass more Engine related code(not published from Valve) in GoldSRC than in Source Engine. And yeah the source engine is rly a nightmare to work with

--- edit ---

Well you can Bypass more Engine related code(not published from Valve) in GoldSRC than in Source Engine. And yeah the source engine is rly a nightmare to work with
 
Steam Registered User
Joined
Apr 7, 2013
Messages
620
Best answers
0
Well if dev's customized GoldSrc engine to have Wertex weights and animation blends and more, can't they modify the engine to use more than 1 CPU?
Is it above the law or something, if it's coded somehow it can be re-coded too, can it?
I'm not exactly one who knows about using C++ in 3D space, but from what I know about it, the C++ code is converted into .dll files. They are machine code by then, and anything that the machine doesn't need to know, (comments, things the compiler might infer,), is vented and deleted. YOu can get a few rather good dll decompilers/decoders, but they won't give you back working source code.

I can only assume that the devs struggled through and edited the available stuff in the (badly decompiled) source code, or maybe even the stuff that wasn't in a .dll file, i don't know, but perhaps the bit about the 1 CPU is encoded through the whole thing, and can't be effectively edited without a very (very) long period of trial and error. All in all, it isn't worth it.

The Source engine is so fixed down to the Half Life 2 way of 'being', that it is difficult to do much with it unless you are making an explicitly HL2 mod, or TF2, or any other game that uses the Source engine. The flying in Source is so ridiculous, it's unusable. You will often get glitches, like 'bacon legs', if you run down into the ground while flying and crouched, and stop crouching, your legs will contort awkwardly and in an ugly fashion.

I've heard the way the skeleton must be made, it is awkward to give it a variety of movements. The engine in general is prone to glitching, and sometime that can be due to how 'free' the physics are. In Goldsrc the physics are more limited, thus giving significantly less glitches in that department. If you ram a box into someone in HL2, on the source engine, the box is likely to kick up a lot of dust and flicker about, side to side. On the GoldSrc engine, you can't pick boxes up, but if you were to push one into someone, the box would simply stop in it's tracks, and the NPC would continue to walk on it's path.
 
The very best there is.
Joined
Jan 23, 2011
Messages
516
Best answers
0
Reverse engineering is (mostly) illegal. The 1 CPU "limit" is an architectural problem that can't be solved without creating, in essence, a new engine.
 
Retired
Joined
Nov 24, 2001
Messages
692
Best answers
0
As far as I know you can use multiple CPUs in GoldSrc (unless there are some VAC checks in place to prevent this or there are limitations on what a dll is allowed to do that I'm unaware of). I remember LoD playing around with loading the game in a different thread and green tinkering with openmp. We toyed with the idea of making ESF multithreaded, but decided that the potential benefits would not outweight the debugging nightmare and extra development time introduced by it.
 
Freelance Mappzor
💻 Oldtimer
Joined
Nov 21, 2003
Messages
17,065
Best answers
0
I'm not exactly one who knows about using C++ in 3D space, but from what I know about it, the C++ code is converted into .dll files. They are machine code by then, and anything that the machine doesn't need to know, (comments, things the compiler might infer,), is vented and deleted. YOu can get a few rather good dll decompilers/decoders, but they won't give you back working source code.

I can only assume that the devs struggled through and edited the available stuff in the (badly decompiled) source code, or maybe even the stuff that wasn't in a .dll file, i don't know, but perhaps the bit about the 1 CPU is encoded through the whole thing, and can't be effectively edited without a very (very) long period of trial and error. All in all, it isn't worth it.

The Source engine is so fixed down to the Half Life 2 way of 'being', that it is difficult to do much with it unless you are making an explicitly HL2 mod, or TF2, or any other game that uses the Source engine. The flying in Source is so ridiculous, it's unusable. You will often get glitches, like 'bacon legs', if you run down into the ground while flying and crouched, and stop crouching, your legs will contort awkwardly and in an ugly fashion.

I've heard the way the skeleton must be made, it is awkward to give it a variety of movements. The engine in general is prone to glitching, and sometime that can be due to how 'free' the physics are. In Goldsrc the physics are more limited, thus giving significantly less glitches in that department. If you ram a box into someone in HL2, on the source engine, the box is likely to kick up a lot of dust and flicker about, side to side. On the GoldSrc engine, you can't pick boxes up, but if you were to push one into someone, the box would simply stop in it's tracks, and the NPC would continue to walk on it's path.
Our guys are using the HL SDK >.>
 
Super elite
Joined
Jul 16, 2010
Messages
516
Best answers
0
Wait, substituting? do you mean converting, or combining them. Because that game does look like a source engine. The way how i see it, does has source. And I don't believe that you guys already bypass the system. I just don't get it.
 
The very best there is.
Joined
Jan 23, 2011
Messages
516
Best answers
0
What's there to get? A game consists of various components. Given enough effort, any one of these can be exchanged for an equally (or more) functional replacement component. The Source Engine (notice the capital letters) is the engine powering Half-Life 2 and the likes. Its name is not a reference in any way to source code.
 
Steam Registered User
Joined
Apr 7, 2013
Messages
620
Best answers
0
What's there to get? A game consists of various components. Given enough effort, any one of these can be exchanged for an equally (or more) functional replacement component. The Source Engine (notice the capital letters) is the engine powering Half-Life 2 and the likes. Its name is not a reference in any way to source code.
99% of the time, if you want to make base changes to the Source Engine itself, you need access to the source code of the Source Engine, right? True, you could use the HL SDK, as Grega said, but in order to do things like make it run on more than 1 CPU, you would need access to usable source code. No one can write in machine code, so it would have to be source code.

BTW, I'm not actually sure about the replacing/exchanging components, because as I said, Valve hasn't released the source code for any of the two main engines, and thus it would be difficult to actually read or write the decompiled code, which would be what you need to do, if you want to make changes to the engine itself, right?

That's just my 2 cents.
 
The very best there is.
Joined
Jan 23, 2011
Messages
516
Best answers
0
BS. Of course you can write Assembler. You can even modify a disassembled binary, but it's just no fun. Also, illegal, as said elsewhere.

As for component replacement: Look at ESF. It's living proof. I know the concept might be hard to grasp, but you can replace a black box component. It's just a lot of work. Of course, documented interfaces help a lot. Still, typically no need to reverse engineer anything.

You might want to look into actual programming. The kind that produces PE binaries.
 
Freelance Mappzor
💻 Oldtimer
Joined
Nov 21, 2003
Messages
17,065
Best answers
0
99% of the time, if you want to make base changes to the Source Engine itself, you need access to the source code of the Source Engine, right? True, you could use the HL SDK, as Grega said, but in order to do things like make it run on more than 1 CPU, you would need access to usable source code. No one can write in machine code, so it would have to be source code.

BTW, I'm not actually sure about the replacing/exchanging components, because as I said, Valve hasn't released the source code for any of the two main engines, and thus it would be difficult to actually read or write the decompiled code, which would be what you need to do, if you want to make changes to the engine itself, right?

That's just my 2 cents.
There are ways round that. Our map system for example. The game needs a .bsp file in order to display the map in the server creation menu. So we have a blank file for that, but instead of that file we tell the game "Hey the resources you need to load are actually in this .XML file with the same name as the .BSP" And in a nutshell thats kind of how the new map format works. We disabled all collision on the BSPs, disabled the rendering of the BSPs and simply loaded the new maps on top of the old ones. Of course our placeholder BSP is pretty much a small box with nothing in it to ensure the loading of the BSP is as fast as possible so that the game can focus on the actual resources being used.

So we havent per se removed the old system and replaced it with a new one, we simply disabled any interaction a player might have with the old system and loaded the new one on top. Thats why we had no need to redefine the actual HL map format itself.

Ofcourse this explanation is just a really REALLY simplified way of explaining the process, so dont jump me if you know your coding.
 
Steam Registered User
Joined
Apr 7, 2013
Messages
620
Best answers
0
BS. Of course you can write Assembler. You can even modify a disassembled binary, but it's just no fun. Also, illegal, as said elsewhere.

As for component replacement: Look at ESF. It's living proof. I know the concept might be hard to grasp, but you can replace a black box component. It's just a lot of work. Of course, documented interfaces help a lot. Still, typically no need to reverse engineer anything.

You might want to look into actual programming. The kind that produces PE binaries.
As I said, I don't know much about C++, in fact I'm barely a newbie. I didn't know that machine code = Assembly! :D

Also, no need for quite so many snarky comments, please. :p
 
The very best there is.
Joined
Jan 23, 2011
Messages
516
Best answers
0
Well, it's not exactly the same. Assembly code is a textual representation of the low-level commands that are sent to your CPU.

It's good to have a mental model of what's going on, but please refine it before posting walls of text based on it. :)
 

Users Who Are Viewing This Thread (Users: 0, Guests: 1)

Top