Is autodemo disabled by default in the latest version? 

 

Yes.


@Baker "cl_autodemo 1 needs host_maxfps set to 72 -- otherwise it won't record because the demo size could be massive and 72 fps is only correct Quake physics in single player. (todo: document that)"

But what would be the problem if you have a lower FPS set, as I do (and probably anyone else who uses vid_vsync)? Sure, physics might be wonky in Single Player, but... that's not exactly a reason to prevent autodemos if the user wants them, at a lower FPS.




I'm playing with zoom aliases now. I think r_viewmodel_fov should default to 0 (standard Quake behavior) rather than 90. Yeah, it improves the look if someone sets a higher fov, but it makes it look weird when you zoom in with a lower fov.

Standard Quake is the opposite, looking correct when you zoom in but bad when you set a high fov.

So, I prefer standard Quake behavior, especially when I have set "weapon draw = quake default" in the menu.


An optimal way to do this might be to have 2 separate variables:

r_viewmodel_fov_min
r_viewmodel_fov_max

Then you could set the max at 90 to never get the weird effect when zoomed out, but the viewmodel would still be allowed to be pulled back when you zoom in (which looks correct).. unless you wanted to clamp that too with the min setting to not go below. 

I'll make the cvar that control "window02_1" only apply to the id1 folder.

I'm hardcore and already had realized that even as a setting it would default on for people using -game. 

maybe you can bring it to the preferences in menu? 

Weird, I always set fps to 150. Monitor is 144hz though, need that max fps 

I know which mappers reside in Asgard and know you are one of them, I've read this site regularly and know, for example, you used to run the speed mapping session.

Let me assure you that if for instance that if you have something to say, I am always listening.

I'm a very conservative engine developer despite also adding player-oriented features.

When I started engine coding, Ben Jardrup helped me several times and would explain the compatibility mindset to me. 

Same,

I never encountered any physic issues so I just kept it at my max refresh. :O 

I'm quite interested in why the framerate changes the physics. I wonder if it is the physics stuff being calculated every frame, rather than every 1/72nd of a second.

If that is the case is it worth trying to keep the framerate at a multiple of 72 to be safe? (144 if your monitor can do it). 

autodemo -- pulsar, I'll spend some time thinking about right way to handle to.

sound 44000 - bloughsburg, I remember some of the sound mixing discussions about that. I'm adding that to my list and will eventually happen.

@fifth - Not sure what you are wanting. Quake physics are still 72 fps and although fps independent physics is on my eventual to-do list. If you set 144 hz in your video card and vid_vsync 1 and host_maxfps 144 in the console, do things work as expected?

@gunter - at a higher fps, the demo files could become huge. Maybe make cl_autodemo 2 option -- record an autodemo regardless of the fps. gun fov 90 -- people love the feature, you know how to disable it.

@nightfright - at least for now, Mark V is a pure Open GL 1.2 engine for maximum hardware compatibility for any machine Windows XP or higher. MH needed a glsl for that in Remake Quake engine.

The track by mapname thing, I will think about and have an idea on a "correct solution" which would give you the same ability to control it but does not work in a way similar to what to you suggest, but I would need to put some thought into it so is more likely a future version item.

@nightfright part 2 ---

I'd recommend creating a Wiki page at https://quakewiki.org/wiki/Main_Page listing extra replacement content paks and I'll put a link to that page on the Mark V page -- that way if new content becomes available it can be updated and available to users without me continually editing the Mark V homepage.

Be sure to upload mod enhancements to Quaketastic (see Func screenshots thread for username, password if you don't already know) beause Quaketastic files are preserved forever at the Amazon/Government funded archive.org site (!!)

/I think that's most of the replies, I read Spike's thoughts on gamedir change and @snaut yeah that's cool. 

I've always thought that the engine ought to be able to cap the framerate of the demo independently of the actual client framerate -- When I recorded demos for rubicon 2 I intentionally set host_maxfps really low to get a smaller demo file, but it would be nice if it was an automatic feature.

But, I never did the research into what kind of problems would have to be dealt with to make the demo playback correctly. For example obviously the dropped frames might have important events in them, you'd need to save them and put them in the next demo frame so they are not lost. 

Spike actually has a separate thread (or similar) in FTE to ensure 72 fps even if the client goes under 72 fps.

In 2014, I made a run at acquiring DirectQ's fps independent framerate, but noticed a little jerk in DirectQ when using +turnleft and +forward at same time -- so I moved it to the back of the queue for future consideration. 

I suspect Spike might suggest that the best to get such a result might be having the "server" record the demo instead of the "client" --- in a properly client/server separated engine (like how the Quakeworld engines have complete client/server separation). 

Never knew it affected demo filesize. I always play at 144 fps and never noticed any bugs 

two things:
1) use a decent network protocol that doesn't resend everything every single packet. get AD's particles under control by harassing sock into using clientside stuff instead of network abuse.
2) screw threads, just don't send packets to the server quite so often. from what I remember the only real challenge is figuring out how to deal with impulse;wait;impulse scripts. one way is to just not wake up from waits while connected with an impulse still pending. obviously if there's any hacks internally directly linking both client+server then you'll need to fix them, otherwise independant rendering/server isn't really any different from a public server or demo. drop the server's rate to 10hz and you'll get quake2! 

