DirectQ is likely going to get a patch release maybe sometime next week; there are a bunch of small updates which individually are nothing major, but taken together warrant it.
My D3D 11 experiments continued a while back, but have now stalled again. I got texture loading done - it's not a nice API for loading textures (to say the least) but I managed to get something that looks reasonably sane wrapped around the raw API calls.
Been playing with GL_ARB_vertex_program and GL_ARB_fragment_program. These are the old assembly language shaders that predated GLSL, and I have to say that my impression of them is fairly - well - impressive. The OpenGL interface for them is clean and minimal, and the shading language is simple and unambiguous - both of which compare favourably to GLSL which seems like a madhouse sometimes. There's also less for driver vendors to mess about with (and - inevitably - mess up). As an experiment I ported a stock GLQuake to using them throughout the renderer in maybe half a day (already having the required algorithms for water and sky warps in my GLSL/HLSL code helped a lot here). I've since replaced the water and sky GLSL in RMQ with these, and am considering doing a full shader version of the engine - if only I could convince the team to agree to going shaders-only. :(
There's more but I'll save that for another day.
Thursday, August 18, 2011
18th August 2011 - Various Bits and Pieces
Subscribe to:
Post Comments (Atom)
10 comments:
Vertex Attrib arrays were a bonus feature of vertex/fragment programs that I wasn't expecting. So much cleaner than glEnableClientState/glclientActiveTexture/glTexCoordPointer mess.
Been playing with 1.8.8_final for some time now, and I'm afraid there is still something not quite right with it..
Both polarite and me noticed mouse lag, especially when using LG or being shot at with LG.. It appears to be fps-dependent, being more apparent on 500 fps then on 250...
But at the same time.. 200 fps seems bad, while 199 fps (which actually reports 167) seems fine again..
Kinda hard to put the finger on it, but I'm guessing it has to do with the timers and floating point precision and stuff..
I found at least one scenario where the mouse lag can be reproduced consistently and that is when setting host_maxfps to 500 and running up and down the lava-stairs on this map..
Hope that helps identifying the problem..
The only thing I noticed is the hud match timer shows up during a normal match, but goes away when you're killed (but comes back when you respawn).
If you are fighting for Q and die before it spawns, typically you stay dead and watch exactly when the enemy picks up the Q. That way you can time it perfectly next time. So the timer is still important even when you're dead.
Other than that this release is the best one yet!
- Magnus
"The only thing I noticed is the hud match timer shows up during a normal match, but goes away when you're killed (but comes back when you respawn)."
The status bar goes away when you die because the client struct is no longer valid; the timer is part of the status bar so it needs to go away too. You can use scr_clock 1 to get another timer that's always on-screen.
I'll look into it, but no promises.
"Both polarite and me noticed mouse lag, especially when using LG or being shot at with LG.. It appears to be fps-dependent, being more apparent on 500 fps then on 250..."
I doubt if it's mouse lag; it's most likely something else that's appearing to be mouse lag.
"I found at least one scenario where the mouse lag can be reproduced consistently and that is when setting host_maxfps to 500 and running up and down the lava-stairs on this map.."
All I notice here is that it's a bit of a bumpy ride, but that's from some FPS-dependent client-side physics that's always been in the engine; nothing to do with the mouse.
MH, don't worry about the timer thing on death if its any effort.
The easy solution is to just spam a bind that has %t in it anyway when the powerup is picked up. The only downside to that is you don't know if its like an early 55 sec or a late 55 sec.
No worries at all.
Thanks again!
- Magnus
I would greatly appreciate it if you would add in an "avidemo " command for recording videos at any framerate specified. This command would output TGA, PNG, etc. images, as well as a WAV file for audio. Thanks.
This link contains useful information on adding support:
http://forums.inside3d.com/viewtopic.php?t=1259&sid=27d5bd4b387c62c4e171039fb9d94499
The only thing I would prefer is that it not record straight to an AVI file and instead output to separate image files.
"I doubt if it's mouse lag; it's most likely something else that's appearing to be mouse lag.
All I notice here is that it's a bit of a bumpy ride, but that's from some FPS-dependent client-side physics that's always been in the engine; nothing to do with the mouse."
Well, whatever the case may be, I do get a full 2 to 3 seconds latency in that particular spot (offline that is) depending on the value of host_maxfps... And by latency I mean delayed response to my keyboard and mouse input.. Kinda feels like ping 1000+ :/
Something similar seems to happen online (on different maps) but not as apparent/consistent..
Anyways, this is still a great release, so I will be using it nevertheless ;)
"Well, whatever the case may be, I do get a full 2 to 3 seconds latency in that particular spot (offline that is)"
Wow, that's not good. I musta run up and down those steps maybe 50 times and didn't notice anything, but 2-3 seconds is quite evil.
I have another suspicion. I had some code in to throttle back CPU usage if the game was idle for a while, so maybe that was being a bit too agressive. I've changed the way it works (especially to disbaled by default) so we'll see what happens in the next one.
"I would greatly appreciate it if you would add in an "avidemo " command for recording videos at any framerate specified. This command would output TGA, PNG, etc. images, as well as a WAV file for audio. Thanks."
I had this in an unreleased version but the AVI export never worked right; it always blew up when trying to grab the backbuffer surface. Writing out individual images would work though (it's what we use in RMQ - for portability reasons there as AVI codecs are OS-specific). Maybe worth a try again?
"Writing out individual images would work though.. Maybe worth a try again?"
That would be a nice feature to have for sure! Using individual images is more flexible anyways, as it allows for easier compositing/sequencing in Blender for example :)
Post a Comment