![]() |
HL1 For other platforms?
I've been wondering why no one has decided to upgrade the old quake engine so linux/macos users can play hl1 natively.
It seems possible, you'd need to strip out the quake virtual machine and replace it with HL's interface along with a few other major changes but it looks possible. I think it would be pretty cool to see HL running natively on my powermac 7500 ( G4/450 upgraded ). Does anyone know of any legal/technical reasons why this hasn't been done yet? |
Re: HL1 For other platforms?
in that case i would say upgrade that engine and make it look better. HL2 style or something, but then free ;)
|
Re: HL1 For other platforms?
I was thinking about something along the lines of tenebrae for those stencil shadows and per-pixel lighting features but a generic renderer would have to be re-added for those video cards that have no shader capability.
But I think the first steps would be: 1. Decide to use either QuakeWorld or GLQuake 2. Seperate the server from the client 3. Implement the HL engine functions server-side 4. Re-compile the half-life mod for the target os/machine 5. Run it and use debug output to verify its working correctly The client would be fairly simple... - Strip out ALL vgui code from the hl client source - Recompile hl client for target os/machine - Modify quake to use the HL bsp format - Test by having it load a hl map and noclip around - Add client-server networking A lot of work but it seems possible, I just wonder why no one has started already. |
Re: HL1 For other platforms?
use the HLSDK without Valve's HL engine is illegal as it has strict non-free license. You also have to write all MOD codes yourself.
Valve's main purpose to release the HLSDK seems to be get some people working for Value for free (just think about the early age of CS), rather than serving the hobbies or contributing to the community. edit: this one seems can render HL maps: http://fteqw.sourceforge.net/ |
Re: HL1 For other platforms?
Well that sucks, although it shouldn't be hard to replicate HL's entity behaviour - it may even be better to leave it alone and do it in QuakeC and just upgrade the client.
I'll have to look into that quakeworld engine later on, if it can render hl maps then the client is half way there already. As far as the legal issues, is it illegal to use the sdk for referencing things like constants? I can live without it but it would make things so much easier ( thats even if I decide to start it ). Still, the hardest thing would probably be getting hl mdl support working. I'll have to go out and buy an opengl book and learn it before touching any quake code. |
Re: HL1 For other platforms?
Wouldn't it be better to use the q3 engine instead?
|
Re: HL1 For other platforms?
Could be, but the problem remains that if the hl mod code has to be re-written from scratch it won't "feel" the same as the original.
It could be close, but those who would play it again under a new engine would notice a difference. Though quake3 would have a lot of bugs fixed since quake1 it would really increase the system requirements, that and having to rip out the md3 code and put in hl's mdl system. Either way its a lot of work and I'm starting to wonder if its possible to re-write the game code close enough to feel like the orignal hl. |
Re: HL1 For other platforms?
Better use one of the existing, free engines and mod those than :) (Sauerbraten!)
|
Re: HL1 For other platforms?
I'm going to grab the quake3 engine source sometime today and see how difficult it would be to get a half-life bsp loaded.
Even with standard q3 game rules a loaded hl bsp would be a great start. |
Re: HL1 For other platforms?
Ok, so how legal is it to use HL BSP file information contained in bspfile.h?
A lot of code to render this stuff is already in quake3 so making it render a hl bsp shouldn't be too hard if I make 2 seperate code paths for both formats. I still have to write a tool to extract all the textures from HL wads but the information about the format is near non-existant. Still have no idea how to handle models though, I could either add a hl model renderer or just write/use a tool to convert them all to md3s. |
Re: HL1 For other platforms?
Quote:
|
Re: HL1 For other platforms?
Quote:
|
Re: HL1 For other platforms?
Well, I'd need a tool which would extract the textures put them in the format q3 expects and place them in the proper directories.
Since no tool to my knowledge does this I will need to write one. |
Re: HL1 For other platforms?
Look at the Quake 1 compile tools source and take it from there. I believe the only differences are the lightmaps are 32 bit and the textures have individual palettes. It is under GPL.
|
Re: HL1 For other platforms?
"Ok, so how legal is it to use HL BSP file information contained in bspfile.h?"
as long as you write all codes yourself, it should be no problem as the file format is not restricted. but I think it's better to rename all the constant names :) edit: I think there is a HL map decompiler included with the Quake3 source code distribution (the bspc utility), so it should be okay to do so. Also as it's GPL'ed it could be better to copy stuff there. |
Re: HL1 For other platforms?
Well, I'd use the same maps as they come from a half-life installation.
As luck would have it, both quake3 and hldm use the info_player_deathmatch entity as start points aswell as the entity structure in the bsp being the same. Though, im still debating on how to implement this... I could rip out all the q3bsp code, use compile flags or simply allow both types of maps to be used and build function pointers to certain functions depending on the map type being loaded. I'm thinking #3 is the best option, same thing with the renderer. [Edit] I actually might go with the quake 1 engine as I already have it loading a half-life map. The formats are so similar that you only need to set BSPVERSION to 30 inorder for it to load. In-game however it looks like someone painted the BMRF with bloody vomit so I'll have to work on texturing. |
Re: HL1 For other platforms?
Changing the BSP version does not work; I've tried it. You need to convert the lightmap and the texture lump. Each of the textures have a palette stored with them in HL, and in Quake they use the main palette. I am pretty sure that the lightmaps in HL are 24 bit also. They could be paletted, though.
Anyway, a texture in HL would be like this: Code:
uchar r; Code:
char *data; |
Re: HL1 For other platforms?
Yeah, I know its different which is why the level came out looking like crap.
I'll have to write some new functions to handle the different textures/lightmaps but thats a job for tomorrow. |
Re: HL1 For other platforms?
Shit! I was going to give you some pseudo-code, but somehow my page got changed and I lost it. Oh well, I am sure you have the skills to do it. If not, I can help.
|
Re: HL1 For other platforms?
Bah!
The palette size should be at file_base + offset_to_mip_level_4 + ( ( tex_width * tex_height ) / 64 )... But it isn't. I have a document here that says the palette size is an word ( unsigned short ) after the 4th miplevel texture and that it should be 256. I get nowhere near that number. |
Re: HL1 For other platforms?
I thought the palette size was 256*3. If it is 256*2, then the format would be RRRRRGGGGGGBBBBB. That is a little bit more complicated to convert. It would be like this:
red = ((entry >> 9) * 255 / 31; green = ((entry << 5) >> 10) * 255 / 63; blue = ((entry << 11) >> 11) * 255 / 31; BTW, some textures are in WADs. It appears that the ones in WADs have no offset. |
Re: HL1 For other platforms?
I think it means 256 entries of 3 bytes, but thats working now I have a pointer to the palette.
The only problem now is converting it to a bitmap, I have next to no experience with images so this will take me a bit longer to figure out. I think its something like... u32 Pixel = SDL_MapRGB( format, palette[ pixel_data[ i ] ], palette[ pixel_data[ i + 1 ] ], palette[ pixel_data[ i + 2 ] ] ); Btw, this is in a seperate app now as I want to make sure it works before trying it in quake. Unfortunately I get nothing but garbage in the screen. |
Re: HL1 For other platforms?
Damn it happened again!
Anyway, use the data of a texture to look up an entry in the palette. Make sure you do it three times; one for each color. Then just copy it into wherever it needs to go. Also, make sure that you aren't accidentally mixing up length and width. I've done that before. |
Re: HL1 For other platforms?
Well, the darkplaces engine supports both half-life BSPs and wad3 files aswell as some pretty nice rendering enhancements like bloom, realtime lighting, ect...
I really should have looked harder to find a pre-made engine to use lol. |
Re: HL1 For other platforms?
Quote:
[edit] I just tried an esf map with Nexuiz (a game which uses the darkplaces engine) and it worked :) Well the skybox was missing, but maybe I had to copy another file. |
Re: HL1 For other platforms?
The really big problem which stands in the way of this working is quakec...
Important entities such as multi_manager have custom key/value pairs which get ignored by the engine. I added in something to call a quakec function when an unrecognized key/value pair was found but I could not figure out how to pass in strings to quakec as parameters to the function. Also, a HUGE problem is the half-life mdl format which is extremely undocumented and you can't use valve's code in the sdk due to licensing issues. It was really cool to see a hl map running under the quake engine and even having a healthcharger working but without model support this isn't going anywhere. |
Re: HL1 For other platforms?
Are you using the stock QuakeC compiler? I think there is a better one out there.
|
Re: HL1 For other platforms?
I can't remember which one I used but it was definately a custom one.
That isn't the problem though, inorder to use something like a multi_manager which has upto 16 custom key/value pairs for the target entity and firing delay you need seperate structures/memory for each type of entity. As far as I know all you get in quakec is the entvars_t structure unlike hl where you got pvPrivateData for classes, ect... One idea would be to rip out quakec entirely and put a new native system in place but that makes it really tempting to use the HL system. All the code is there but is unusable to anything but valve products so you'd have to re-create everything including porting over the basic entities from quakec. But model support is the real killer here, everything else is possible to re-create. |
Re: HL1 For other platforms?
The funny thing is, I was planning to convert Quake to use something similar to HL's system. I guess I'll have to do something else now.
Anyway, to figure it out, I would try to look at the lumps and see what looks like this structure, what looks like that structure, and what is it divisible by. Also, check to see if they are valid as floats or not. |
Re: HL1 For other platforms?
Reverse engineering the half-life model format may be too complicated for me :/
Although, I did just reverse engineer the pak file format from q1/q2. I know its opensource but I wanted to see how difficult it would be to reverse an entire file format. It was actually pretty easy and oddly enough, fun. Code:
const int PAK_IDENTITY = ( int ) ( 'K' << 24 ) + ( 'C' << 16 ) + ( 'A' << 8 ) + ( 'P' ); |
All times are GMT +2. The time now is 01:31. |
Powered by vBulletin® Version 3.8.2
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.