FitzQuake Mark V - Easy to compile and ...

Discuss programming topics for the various GPL'd game engine sources.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: FitzQuake Mark V - Easy to compile and ...

Post by revelator »

Guess it had its merits at some point but todays hardware seems to be getting further and further away from compatibility with older extensions.
Still a few problems to iron out in the source, water surfaces sometimes change based on view direction ? yikes, and it runs a little choppy sometimes (bit like pipeline stalling, which it might actually be).
Also need to finish my old work yanking bakers video menu into it :) the code is there but i guess i must have missed something cause the menu only works when running in windowed mode.
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: FitzQuake Mark V - Easy to compile and ...

Post by revelator »

Doh somehow i broke plats, not entirely sure how though but every entity with some kind of movetype is now invisible :S
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: FitzQuake Mark V - Easy to compile and ...

Post by revelator »

Ok i think i got the gist of what happened, seems i have to be very very carefull when rearanging stuff in mh's old engine.
He used a rather smart way of getting the transforms for a lot of things like shadows by reusing the matrix calculations.
But it is extremely fragile when moving certain functions out of the way to make things a little more readable.

Now one thing left, it seems i have a borked blend func somewhere in the water surf code, so now i have lightmapped underwater surfs Oo while interresting it looks like crap with arb shaders lol.
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: FitzQuake Mark V - Easy to compile and ...

Post by revelator »

I started updating an old project of mine, demonquake. So far i have applied every fix found over the years to the code and it runs pretty well.
Its a bit old school originally based on joequake with a few additions by myself like flares and a rather elaborate fog system.

It uses immediate mode opengl atm, but i intend to move things to VBO's and also incorporate MH's normalmapping since it looks great.
The engine is fully nehahra compatible and allready looks pretty nice with that mod :) but theres still some work to do like a customized HD menu tailored towards
that particular mod.

Particle system is an abreviation of QMB's, in time i will add decals to it for some better blood and explosion effects. Ill probably use MH's texture manager for this cause it can load particle and decal images from resource which would be nice as a baseline. Atm the engine uses the old way of having its resources in a seperate dir.

I allready had md2 and md3 model support in the code but i removed it again for the time being (to much hackery needed to support them if i want the same effects to apply everywhere) i might add in the new skeletal model format from remakequake as well as bsp2 (nehahra would probably be a nice candidate for getting an update to those formats).

So what can it do as it is ?.
Flares on light entities.
lit support.
nehahra compatibility.
movie capturing.
neat particles.
lame script support (rather minimal im afraid, but ill look into what can be done with it).
hardcoded texture effects like glass surfaces detail texturing and shiny metal objects (looks ok but the code ... yuck).
arb shaded liquids (beefquake).
luma and fullbrigths.
underwater warp and caustics.
qc controlable world and liquid fog.
qc controlable fullbrights and alpha.

fixed.
dynamic lights on moving brush models.
stair step ups.
surface culling, uses code from MH to get all surfs min/max values to construct a bounding box to cull against.
infinite farclip.
extra efrags.
vector based color shifts.
framerate independant colorshifts.
loads of mistakes pointed out by PVS studio.
Productivity is a state of mind.
frag.machine
Posts: 2126
Joined: Sat Nov 25, 2006 1:49 pm

Re: FitzQuake Mark V - Easy to compile and ...

Post by frag.machine »

revelator wrote:lame script support (rather minimal im afraid, but ill look into what can be done with it).
The only rational thing to do is drop it. In the fire, if possible. :P

Seriously, now: nowadays you'd be better served by any JSON library. There are literally tons of options, just google it.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC :) (LordHavoc)
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: FitzQuake Mark V - Easy to compile and ...

Post by mh »

revelator wrote:infinite farclip.
With protocol 15/666 limits of +/- 4096, you can set farclip to 14189 and it's effectively infinite so far as Quake is concerned.

Please drop that "normal mapping" too; it's deeply embarrasing.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: FitzQuake Mark V - Easy to compile and ...

Post by revelator »

It's not the old crap detail map code, it is real normalmaps :) it just uses player position to calculate the bump vectors instead of light. Are you ashamed of that code ? :shock:

