Half Life Pandora Port


Muggie

Still Fresh
Joined
Aug 8, 2011
Messages
69
I was wondering if anyone was working on or playing with getting Half Life and other Gold Source games working on the Pandora. Valve has released the source code and SDK of the game and I was wondering if anyone was thinking of porting it. Who wouldn't want to t play HL, CS, TFC, and other Gold Source games on their Pandora?


Here's the source and stuff I found after digging around. I believe everything is there in those files.


http://metamod.sourceforge.net/files/sdk/
 
I was wondering if anyone was working on or playing with getting Half Life and other Gold Source games working on the Pandora. Valve has released the source code and SDK of the game and I was wondering if anyone was thinking of porting it. Who wouldn't want to t play HL, CS, TFC, and other Gold Source games on their Pandora?


Here's the source and stuff I found after digging around. I believe everything is there in those files.


http://metamod.sourceforge.net/files/sdk/

SDK's are not the full source.
 
Valve never open-sources their stuff. I bet the only reason no one's made an engine rewrite of it is because of it's modability.
 
I started a thread on this many moons ago. Half-Life is a windows game that runs on the gold-source engine. Technically, the Pandora may be able to run the graphics, but since Valve hasn't released the source code for the engine, there's no way to create a port for the Pandora.


In short, No. It cannot be done.
 
Half Life was going to come out on the Dreamcast but then was canceled. I know that its still floating around somewhere. With a Dreamcast emulator running on the Pandora, perhaps we can play HL with that? Or is that too far fetched?


This video got me excited for a Dreamcast Emulator. :)

https://www.youtube.com/embed/vXJ0WtWGRLE?feature=oembed
 
The SDK DOES contain the full source code to the Half Life engine. It does not contain certain Half Life specific files like the maps (those are easy to get if you own Half Life, though). There are 2 .dll files that the engine relies on with no included source. One of those .dll's can easily be removed, but vgui.dll cannot. There is no linux version of that file. I have looked into using winlib to create a wrapper .so file for vgui.dll and it seems possible. Other than that, you'd just need to fix up the code to compile on modern versions of gcc. Current versions of gcc complain about all sorts of things in the source code, but they're easily fixable (it just takes a lot of time). I did compile a complete Half Life server on linux using the source files in the SDK. I didn't bother trying to get the Half Life client files to compile because of the issue of vgui.dll and because they weren't meant to be compiled on linux, so there are no makefiles that come with the SDK for compiling the Half Life client. You'd have to make your own, which isn't really a problem.


Oh and the SDK that Muggie linked to just contains the source code files, and none of the useful documentation and tools that comes with the full version of the SDK. If you do want to look over the code, get hl_sdk_v23_source.exe and then apply the patch called hl_sdk_v23_source-update-p3.zip


I'll try to look around and find the full version of the SDK that has extra documentation.


In short, I think the biggest problem is dealing with vgui.dll. Everything else (besides procinfo.dll, which is easily replaceable) has the full source code included and can be compiled after the code is "fixed" to compile on modern versions of gcc. I believe it is possible to create a wrapper .so using winelib, but I haven't tried. Someone else should look into this and see if they can pull something off.
 
it wasnt ari's first post, but impressive sir...not everybody can argue pickle with knowledge
 
Winelib won't help here, as this is an ARM system. But really, is the SDK the full source? Are you sure about that? Why hasn't somebody else attempted to compile the client for ARM then? Just because of some missing lib? Some people write whole replacement engines... I can't believe that...
 
In short, I think the biggest problem is dealing with vgui.dll. Everything else (besides procinfo.dll, which is easily replaceable) has the full source code included and can be compiled after the code is "fixed" to compile on modern versions of gcc. I believe it is possible to create a wrapper .so using winelib, but I haven't tried. Someone else should look into this and see if they can pull something off.
No it has not! It's just game logic code, no rendering code there, have you actually looked at it close enough? It's more or less useless unless you want to host dedicated server on pandora, and I'm quite sure even that has missing bits.
 
Last edited by a moderator:
No it has not! It's just game logic code, no rendering code there...

OK what do you mean by game logic, and what do you mean by rendering code? Because if it is genuinely just rendering stuff (and maybe sounds) missing then surely they can be worked out? GoldSource is after all modelled on the Quake engine. The WADs can handle more colours (possibly higher resolutions too, not 100% on that) and the BSPs probably contain custom objects (game logic?) so I can't see how its immediately written off as impossible to work from the SDK.
 
