Old school quake, well not quite but

[revelator]

Hmm food for thought, thanks spike ill see what i can do to get to the bottom of this.

[revelator]

Ok that helped a bit, i created a guard against recursion in SCR_UpdateScreen still a little stalling but much better now.

Also ran into a bug that im not sure is code related but i might be wrong, e4m1 underwater leafs seem to collapse causing underwater fog to fail, same happens in the end map before shubby. Are there any problems with wrong worldtypes in those maps ? i remember claustrophobolis had some problems with this. Fog works fine in all other maps.

[revelator]

Damn its also code related cheked with another engine and it does not exhibit this behaviour, guess ill be busy for the time being fixing this.

Mh's comment also had me look at the tenebrae glare code, so i applied the same bloom code i use in realm for a test but it does nothing ?, seems tenebrae uses
code that is not compatible with this method of applying bloom. Last version used a post processing shader but it was buggy as hell so i removed it for the time being untill i find out why. Atleast i fixed tenebrae old problem with breaking shadow voulmes if depthrange was enabled, i posted this fix in the engine coding section for those interrested. No more problem with the model poking through walls yay .

[revelator]

Gaaaah i just noticed realm does not check backfacing surfs, guess i forgot to implement the code when i ported this codebit from tochris sigh.

That might actually explain the weird behaiviour with leaf planes collapsing, going to check that fingers crossed.

Finally managed to get fragment shaders to work with the dual layered water, the overlay looks pretty good though its a far bit away from the original.
It does smooth out the edgies

Still stalls a bit not sure what to check next urgh.

[revelator]

Sigh ok it was the lava heat haze code causing the rest of the stalling, it uses a nasty pvs hack to prevent smoke from poking through walls even if its occluded.
Unfortunatly it also causes some jerkiness when the pvs changes because it does this every frame. Im looking for a way to fix this properly.

[toneddu2000]

wow, I admire your dedication and skills!

[revelator]

now plays nehahra maps, still TODO: demo movie support and fixing menues.

[revelator]

[revelator]

[Spike]

... every frame? yeah, that's going to be a huge performance loss, definitely.

[revelator]

Yep and further i found out that the reason i newer made a cvar to control this behaviour is because realm needs normalmaps to function correctly, i just tried and every
texture that was missing a normalmap turned up with weird colors untill i reenabled it. Seems that i need to make some fallback method in case they are missing.

[Spike]

defaultnormalmap = CreateTexture(TEXTURE_RGBA, 1, 1, "\x80\x80\xff\xff");
then they can all use the same image...

[revelator]

Ah your a lifesaver thanks m8

[revelator]

Also spent a lot of time removing most of the hackiness from nehahra and using an opensource mod player instead of fmod,
still not quite there yet but its getting better by the day. Currently im missing the demo movie code and im running headlong into a rather obscure host error pointing me to svc_staticentities rather fun since both the server and client code was allmost a 1/1 copy of nehquakebjp minus a few things like qc controlled skyboxes which realm does not yet support, they are parsed non the less but newer forwarded, i took this code from bjp's enhanced glquake which can also load nehahra maps and does not suffer this bug, so its probably some obscure fuckup on my side.

This is turning into a full time job and i cannot do this kind of work anymore because of health issues,
so i'd better force myself to focus on other things (yeah like that's going to happen, but it must, even though i hate it) .
So as they say it will be done when its done, but i hope the wait will be worth it.

[Spike]

you can greyscale (or whatever) the original 8bit image and treat it as a heightmap and generate a normalmap from that, which is what tenebrae did.
while FTE can do that, it doesn't do so by default because imho its ugly. I think DP is the same.
instead a normalmap with x=0,y=0,z=1 is perfectly sufficient. note that if your lighting directions are in worldspace then you'll need some sort of matrix to rotate the lighting directions into surface space (if you have an rtlight you can just do this on the cpu as you submit the texture coords for each vertex), and they also need to be normalised instead of saturating (cubemaps are handy for this if you're stuck with fixed function hardware). if you're doing deluxmapping (mapname.lux files) then both textures should already encode both vectors in surface space so you can just do a simple dotproduct and scale the per-pixel lighting by the result of that. Do note that you'll end up with darker lighting everywhere that the two vectors don't exactly match - you might want some bias or bounds or ambient lighting or something.

but yeah, if you want some placeholder normalmap, fill it with that pastely blue colour, and it'll effectively be perfectly flat.

and yes, removing hacks takes much longer than originally implementing them did... don't worry about removing them all at once because you'll never get it working again afterwards.

I assume you mean svc_spawnstatic... with the bjp1-3 protocols, the modelindex value is always a short. the vanilla protocol (including nehahra's demos) uses bytes.
if you can play a demo recorded by another engine using that protocol, then the problem is probably in your server (you can also run your server with -dedicated and see if the other client can connect okay as a demonstration that a server-protocol bug doesn't discriminate).