help completing an engine

[revelator]

Hey peeps.

Im fixing up some lose ends on my realm engine but need some help on a few features, so if anyone is interrested in helping fixing the code the credit is all theirs

things to do.

Bumpmapping on alias models (works fine on surfs) pointers on how to do it was in mh's Q2 engine but it turned out a mess when i tried to adapt it so if someone could pitch in with a hand on this part id be happy.
Menu system. My plan is removing it completely and replacing it with a csqc based one. Hud models are ok allthough it should be replaced by a later model from mh.
Bloom renderer. mh's version preferable to the one im using currently. My version works but its a bit to colorfull hehe.
Code for loading skyboxes. Completely missing atm, the plan is using something ala tenebraes version with tile textures for scrolling clouds.

other parts that could use a workover.
vertex arrays on some parts of the engine uses a non native adaption from early phoenix quake, while they do work fine id prefer not to have a load of seperate arrays.

The wm in realm is based on bengt jardrups work and as such suffers from the same bugs his engine has.
Most notabley some mods behaving weird or not loading at all. I used it because it handles extreme mods better but it does have some drawbacks.
I fixed some of incompatibilities but some still remain.

write here or PM me if you want to lend me a hand.

Best wishes reckless.

[Spike]

bumpmapping of any kind requires a light direction. good luck getting it to match.

csqc is not a good choice for engine-based menus. mods provide their own csprogs.dat which means no more menus. also, csqc is not running when a map isn't loaded (unless you want to do some halflifeesque a-map-is-always-loaded thing).
of course, your implementation is your implementation.

bloom... can't help you with that. the stuff in fte is shite.

skyboxes. use a cubemap. its easy enough (the awkward part is getting your texture loader to load the images into cubemap sides instead of regular 2d textures). also check to ensure the seamless cubemap extension is active... With a cubemap or two you can just use a texture matrix and rotate it to rotate the clouds. then there's no per-vertex maths and you can push your sky polies through with one glDrawFoo call (ignoring state changes). or use a cubemap with glsl - you probably want to use glsl to stop the annoying sky warps in glquake anyway, which would make skyboxes merely trivially different from regular skies.

vertex arrays are deprecated. Use VBOs, and glsl when you need to animate them (like water).

why does your engine need a window manager?
I'd pimp fte's qclib, but I'm too lazy to support it properly. but on the plus side it does give a nice 'compile' console command.

[revelator]

realms bumpmapping is not standard its a special version made by mh based on an idea by me it does not use light direction but player direction on the plus side its way way way faster than normal dot3 bumpmapping.
ok was not aware of that restriction in csqc for menu use ill see if anything else can be cooked up (xml menues ?).
cubemaps for skyboxes sounds ok ill look into it.
vBO hmm i might but my engine is allready among the faster ones so im not sure how much i would gain.
glsl was dumped early as the modifications nessesary would be to much and the system i use currently emulate shaders quite ok but maybe in time (its definatly something i want to look into).
oups wm should have been vm

the bloom code i use is allmost the same fte uses heh.
Mh's only apply bloom to textures with luminance.
qclib might be of interrest

[revelator]

[Spike]

yeah, if you use a deluxemap instead of that cubemap, you can get bumpmapping which does respond to light directions. The issue comes between separate lights, as it flattens out. But you can get some decent enough bumps that way, you just have to ensure that the normals are not full unit length to retain the same lighting intensity across the surface. Then you get per-pixel lighting without the expensive multiple passes.

VBO is great for situations where you have a lot of vertex data, or slow pci busses or whatever, but otherwise its mostly a pain. If you're implementing VAs, you should consider going the whole hog and using VBOs instead. They're mostly the same really, but VAs are not part of gl3's core profiles. If you're generating data on the cpu each frame, then vbos probably won't be a gain, which is something to get annoyed at... Otherwise they're the fastest way to get data to the gpu, and the only way in d3d.

GLSL is awesome. nuff said. If it means less texture lookups then you've gained from it. various things become less hacky. entity vertex lighting stops being so inefficient, etc.
mh is a fan of the earlier arb programs, if only because of intel being utterly useless.
glsl isn't all that complex, other than to learn exactly what fixed-function stuff becomes unnessecary.

[mh]

[Spike]

yeah, I had fun with GLSL+ATI vertex attributes. attribute 0 is stated to be gl_Position. Enabling and disabling it also enables and disables GL_VERTEX_ARRAY or whatever it is on ati, but not on nvidia. If you go fully into glsl then its not a problem, but you do need to enable that bit of fixed-function state if you stop using glsl. You also have to be careful with nvidia and float foo = 0; type statements, because glsl isn't meant to allow you to do implicit type conversions between floats and ints but nvidia allow you anyway. Nvidia have cleaned up their act and behave much more strictly if you explicitly state #version 110 right at the start (if you do so, make sure its above any #defines because certain implementations are strict about that too), and doing so can reduce compatibility issues because everyone does agree on what version 110 is meant to mean, even if they do allow ambiguous things like defines before stating the version (which is actually not meant to be allowed).
The worst glsl implementation is mesa(linux+intel hardware), because they abort() on my shaders, and I can't even reproduce that on my machine. Damn you mesa/intel!
Anyway... cubemaps for skyboxes, even if you don't use glsl.

[revelator]

cubemapping it is then

The deluxemapping idea is interresting ill see what i can dig up about it.
Atm only implementation i seen was in tenebrae2 but i suspect darkplaces to have it also.

Also amen to the way vendors treat the glsl spec is fubar, i hope they settle on some standard soon.
vBO's are still on the backburner for now atleast untill i get something im happy with but after that all bets are off hehe.

[mh]

Go cubemapping!

One of the big problems I had with attrib arrays was that I'd found a driver that Just Did Not Like writing from vertex.attrib[anything] to result.texcoord[anything other than 0]. As it was an older driver the possibility of it ever being fixed was pretty damn low.

Beware of (ab)using the color registers; they can be interpolated at much lower precision on some hardware, so unless you're certain that this lower precision is OK you risk huge loss in fidelity.

It's a shame that GL_ARB_vertex_blend never got wide uptake, and never made it into core. You could do a static VBO plus interpolation setup for MDLs with that and not need shaders at all. The hardware is definitely capable and the D3D version of it (D3DRS_VERTEXBLEND) is widely available.

One of the really really nice things about shooting for more modern graphics hardware (say, SM3+) is that a lot of old crap that you needed to worry about just goes away.

[revelator]

[mh]

[revelator]

[mh]

[revelator]

all drivers unfortunatly though some have been better than others :/ only way i could get it stable was dropping the factory overclock back to standard gtx 285 values and even then it did occasionally crash the whole system but atleast not every two minutes.
the strange thing was that i could murder the card with furmark (on highest) for days and it didnt crash once untill i loaded a game. The cards been living in two machines now and the stability didnt improve with different hardware
so my best guess is that the card had some sort of fault. To bad this experience only cost me about 10 grand in hardware and thats in dollars

doesnt matter the card was pretty hefty for its days but the 560 blows it totally out of the water (allmost 50% faster) and i get dx11 support so im happy.

[revelator]

an intel outperforming an ati preposterous! hehe no i heard something similar but i guess intel has made to much of a bad name for itself with there previous gfx chips so it stuck