And yeah lamescript will probably go anyway, json could be a nice alternative. Or maybe external ent support, seems mappers like that one.
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: FitzQuake Mark V - Easy to compile and ...

Post by revelator »

The farclip code was from my MH based realm engine which in turn seems to have been based on tenebreas but refined to death.

Allmost forgot the engine also does vertex ligths + pox interpolated version.

From the comments inside the code

These give a properly bumpmapped <insert engine name here>. I've tested by plugging the quake textures and normal maps
generated by this engine into several of the various bumpmapping tutorials out there, and have gotten
the same results as this gives in Quake maps, so I'm happy with it.

<insert engine name here> bumpmapping has nothing to do with lights. Instead, it's using the player coords to generate
the info used for bumpmapping. Rotating the texture matrix for the normalisation cube map was a stroke
of deadly genius - not documented anywhere...

the codebase for the normalmaps is rather large so ill spare you posting it here, but for those interrested baker has a copy for reviewing. The textureloader from this engine also merits another look, i would say it rivals newer implementations in usability. And it does take NULL data without a hickup :).
Productivity is a state of mind.
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: FitzQuake Mark V - Easy to compile and ...

Post by mh »

revelator wrote:It's not the old crap detail map code, it is real normalmaps :) it just uses player position to calculate the bump vectors instead of light. Are you ashamed of that code ? :shock:
Even allowing for the player position thing, the rest of it is completely mathematically incorrect. There's no rescaling from 0..1 to -1..1, and the normals aren't properly transformed for entities.

I guess that if all you want is to see something that looks like it might be normal mapping, then sure; otherwise it's a crock of shit.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: FitzQuake Mark V - Easy to compile and ...

Post by revelator »

i guess so, but dont all quake 1 engines have the problem with incorrect facing normals ? its not like it was built for anything like doom3 style drawing anyway :).

On the point of incorrect code

anyone noticed this ->

avelocities[0] = ( rand() & 255 ) * 0.01;

check the proto for avelocities :)

vec3_t avelocities[NUMVERTEXNORMALS];

that means avelocities[3][NUMVERTEXNORMALS];

but its calculated as avelocities[NUMVERTEXNORMALS][3];
in pretty much every engine out there, running clang on the code pointed that one out nicely.
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: FitzQuake Mark V - Easy to compile and ...

Post by revelator »

For baker or anyone else interrested in how This engine looks when running ->
https://sourceforge.net/projects/cbadva ... p/download

The pak3.pak in id1 is not nessesary but it does add a little more umph ;) Realm or MHQuake9 as it was based on does not need any external data at all,
even the HD particles are loaded from internal ressources.

It can load pk3 so if you like to keep the content from pak3.pak you could repack it as pak0.pk3 to get it out of the way (addition from me).
The engine also does GLSL shaded heathaze and is capable of doing GLSL water also, but it requires a rather hefty rewrite of the code for drawing water surfs which uses a dual layer approach to emulate real shaders by doing seperate blend and warp matrix calculations over two TMU's. Besides it looks kinda nice :)

Sprites have HD replacments loaded from the particle system like bubbles and light globes.
Besides that the particle system is rather true to its origin, looks better though.

Also there are no none zip zilch md2 md3 or whatever model support but we do support lumas and fullbrights :)
A note on the above lumas work, but it is pretty picky with correctly alpha masked textures, the current HD skins from the quake ressurection site dont seem to fly well with Realm as monsters go all black instead of fullbright. The normal monster skins from these are included though and look great.

It also supports mod playing (it was my plan at some point to make it run nehahra) but after several bouts of sickness i kinda lost track and then i started dabbling in C++ and forgot about most of the C quirks :lol: Instead of Fmod it uses the now open source midas library (good luck compiling it yourself though, it took me several months to coerce the build system to accept mingw, and much has changed since then so it no longer compiles with later versions, sigh).

Engine also has bloom on surfs, it can quickly become to much if you boost bloom alpha so be carefull.
Overbrights are also supported with gl_doublelight 1 or 2. 1 looks nice 2 might be a bit to much for most though, 0 is standard and many will probably prefer that.

The rest of the nifties are hard to miss :) you might choke a bit on the menu screen hehe.
Productivity is a state of mind.
Post Reply