Yes to all of that ;-)

Btw, offhand do you know about about the bloughsburg/zbikey sound crackle @ 44 hz. I don't touch the sound mixer often -- and such a conversation wasn't recent so I can't recall the details immediatelly. Is that the true hz is 48k issue? 

@spike also -- while I'm thinking about this -- your single port rewire of reading messages -- I haven't investigated so is probably non-issue, but in my head I was thinking "make sure that can't skip a player impulse". I think QSS queues up +jump and such.

/Again, haven't had time to focused on deep examination of that, so quite possible I'd see something obvious that I'm not thinking of at the moment. 

I have no audio crackling / distortion, everything sounds fine for me.

Those who are having glitched audio, might help track down the problem if you type 'condump', and paste this section from your id1/condump.txt:
Sound Initialization
Set primary sound buffer format: yes
Using secondary sound buffer
2 channel(s)
16 bits/sample
11025 bytes/sec
DirectSound initialized
Audio: 16 bit, stereo, 11025 Hz
Sound sampling rate: 11025

Also - congrats on the release, Baker :) 

Thanks ericw! At more than one point, didn't think it would ever happen. 

qss's single-socket stuff just switches from looping through each connection and then handling the messages to checking the socket(s - ipv4+ipv6+ipx) and then parsing them within the context of the player with the same remote address.
there's no extra buffering there that wasn't already there, certainly not in the client-side stuff. inputs are handled the same way as they always were.

if you're getting crackles mid-sound then rewrite your resampler. resampling 44->48khz will probably screw up the waveform if you have 44khz frequencies. most people can't hear those anyway.
be aware that the vanilla resampler uses 'nearest filtering', which has somewhat obvious deficiencies...
on the other hand, pops when you override another sound could be fixed with a gradual fade-out instead of suddenly dropping down to 0. 

Count me as another person who is very glad this release happened, and it happened now instead of later in 2017!


"gun fov 90 -- people love the feature"

Well, people love lots of things, but that doesn't mean Quake's default should change, heh. I mean, lots of people probably love r_viewmodel_ring 1, but it's defaulted off....

From looking at the old thread, the people who are using r_viewmodel_fov are not using your default value anyway.... They are using 110 or 130.

And of course, they are using it when setting a higher fov. It's good for that. I like it for that too. Too bad it doesn't work ONLY for that.... Lower fov's make it weird.

So yeah, I'll disable it. I have a section in my fitzquake.cfg file for "Restore Quake Defaults." The section is actually not too long (about 7 behaviors), which is a very good thing. But I'd be more happy if it was completely unnecessary to restore any Quake defaults!

Now, it's not always bad to change a default, but you have to be certain there is definitely no negative impact from the change.

For example, I couldn't see any negative impact of defaulting r_viewmodel_ring 1. It's a cool setting, and everyone should use it... but I would never actually argue for making it a default... because it's not Quake's default! Heh. But of course, I would't mind if it was made default either, unless some unforeseen negative impact arose.

Of course, sometimes the "negative impact" is simply that it doesn't look the way people are used to, and they don't like that... sooo... in the end (as you say), you gotta be really conservative about changing defaults. Err on the side of caution. 

In this engine, one thing I've tried to do is absorb as much of the feature set from other engines with great contributions that aren't developed any longer like Enhanced GLQuake/WinQuake, ProQuake, JoeQuake.

But it is currently lacking one of the most prominent features of JoeQuake as an option (will off by default), which are the optional particle effects system (QMB particle system by Dr. Labman).

It'll need some rigorous testing when it's available in a few hours. 

Rigorous is my middle name.


Well, not literally. That would require some really weird parents.... 

Here you go! This is with me changing sndspeed to 44100

Sound Initialization
Set primary sound buffer format: yes
Using secondary sound buffer
2 channel(s)
16 bits/sample
44100 bytes/sec
DirectSound initialized
Audio: 16 bit, stereo, 44100 Hz
Sound sampling rate: 44100 

Oops, and here is QS:

Sound Initialization
SDL audio spec : 44100 Hz, 1024 samples, 2 channels
SDL audio driver: dsound, 65536 bytes buffer
Audio: 16 bit, stereo, 44100 Hz