Few Bugs In QS
#121 posted by ToMaHaKeR on 2012/01/07 00:23:53
QS v0.85.6, WinXP:
- if you Alt+Tab out of game, MWHEELUP and MWHEELDOWN cease to function. also, gamma resets to zero but that's a classic OpenGL issue, I believe
- if the zoom function (default key: F11) is used, mouse sensitivity resets
(but still the best engine :D)
ToMaHaKeR:
#122 posted by metlslime on 2012/01/07 00:36:23
the F11 zoom behavior is a bug in default.cfg isn't it?
#123 posted by necros on 2012/01/07 01:11:14
yeah, iirc, the f11 is just a basic alias that has a present sensitivity setting. you need to overwrite that yourself to match your original mouse sensitivity.
#124 posted by ToMaHaKeR on 2012/01/07 02:03:28
It will sound noobish, but where exactly is default.cfg located? Can't find it in any of Quake's directories, is it in a PAK file?
Default.cfg
#125 posted by mh on 2012/01/07 04:08:26
Is in a PAK file, yeah. And it is an old bug from 1996; the zoom aliases eventually reset sensitivity to 3 (IIRC) and because default.cfg is forced on you your only real option is to put aliases into your autoexec that override these (does QuakeSpasm exec quake.rc or the 3 .cfg file? Can't remeber right now, but quake.rc is another potential source of evil).
#126 posted by necros on 2012/01/07 04:32:23
there's nothing wrong with quake.rc;
quake.rc just execs the config files, nothing more.
anyway, what you want to do is open up your own config.cfg file and add this to the end (or anywhere, really...)
// zoom
alias zoom_in "sensitivity 2;fov 90;wait;fov 70;wait;fov 50;wait;fov 30;wait;fov 10;wait;fov 5;bind F11 zoom_out"
alias zoom_out "sensitivity 4;fov 5;wait;fov 10;wait;fov 30;wait;fov 50;wait;fov 70;wait;fov 90;bind F11 zoom_in; sensitivity 3"
bind F11 zoom_in
and change the sensitivity values appropriately.
#127 posted by erc on 2012/01/07 17:54:46
Hmm.. is it possible to have back the playtime in status bar without recompiling the engine?
Quake.rc
#128 posted by mh on 2012/01/07 21:10:14
Mods can and do contain a custom quake.rc that sets cvars and issues commands itself (e.g if a mod wanted to force water alpha it might add "r_wateralpha 0.4" to it's quake.rc after exec'ing the configs).
#129 posted by necros on 2012/01/07 21:57:27
right, it's there to provide a way to add in custom commands without messing with autoexec and config.cfg.
i did that myself with ne_ruins. i enforced developer 0 by running a config file after stuffcmds, for example, because in the past, players had tendency to play with developer mode on and then complain about console spam. :P
Nothin To Do With, But
#130 posted by ijed on 2012/01/08 05:28:02
AguirRe had a set of commands built in to pause rewind and FF demos.. haven't got around to asking him the how yet.
Demo Navigation
#131 posted by Baker on 2012/01/08 09:14:33
JoeQuake has demo pause, rewind, fast forward.
Demo pause is an easy engine modification. Likewise, so is fast forward will more or less changes the timing of a frame similar to how host_framerate does or the FitzQuake host_timescale cvar does.
Demo rewind ... and I haven't looked at this code to think about it in 5 months or so (I was trying to get interpolation to work right in reverse. And I did (or at least so close the couple of remaining flaws would never be casually noticed). At least with everything except dynamic lights fade timing.) ...
But if memory serves correctly, it builds a stack of locations that point to the demo read positions of the previous demo frames within the demo. So to play in reverse, instead of going forward it picks the previous location from the array and uses that. And if there is no previous location, you are at the start of the demo.
You also have to create an extra "client time" storage unit because cl.time is still important for things like sounds ... you cannot play sounds in reverse so they still need to end after X seconds and only a "forward-only" time instance can do that. In fact, this is also true of particle animations and some other things. But there is also the "demo neutral time" that can go backwards and this should be used for reversible events like animation interpolation, movement interpolation, the display of the clock if you press TAB to see the true time in the demo, etc.
Also, by looking at the current demo read position and comparing against the length of the demo file, you can estimate the percent of demo playback to show a demo progress bar (!!!).
@erc
Start the engine with "-fitz" option restores playtime in statusbar, among a few other things
#133 posted by negke on 2012/01/08 12:28:37
I never understood why the game time display was removed from QS. It's fairly useful, unlike the skill display. This would be better off as a console setting instead of a command line switch.
aguirRe's demo script was an alias config that had the cursor keys increase or decrease host_framerate by by 0.1 steps. No rewind, only fast forward and slow motion.
#134 posted by mh on 2012/01/08 16:01:17
I ported JoeQuake's demo rewind code a while back. It was ... "fun".
I think that Fitz's host_timescale is an infinitely more sensible option than host_framerate for controlling demo speed, but of course it needs engine support.
Gl_zfix
#135 posted by ToMaHaKeR on 2012/01/08 20:39:37
Some textures are still fighting a bit on certain maps, although gl_zfix is enabled. But this is noticeable only if they are viewed from the distance. Can gl_farclip fix this if it's set to a ridiculous level, or parhaps some other gl_ trick?
#136 posted by mh on 2012/01/08 22:07:05
A high value of gl_farclip will make it worse as it reduces your z-buffer precision; ideally setting it low will help more (there is, of course, a tradeoff in that).
z-fighting is really a mapping problem, and it should be fixed in the map and not by the engine.
The traditional "fix" (using polygon offset) sucks because (a) the z-buffer is non-linear so offset factors will have different effects at different depths, and (b) the OpenGL spec allows polygon offset to be implementation-dependent, so the same offset factor may have different effects on different hardware.
Demo Control
#137 posted by ijed on 2012/01/09 00:46:12
I haven't requested this (yet) but with Peg's RMQ demo's it'd be very useful. There's lots, and the level length is 30 minutes average.
And yeah, z-fighting is bad level building.
What are the engines that can play and rec demos with reloads and map changes except DP?
#139 posted by necros on 2012/01/09 01:21:57
well... technically all of them.
save a game
die somewhere
type disconnect
type record demo
load a game
same for level transitions.
change level
save
type disconnect
type record demo
load the game and continue playing
this is extremely helpful when sending in beta demos! :)
yeah... this is extremely awkward, hence I'm looking for engines that can do it seamlessly
Any Engine Can IF ...
#141 posted by Baker on 2012/01/09 03:20:51
Engine tutorial: Playback demos recorded across map changes. (Ridiculously easy).
http://forums.inside3d.com/viewtopic.php?t=2397
#142 posted by mh on 2012/01/09 03:30:18
I haven't requested this (yet) but with Peg's RMQ demo's it'd be very useful. There's lots, and the level length is 30 minutes average.
Oh, you've already had this available for years. cl_demospeed; set to negative numbers to rewind; it fucks with the motion blur though so you may wish to disable that.
Demoplay With Map Changes
#143 posted by szo on 2012/01/09 09:43:55
just added support for this to quakespasm:
http://quakespasm.svn.sourceforge.net/viewvc/quakespasm?view=revision&revision=604
... in the svn repo now, will be part of next version
Does It Also Work With Reloading? And After Dying
#144 posted by negke on 2012/01/09 10:42:26
There's a way to fix demos recorded across map changes, but it only works for protocol 15 and 10002. With BJP's convdem tool, simply append a short newly recorded demo snipped to the end of the existing one (merge) and the post-mapchange recording will be shown fully.
Negke: Die/reload Demo
#145 posted by szo on 2012/01/09 11:56:55
.. yes it does: tested with this one:
http://quakespasm.sf.net/tmp/tt2.dem
|