Basic Half-Life Map Support For Stock GLQuake

Spike · Post by **Spike** » Sat Dec 05, 2009 4:52 pm

in baker's stuff, I don't see the divide-by-3 for the lightmap offsets.
Also, that 'beam' brush in baker's screeny seems to have the same lined effects, as well on the walls.

Ah, right... step #13 is wrong. It greyscales it, but leaves it as 3-componant. Which is wrong.
What you should do is divide the surface lightmap offsets by 3, and average the 3 rgb lightmap values and scale them down.

so:
loadmodel->lightdata = loadmodel->lightdata[i+1] = loadmodel->lightdata[i+2] = out;
becomes:
loadmodel->lightdata[i/3] = out;

but yeah, you need to divide the msurface_t lightofs field by 3 too, but only for halflife maps.

ceriux · Post by **ceriux** » Sat Dec 05, 2009 8:26 pm

spike doing this has actually made the lighting worse. there is a tutorial for some kind of a shadow fix or better shadows or something. if i implement that do you think it would fix the issue im having? because that last fix made it worse as you can see below.

Team Xlink · Post by **Team Xlink** » Sat Dec 05, 2009 9:03 pm

ceriux wrote:spike doing this has actually made the lighting worse. there is a tutorial for some kind of a shadow fix or better shadows or something. if i implement that do you think it would fix the issue im having? because that last fix made it worse as you can see below.

That fixed worked great for me.

Thank you Spike.

Also, I don't think this is the only implementation needed to use worldcrafts half life waypoints for bots, it would require customized bots.

It would make scripted events much easier if you applied it to monsters.

ceriux · Post by **ceriux** » Sat Dec 05, 2009 9:51 pm

well... do you think its the compiler im using then?

also iv chose to include the textures into the bsp could that also be causing my issue?

Spike · Post by **Spike** » Sat Dec 05, 2009 10:47 pm

ceriux, you need to make two changes, not just one. if you didn't make the second change then it will appear worse. and yes, I was a little vauge perhaps that it was actually two seperate changes, and not an explaination for a single change.

ceriux · Post by **ceriux** » Sat Dec 05, 2009 11:36 pm

but they're both in the same function right? i changed both of those that were similar to each other. the effect was more or less the same.

what if i tried to implement colored lighting? im just wondering if its just how the lighting is kind of a hack? im not sure. if you guys want ill post up that section of the function.

Downsider · Post by **Downsider** » Fri Dec 11, 2009 11:44 pm

I was implementing this, and I noticed WAD3_LoadTextureWadFile is never used. I managed to load up each WAD file manually by just chucking a WAD3_LoadTextureWadFile("halfelife.wad"); somewhere in host.c, but that's obviously not the desired method..

Team Xlink · Post by **Team Xlink** » Sat Dec 12, 2009 12:27 am

Downsider wrote:I was implementing this, and I noticed WAD3_LoadTextureWadFile is never used. I managed to load up each WAD file manually by just chucking a WAD3_LoadTextureWadFile("halfelife.wad"); somewhere in host.c, but that's obviously not the desired method..

I also ran into that problem.

Also, Ceriux, are the halflife maps your testing with the stock half life maps or are they custom maps?

Baker · Post by **Baker** » Sat Dec 12, 2009 1:23 am

Downsider wrote:I was implementing this, and I noticed WAD3_LoadTextureWadFile is never used. I managed to load up each WAD file manually by just chucking a WAD3_LoadTextureWadFile("halfelife.wad"); somewhere in host.c, but that's obviously not the desired method..

If you guys are making your own maps, please compile the WAD into the map itself. Then you don't need external wads.

Example: http://quakeone.com/proquake/src_other/halflife.bsp

^^ That map has the WAD compiled into it.

Unless you have a well-defined texture set that is going to be used across a series of maps, when you compile the Half-Life map the WAD should be compiled into it, IMHO.

ceriux · Post by **ceriux** » Sat Dec 12, 2009 1:28 am

its a custom map, with the textures compiled into it. the pictures are up above. would you guys like a link to the map to see if you get the same issues?

edit: nvm downsider helped me fix my problem.

Downsider · Post by **Downsider** » Sun Dec 13, 2009 4:36 am

I got Half-Life maps working fine, but there's a problem. I've got an extremely RAM budget, and it would be better if I could render each texture as a paletted image. I'm not too familiar with how this can be done?

I don't need somebody to hold my hand, just throw a few pointers as far as storing the palette and calling it back later.

Also, would switching the palette for each texture cause rather major slowdowns?

ceriux · Post by **ceriux** » Sun Dec 13, 2009 4:54 am

Downsider im pretty sure thats what the hlbsp format already does. each texture stores its own 256 pallet.

Downsider · Post by **Downsider** » Sun Dec 13, 2009 5:15 am

ceriux wrote:Downsider im pretty sure thats what the hlbsp format already does. each texture stores its own 256 pallet.

Baker's implementation upsamples them to 32-bit for the sake of a simpler method, but for my purposes, it uses too much RAM.

ceriux · Post by **ceriux** » Sun Dec 13, 2009 5:38 am

i probably dont know what im talking about , but have you tried making them sample down ?

Downsider · Post by **Downsider** » Sun Dec 13, 2009 5:49 am

ceriux wrote:i probably dont know what im talking about , but have you tried making them sample down ?

The main problem is that I have to store the palette somewhere and I'm not sure how exactly I should go about doing that, and when it needs to be loaded, but most importantly, when to revert to the original Quake palette.