http://quakeone.com/qrack/ 

if you compare jq0.13dev to any qrack you'll see what's diff, that was the base i started on; and the first file I focused on was gl_rpart.c ;) 

1) MH's revised sky draw is a pretty decent speed boost for the scrolling sky.

2) I needed to know whether or not MH was right about color 255 not supposed to be fullbright.

Original WinQuake color 255

In the above screenshot, notice I took care to stand next to a wall with lighting.

The brownish color on the walls is color 255, which is surrounded by fullbright white (color 254) and the black area is non-fullbright red (color 79).

Color 255 isn't generally a very useful color. It is rarely used.

But in WinQuake it is acting as a fullbright color. 

I haven't checked but I have a good degree of confidence that the colormap has it as a column of 255. So from the perspective of the colormap it is fullbright and I'm probably wrong.

Where things get tricky is how you interpret index 255 because '{' textures should be able to have fullbrights on them too, and 255 cannot be both fullbright and alpha in a '{' texture.

It's also the case that in all of ID1 no BSP texture uses index 255 (I checked).

There's also this in the colormap generation code in qlumpy (https://github.com/id-Software/Quake-Tools/blob/master/qutils/QLUMPY/QUAKEGRB.C#L233):

note: 254 instead of 255 because 255 is the transparent color, and we don't want anything remapping to that

So I can say with a good degree of confidence that even though 255 is represented as fullbright in the colormap, it is not intended to be actually used for anything other than transparent. 

Where things get tricky is how you interpret index 255 because '{' textures should be able to have fullbrights on them too, and 255 cannot be both fullbright and alpha in a '{' texture.

I think it has to be transparent, otherwise fence textures would cease to exist as a feature. Since it's transparent, it should not be added to the fullbright mask. And alphaedgefix should be used to fill it in with neighboring colors.

On non-fence textures, it should be fullbright since that is how it works in all versions of the game (software and accelerated) that support fullbrights. 

@mh - It disturbed me that such a behavior difference occured.

I wanted to know exactly why Windows + D caused a problem. Here is the reason.

Dumping system messages:

