Friday, February 25, 2011

DirectQ Update - 25th February 2011

It's confirmed that a Beta 2 will be forthcoming over the next few days as a few bugs (one serious) have surfaced.

The serious bug is related to the behaviour of ATI cards with my surface vertex caching system; at least everyone who's experienced it so far is on ATI (the specific model doesn't seem to matter). I've gone back and removed the caching system, cleaned out a lot of the code, and generally made things a lot simpler.

One thing I'm experimenting with is converting most primitives to triangle-strip layout; on some hardware this can potentially give faster performance. I'm still using indexed triangles as the basic primitive, but they are laid out in memory in strip order, so according to the documentation this should give optimal performance. I think with the likes of Quake - which doesn't really stress vertex submission - it's not going to be too big a deal, but it will be interesting nonetheless.

I have an initial cut of code written that resolves the MDL shading problems, but I've yet to transfer it to my main codebase. The one thing it doesn't do is interact well with overbrights; as it's based on software Quake it just assumes that everything is overbright always. Not sure how I'm going to approach that one. It also requires pixel shader branching, but I can work around that by using a 1D texture as a lookup table and setting the texture address mode to clamp.

I'm also curious about the FPS lock I introduced in this version. Basically, a single player game running at higher than 72FPS will fuck up physics - so badly that sometimes it can kill you. To work around this I've locked FPS to a max of 72 in single player games. This is a balancing act where I fear that I'll never get it right - people will complain about the FPS lock, but if I remove it people will complain about the screwy physics.

More next time.

6 comments:

=peg= said...

Maybe just print a warning message at the start of the map when host_maxfps is set higher then 72 and let the player decide whether he prefers smooth gameplay with wonky physics, or proper physics with less then optimal smoothness..

(I guess cutting down on mouse polling rate and dpi as well as setting monitor refresh rate to 72hz in Single Player mode would make it smoother.. but that is a lot of trouble to go through for a quick Single Player game, personally I don't mind the occasional weird physics that much ;))

mhquake said...

"personally I don't mind the occasional weird physics that much"

Not do I aside from the fact that it can kill you.

=peg= said...

Hehe, yeah that's minor inconvenience ;)

In single player mode I usually stick to 125 fps to (sort of) get the best of both worlds so to speak..

David A. said...

The beta is unplayable on my A64 3800+, nVidia 7950GT, Win7 32-bit, latest drivers. The game stutters bad enough that the sound start cutting out.

FPS results are with vSync off, cl_maxfps 1000 (I normally play with vsync on; same problem there):

Last version:
timedemo demo1: 383
start map fps: ~300

Beta:
timedemo demo1: 186
start map fps: 38-50

The FPS is noticeably lower when playing a game. Both demos and gameplay have the same stuttering issue. "nosound 1" also did nothing.

=peg= said...

A few more minor things we (Orl, Polarite and myself) noticed last night when playing online:

When console is down:

- All environmental world textures stop animating (sky scroll and warping effect of liquids).
Not a big deal (to me anyways) but I just wondered if this behavior is intentional or a side effect of the way the new renderer works..

- In windowed mode + console down -> no mouse pointer to take you out of quake (unless you actively alt-tab).
(I guess this is a bit of an inconvenience to players who are used to that kind of behavior in other clients)

- The quad(and presumably all other powerups)-timer only works for the first quad you pick up.. I guess, ideally, the counter should reset to 20 when you pickup another quad while you already have one, think e4m3. (nice feature tho)

- If at some point you could somehow "hack in" a match-timer and teamscores (HUD) for match mode (cr-mod/runequake-mod) ala proquake/qrack that would be a real bonus ;)

mhquake said...

"Maybe just print a warning message at the start of the map when host_maxfps is set higher then 72"

Main problem is that people generally ignore these messages (...and then complain anyway...)

"When console is down - All environmental world textures stop animating (sky scroll and warping effect of liquids)."

Intentional; if the client is paused any client-side animations or effects should also pause. They do in software Quake so this was a GLQuake bug (or omission).

"In windowed mode + console down -> no mouse pointer to take you out of quake (unless you actively alt-tab)."

The pointer should be visible and I have code in there to ensure that it is. Maybe a bug with the old input code on your machine?

"The quad(and presumably all other powerups)-timer only works for the first quad you pick up"

This might need a protocol change to fix as cl.itemgettime is only updated if the items actually change. The client doesn't seem to have a way of knowing that you've picked up an item you already have.

"If at some point you could somehow "hack in" a match-timer and teamscores (HUD) for match mode (cr-mod/runequake-mod) ala proquake/qrack that would be a real bonus"

Some day I'm going write a few screens of rant about ProQuake hacks (which are almost as bad as Nehahra hacks).