No it has not! It's just game logic code, no rendering code there...

OK what do you mean by game logic, and what do you mean by rendering code? Because if it is genuinely just rendering stuff (and maybe sounds) missing then surely they can be worked out? GoldSource is after all modelled on the Quake engine. The WADs can handle more colours (possibly higher resolutions too, not 100% on that) and the BSPs probably contain custom objects (game logic?) so I can't see how its immediately written off as impossible to work from the SDK.

The amount of effort it would take to reverse engineer and simulate the how the original game worked in every aspect work would take forever to achieve.. I mean feel free anyone who would want to take on such an endeavor.. but you might as well be making a brand new game on the amount of work involved.
 
Last edited by a moderator:
No it has not! It's just game logic code, no rendering code there...

OK what do you mean by game logic, and what do you mean by rendering code? Because if it is genuinely just rendering stuff (and maybe sounds) missing then surely they can be worked out? GoldSource is after all modelled on the Quake engine. The WADs can handle more colours (possibly higher resolutions too, not 100% on that) and the BSPs probably contain custom objects (game logic?) so I can't see how its immediately written off as impossible to work from the SDK.

The amount of effort it would take to reverse engineer and simulate the how the original game worked in every aspect work would take forever to achieve.. I mean feel free anyone who would want to take on such an endeavor.. but you might as well be making a brand new game on the amount of work involved.

It's not every aspect though is it. The SDK contains weapon, NPC and enemy functionality at the very least. If it does also contain details of the custom entities added since the quake code they took the engine from I can't see how there's all that much to do. Even the stuff not included in the SDK wouldn't all have to be reverse engineered because it is a continuation of the quake engine (don't tell me that isn't open source).
 
It's not every aspect though is it. The SDK contains weapon, NPC and enemy functionality at the very least. If it does also contain details of the custom entities added since the quake code they took the engine from I can't see how there's all that much to do. Even the stuff not included in the SDK wouldn't all have to be reverse engineered because it is a continuation of the quake engine (don't tell me that isn't open source).


If it was easy to do as chucking the PAK files in and making a few changes this would of been done years ago... Valve heavily modified the engine(they claim 75% of the code is their own), including how it handles the maps, Artwork and sound not to mention their AI scripting and graphics rendering.. I'm sure someone can make a Deathmatch total conversion that may almost feel like the real game.. but forget single player.
 
After looking through it again, I'm not sure if the SDK contains the full client gold source engine, but it definitely does contain the source files required for the Half Life "addon" to the engine.


In the full version of the SDK (which has extra documentation over the one posted above), there is a file called ReadMe.txt, In that it says:

Single-Player Source:
=====================


The directory containing all the code required to rebuild hl.dll.
All games running on that engine work as .dll files and the engine itself is unmodified between them. Half Life is no exception. But, without the gold source engine itself, then being able to compile hl.dll (or .so on linux) is kind of useless. The SDK does contain the full server source, which should have most of the gold source engine, since the world simulation is all done server side. The server source does not contain any rendering code, for obvious reasons.


The SDK does contain the source required for the Half Life specific .dll to be compiled. So, if the full SDK contains the source to the client side gold source engine, then this is doable, which vgui.dll being the main problem. Otherwise, the engine itself needs to be mostly rewritten (I say mostly because the source to the server is there and it SHOULD contain the majority of the gold source engine).


EDIT: And attempting to use the Quake engine code might help with rewriting the engine if it comes to that, but the majority of the code to the gold source engine is not the same as the Quake engine.
 
Last edited by a moderator:
Getting Half Life to work on a hand held system would be revolutionary. Is anyone going to take a shot at it? They would be a hero in my book! ^_^
 
The SDK does contain the source required for the Half Life specific .dll to be compiled. So, if the full SDK contains the source to the client side gold source engine, then this is doable, which vgui.dll being the main problem. Otherwise, the engine itself needs to be mostly rewritten (I say mostly because the source to the server is there and it SHOULD contain the majority of the gold source engine).
Don't know how can you say vgui (= game menu I think) is the main problem when entire part of the engine that does graphics/input/sounds is missing (I think that used to be in sw.dll/hw.dll + the hl.exe itself).


And don't tell me you can just stick Quake code in there, even if you manage that somehow you won't get anything close to HL. Feel free to prove me wrong (but with actions, not words).
 
Last edited by a moderator:
Back
Top