WM_WINDOWPOSCHANGING wparam: 0 lparam 18fab0
WM_GETMINMAXINFO wparam: 0 lparam 18f7b0
WM_NCCALCSIZE wparam: 1 lparam 18fa88
---------
(Windows + D show desktop, Quake will run a frame here because the message queue is empty -- we have not received a WM_SIZE message yet so we don't know we are minimized.)
---------
WM_NCPAINT wparam: 1 lparam 0
WM_GETTEXT wparam: 1fe lparam 18e580
WM_ERASEBKGND wparam: 5011197 lparam 0
WM_WINDOWPOSCHANGED wparam: 0 lparam 18f890
WM_MOVE wparam: 0 lparam 99016b
WM_SIZE wparam: 0 lparam 1e00280

(Minimized runs frame here, we received WM_SIZE already so we are ok!) 

Beta Build 1031

1- Correct alpha masked texture support in DX9

2- MH faster scrolling sky rendering (DX9, DX8 and Open GL)

2- Resolves a DX9 + "Windows key + D (show desktop)" issue.

Should have one more build later. 

Just been doing some testing comparing texture gamma ("txgamma") to shader gamma (which will have the same result, if not the same perf, as full-screen desktop gamma, which I didn't test).

Visually they're not identical. This should have been obvious, but wasn't, at least to me.

With texture gamma the calculation is pow (texture, gamma) * lightmap

With shader gamma the calculation is pow (texture * lightmap, gamma)

Shader gamma feels more "right" because it applies gamma as a post-process after the entire scene is composited.

You can't deny the performance of texture gamma, and it does give a richer look which can be more visually appealing.

To make texture gamma give the same result as shader gamma, you should also gamma-adjust the lightmaps. pow (texture, gamma) * pow (lightmap, gamma) because exponents are distributive over multiplication. 

Thanks for the calculation comparison analysis.

Yeah, texture gamma and shader gamma have differences. You'll notice Gunter perspective that the polyblends look better with texture gamma. Meanwhile, I wonder about transparent brushes/models which is a "double application" scenario with texture gamma.

Ironically, with texture gamma, I had to modify the FitzQuake texture manager to be aware of textures intended for blending and exclude them from texture gamma (example: the optional QMB particles are blended) to avoid "double application" (although I doubt the final color is technically "gamma-correct" according to the calc). 

I'm not all that caught up in this topic.

I think frames per second is important, but I also think fps above 72 in single player is a bit superfluous. Because Quake physics acts up around 250 or 300 fps (killer lifts, missed triggers on maps like E3M2. 144 fps ... which matters because some monitors, hopefully isn't too bad.

Anyway, like I said, I'm not caught up in this ...

Here is Mark V DX9 and Quakespasm (Mark V Open GL would lose substantially). Quakespasm is set to gamma 1 and contrast 1 to keep shader gamma out of the equation.

But we'll have mirrors on in DX9 just too give DX9 some extra work to do ...

http://quakeone.com/markv/media/dx9_and_quakespasm.jpg

For fun, here is Mark V DX9 and FTE. DX9 Mark V is using external textures.

Spike's FTE is probably the fps champion of all Open GL engines.

http://quakeone.com/markv/media/dx9_and_fte.jpg

MH's DirectQ? Yeah, DirectQ smokes all of the above in a curb stomp which not even close.

http://quakeone.com/markv/media/directq.jpg

My Win 7 laptop has rather modest specs, anyone with an actual "good" graphics card is going to see way higher fps than above.

Anyway, anything above 72 or arguably 144 fps in single player Quake isn't too useful anyway. 

Has anyone ever tried to disconnect the rendering from game logic in Quake? I feel like that'd be a nice thing to have, then we'd be able to run at any FPS we liked and avoid the bugs mentioned above.

I also feel like it would be a giant pain in the ass to figure out and actually implement... 

DarkPlaces has it.

DirectQ had it with a tiny inconsistency that someone picky like me or Gunter would notice, otherwise I almost acquired it from DirectQ and inside Mark V is a partial implementation of retaining some of the improvements from the attempt (more consistent clock timers).

All modern Quakeworld engines have it.

FTE has it on steroids.

At some point will happen in Mark V. 

I know that unborked physics at higher fps in on the wishlist for a bunch of speedrunners. 

Mark V 1032 Beta - Windows, Linux, DX9, DX8, Open GL, WinQuake

Source Code

Features Vs. Mark V 1.2

- Very fast "triple the fps" DirectX 9 build courtesy of MH
- WinQuake looking water warp in Open GL/DX9 (MH again)
- Volumetric shadows - r_shadows 3 (MH again)
- Sky speed up in Open GL/DX8/DX9 (Yeah, MH)

- Linux Open GL build (thanks to JimBob for testing, Spike for debug tips)
- Linux WinQuake build

- Resize on-the-fly windowed mode in all builds (except DX8). Yes, even Linux. Tried to make the Linux build fancy. May have succeeded.

- QMB enforcer lasers available video

- Improved performance on NVidia cards
- 2 Extra options in video menu for convenience.

- Other things, no doubt. But what were they? Scroll back in the thread ;-)

Hopefully resolved the remaining significant issues, like dwere's context creation failure message. Attempted to add texture gamma to DX9 and then ended up with a blank screen and plenty of wasted time, killing the opportunity to add true rotation and even get the Mac build running. :(

Engine coding sucks like that sometimes, but I won't pretend to not be irritated about missing a few items I very much wanted to get done.

/All feedback and any issues reported do get read.

Next update is likely in the spring. 

In DX9 only, models with fullbright pixels still can't handle transparency (like an illusionary player model, or the gun view models except axe). gl_fullbrights 0 makes them transparent again.


Hm, there is still a big difference in the water warp effect in the Winquake version as compared to DX & GL. The Windows one just doesn't warp as much, and is less noticeable. 

Software Quake waterwarp is resolution-dependent. Run it at 320x200 and you'll see a very different effect to if you run it at higher res.

The waterwarp code I wrote is resolution-independent.

IMO the software Quake behaviour is undesirable.

More discussion, test cases, etc here: http://forums.insideqc.com/viewtopic.php?f=3&t=5827

You'll notice that my warp code reverses the X-axis direction but is otherwise good. That's something I intend to fix some day (the X-axis bit, not the otherwise good bit). 

Ah, I see. I agree about the undesirable part. 

Binaries still work on KDE without need for re-compilation.

The laser effect is neato -- kinda like they're being squeezed out of the gun. Would make for a decent "shooting star" effect. Might be nice if they could be toggled off for the player (like the FVF Laser Android class), while still being enabled for the enforcer. But not a big deal *shrug*

Winquake crashes (seg. fault) when I try to drag-expand the window too much. Appears it may be trying to snap to fullscreen (like a snap-to-edge behavior). That doesn't bother me, though, cos I likely won't be using Winquake, and that's an easy situation to avoid anyhow. Otherwise runs fine.

Anyhow, please ignore that until the spring. And thanks again for bringing Mark V to Linux. I will enjoy playing Quake with it in the meantime :) 

I had the same reaction as Gunter that the GL waterwarp effect has a surprisingly strong distortion. I guess I was used to running WinQuake at a non-minimum resolution back in the day.

It's not a big deal, but out of curiosity: how feasible is it to expose "warp amount" as a console variable? 

how feasible is it to expose "warp amount" as a console variable?

There are a few hard-coded numbers in it and I even have a comment on one of them: "tune it or cvarize it all you wish".

I'm actually working over this code at present fixing up a few issues with it, but I don't feel that I'll be the one adding cvars: it's really up to Baker, how or even if he wishes to expose this. 

Hm, yeah, the FvF Laser Android uses the same laser-firing function as enforcers do, but apples various flashing colored skins to the laser projectile.

The QMB effect now has every Android laser shot look just like the enforcer's laser.

And it really hits my FPS when firing the Super Spread Laser (8 simultaneous laser shots, heh).

It's too bad the effect color can't be made to match the laser skin color....
I suppose a quick hack (which I'm not at all sure how it would end up looking, since the Laser Android does use the standard laser color too) might be to only apply the QMB effect if the laser projectile is using its default skin 0.

Or I suppose have the effect only apply if launched by an enforcer, as JimBob suggested.

Though I always thought the laser android could use some kind of QMB-type effects too (when such things are enabled).... 

OK, I'm pretty much done working over the code. It's a shame I didn't get this in time for Baker's release, so you're just going to have to be patient until his time frees up again.

Picked up the latest vkQuake code adjusting the water warp for screen aspect. Yes, my water warp code was based off vkQuake.

Made it as close to consistent as I can get with Mankrip's tests at http://forums.insideqc.com/viewtopic.php?f=3&t=5827

Mankrip has criticised the vkQuake code before, but I think he's being unfair. vkQuake is actually 99% there; the only things it needs are a sign-flip ("(x - (sin (y" instead of "(x + (sin (y", likewise for y/x) and a tweak to the value of AMP (2/300 instead of 1/300).

This is not based on any rigorous code analysis, just tweaking values until it looks right, but it's close enough for me.

Mankrip's: http://www.quaketastic.com/files/misc/testing/waterwarptest_Retroquad_1280x960.png

Mine: http://www.quaketastic.com/files/misc/testing/waterwarptest_DirectFitz_1280x960.jpg

There's a bug where if you change resolution when underwater, water textures get turned to binary garbage. Don't bother reporting it - I'm aware of it. 

Oh my.... The Ninja also uses the laser model (skinned) for his throwing darts, heh... and now they look like laser effects in QMB. 

for some reason waterwarp in both opengl and directx seems to be down-ressed? is that correct? 

Yes, I downscaled it.

This is essentially the same kind of problem and same kind of tradeoff as we have with shader gamma. Because it needs to run as a post-process it's slower, so I downscaled it to compensate.

It's a no-win situation because if I didn't downscale it people would complain that it was slow.

My expectation is that cvars could be provided to tune the size, so that you could select downscaling or not, based on your own preferred tradeoffs (and hardware capabilities). But that's not my decision.