Tuesday, March 1, 2011

DirectQ Update - 1st March 2011 (Part 2)

Keyboard autorepeat broke as a result of some new input code (and me trying to be too clever for my own good); this is now fixed.

I've removed the renderer decoupling as there were some glitches and edge cases I'd failed to catch. No big deal; I've lost nothing by trying it and it was definitely worth trying to see how it would behave. Guess that I'm almost there with it, but not close enough that I can see the whites of it's eyes yet. It's worth another round later on, but right now I'm not going to let it hold things up.

Some shader optimizations should see some more performance improvements coming through. I forgot to mention that Beta 3 got about 25% extra (depending on hardware/etc) in heavy scenes, which was nice. I might be able to pull a few more percentage points from it.

I think the next one out is going to be a Release Candidate, and will happen towards the end of the week.

9 comments:

David A. said...

Beta 3 fixed my stuttering problems, so I guess it was a threading issue.

The only other nags I have are also in 1.8.6:
- r_wateralpha is not saved
- gl_texturemode is not saved
- There's no way to disable colored lighting as far as I can tell

MichealS said...

I was playing with the water alpha in 1.8.666a, and tried setting different levels for lava and slime, but they seemed to be locked to whatever r_wateralpha was set at. Did I miss a setting or are lavaalpha and slimealpha unused?

=peg= said...

@David: r_coloredlight 0

@MichealS: r_lockalpha 0

@MH: what spike said + wiki + this + me having a core i7 makes me think that maybe the mouselag/shakiness problems I describerd earlier have something to do with it..

mhquake said...

"me having a core i7 makes me think that maybe the mouselag/shakiness problems I describerd earlier have something to do with it.."

Nah, I've got an i7.

mhquake said...

"Beta 3 fixed my stuttering problems, so I guess it was a threading issue."

Nice. :)

"- r_wateralpha is not saved
- gl_texturemode is not saved
"

Neither of these are saved in GLQuake. I can see a case to be made for saving gl_texturemode, but the problem with r_wateralpha is that not every map supports translucent water, so you might switch from one that does to one that doesn't, and screw things up.

"- There's no way to disable colored lighting as far as I can tell"

r_coloredlight 0 just disables colored dynamic lights, for map lighting you'd need to not have a LIT file.

Ron said...
This post has been removed by the author.
Ron said...

Neither of these are saved in GLQuake.

Any chance you could introduce a Q3-esque seta command for this purpose?

=peg= said...

Below is a little script that you can copy to your autoexec.cfg

It supplies a button you can use in-game to switch between fully opaque water, translucent water for maps that support it, and translucent water for maps that do not support it (at the cost of lower performance)

The idea is that you can toggle the setting on-the-fly, depending on the map.

Replace "somekey" with the key you want to use to cycle between the various options..
Replace the values for r_wateralpha with the value of your preference.

Copy/Paste the bit below the line
Mind you, after pasting, it should be just 5 lines of 'code'.

---------------------------------
alias cycle_water water1
alias water1 "alias cycle_water water2;r_novis 0;r_wateralpha 1.0;echo opaque water"
alias water2 "alias cycle_water water3;r_novis 0;r_wateralpha 0.3;echo trans water - vispatched (high fps)"
alias water3 "alias cycle_water water1;r_novis 1;r_wateralpha 0.3;echo trans water - not vispatched (low fps)"
bind "somekey" "cycle_water"

David A. said...

I had no idea r_wateralpha caused problems on maps with no VIS data (I found some posts on quakeone.com by MH explaining it). I just assumed it would be ignored and the water would be opaque.

Is there no way to programmatically check for VIS data and automatically disable it? Relying on the user to know if the map supports it or not seems a bit unfriendly.