InsideQC Forums

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.

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.

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.

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?

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.

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.

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..

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?

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.

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.

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?

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

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.

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

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.