InsideQC Forums

Hi, Spike and I have been playing with a new .lit2 format for Q1 for high-res lightmaps, with different lightmap scale per-face.

Here is the struct:

typedef struct
{
char magic[4]; //"QLIT"
unsigned int version; //2
unsigned int numsurfs; //should be checked against the bsps' surface count ...

Recently I was working on my tyrutils fork, latest build is here: http://www.celephais.net/board/view_thread.php?id=60967&start=334

Some of the new stuff:
- surface lights. Not using a new lighting formula like the q3 tools, but it just takes a template light entity and copies it across surfaces ...

Good thread..

Not quite on topic but I uploaded a test map I used when modifying the QuakeSpasm renderer, to check for regressions from Fitz 0.85.
http://quaketastic.com/files/misc/rendering-testmap2.zip
Requires quoth (mapobject_custom to load an external .bsp).

It's nothing special, but tests ...

I have two laptops with NVidia (9400m, 650GT) I can offer for testing if you need it.

With the Dec 24 OSX build, sky looks fine, but if I set r_oldwater to 0, liquids are rendered solid white. Not sure if that is related or a different issue.

Whenever you hit an opening paren, push something on to a stack that says "opening paren at character X".
When you hit a closing paren, you know it's closing the top paren on the stack, so pop that off.

Mathematically on paper, the blending of 2 gamma corrected textures should yield the same texture as 2 non-gamma corrected textures which then have the gamma applied because the mixing is of the color components (R, G, B) which have individual gamma correction. On a computer it will be slightly ...

Hm, maybe you're right, Baker. At least, it could be better to go that route for an engine like Quakespasm which has no fancy visual effects.

I just would just want to make some comparison images with transparent water, fog, etc., to see the difference between doing gamma on the finished frame vs ...

Ah :) Yup, the framerate hit from impulse 255 at that resolution is about 40% (770->440fps).

Anyhow, I'm pretty happy with this gamma implementation. From what I've seen I doubt it will ever get in the way of hitting 60fps (or even 120fps) on Quake maps. Running id1 content at very high resolutions ...

Yeah sorry partly my fault, I probably should start a new thread for the (quake 1) light stuff I was working on.
The latest build for now is in this post: http://www.celephais.net/board/view_thread.php?id=60967&start=287

The new stuff it has is ambient occlusion (aka dirtmapping), a sun dome ...

Booting into Windows, I tried dipping under water in e1m1 with RMQEngine and DirectQ, and both of those also show a ~50% fps drop when the render-to-texture screen warp kicks in. But again, 2880x1800 resolution, and the drop was ~700 to ~300fps. This is a laptop, too, and the gfx card isn't that ...

I didn't realize it was that much of a perf hit, at least on id1 maps, but in e1m1 I go from 770fps with gamma 1 to 290fps with gamma != 1.
I tried that at 2880x1800 to maximize the performance hit, w/ geforce 650gt 1024mb, OS X.

On the other hand if I try one of the heaviest quake maps I know of ...

Yeah the
dest->foo = src->foo;
VectorCopy(src->pos, dest->pos);
thing is awful. Using "const" liberally could detect mixing up the order of VectorCopy, but usually in Quake both source and dest are mutable.

IMO the 0=success, 1=failure, or -1=less, 0=same, 1=greater stuff is horrible legacy style ...

I agree, Baker, I've wasted a lot of time setting up dev environments. It's just time burnt away before you can actually start doing anything productive.
(Btw, thanks for the reminder about Quakespasm's VS/Xcode projects not working on fresh installs, will put that on my todo list. IIRC they require ...

Baker, that's a cool idea.
As long as you make sure to gamma-correct everything (lightmaps, textures, view-blend colors,..) it should work well.
For cases where there's alpha blending - water, glass, pain flashes - you won't get exactly the same result as doing it on the finished image, right? (0.5 ...

Thanks spike, will look into cleaning those things up.

I went for npot just because I don't have any >=GL2.0 hardware without npot, but I guess it would be easy to use a power-of-two texture (the code in RMQEngine that I based this on did use a power-of-two texture for the framebuffer copy.)

GL ...