fte with r_softwarebanding 1 uses 8bit rendering for the world and models, except for coloured lighting (where each colour channel is performed as a separate lookup) so disable lit support if you want strict 8bit colours.
this applies to world(gl+vk renderers) and models(gl renderer). other things including particles etc are unaffected by this, but at least fte's particles can follow palette-based ramps too. 

Thanks - just had a look and r_softwarebanding looks lovely and I even like how it looks with fog and coloured lights on top of it too!

There's a lot of stuff I'll need to turn off though to make it look and sound more vanilla - is there a "proper oldskool" config somewhere? 

how do i turn off the mouse smoothing in FTE? 

m_filter defaults to 0 so reset that if its no longer 0. there isn't any other mouse smoothing.
m_accel 0 maybe? again defaults to off.

'fps_preset vanilla' should disable(and in some cases enable) all the stuff to make fte feel like vanilla's software rendering, including the demo reel, nq sbar, nq player physics, software banding, square particles, disables lerping, etc.
complete list of cvars changed with the presets: https://sourceforge.net/p/fteqw/code/HEAD/tree/trunk/engine/client/m_options.c#l818 (each preset is cumulative with the prior ones, so you'll need to consider the settings above the vanilla preset also, if you want the complete list)
the problem with lots of settings is figuring out which ones you actually want set. :s 

quakeforge's glsl renderer should also render much like software rendering (unlike its regular non-glsl gl renderer).
that said, I don't know how easy it is to get quakeforge to actually run, hopefully taniwha has fixed it up a little since I last tried. 

m_filter "0"
m_accel "0"

I have those set but it makes no difference - the mouse just feels weird and laggy compared to quakespasm, like the movement is being interpolated or something. QS feels immediate... 

I'm sure you've checked, but is vsync enabled, either in the client or forced by your gpu settings? 

I'm sure you've checked, but is vsync enabled, either in the client or forced by your gpu settings?

No I hadn't checked, and that was indeed the culprit.

vid_vsync "0" now added to my config. Cheers! 

 

Can anyone recommend a tool I can use to profile the cpu / gpu usage of quake engines on my pc? I have noticed that when using Quakespasm, my laptop is silent, but on other engines I've tried (FTE, MarkV), running under the same config I use for QS, my laptop's fan blows like a foghorn for some reason... 

Gonna have a punt with a tool called HWiNFO. Will report if I see anything interesting 

This is almost certainly happening because QS is using a Sleep call every iteration of it's main loop, whereas other engines are not.

There are valid arguments to be made that running flat out is actually correct behaviour for a game engine. 

Might that also be related to how QS's CPU usage rockets when I have it minimised vs when I'm playing it? 

I used HWiNFO to log all the stats when running the quakes.

I did a test where I played demo1 twice in QS, and did the same for MarkV using equivalent graphics settings etc. (actually I played demo1 three times in MarkV because the fan was really going crazy after the second time round and I wanted to see if it was getting any hotter)

So here is a simple chart of the max CPU temp across all my cores when playing the demo, sampled at 2-second time intervals (there are less samples for QS because I played the demo twice there vs three times for MarkV)

https://docs.google.com/spreadsheets/d/1ozielkRSptmYI6PSSrn1QwSBcai8WTHauQ1pW8z__5s/edit#gid=0

With QS my CPU temp always stays just below 50C, but with MarkV it's constantly running over 70C.

Now I'm no engine guru but my gut feeling is I'd rather keep my CPU temp at 50C if I have a choice in the matter (considering I'm getting identical framerate in game either way)

mh - what are the advantages to "running flat out", as you say? 

is this win7? you can set your cpu states in power management. depending on your mobo you can do this via the bios. You can also have the client run on 1 core, may help temps. Maybe even give process tamer a try.

70C isn't necessarily bad. I wouldn't want to run 74-80 constantly, though. 

Not sure I want to go digging around in bioses and tinkering with CPU settings, not really my area :} 

Yeah, QS has a 1ms sleep in main_sdl.c. It also sets the Windows timer precision to 1ms (done by sdl) - afaik this raises power use somewhat for the entire system while QS is running, but it should mean that a 1ms sleep is actually 1ms and not 15ms or something.

Just looked at MarkV's source, it looks like you need to set "host_sleep" "1" to enable sleeping.

I imagine the temps will be about equal once MarkV is sleeping. On complex non-id1 maps QS may take a lead, owing to its new GL renderer, but not sure if this will show up in temps. 

Well damn, that did the trick! Just did another profile and the temps in MarkV are down to around 50C, similar to QS.

So, any reason why this isn't the default behaviour? 

First of all, and to establish context, there at least used to be a perception that Quake is an older game, uses less resources, therefore it should have lower CPU usage than a newer game. However, a simple "while (1) {}" loop is sufficient to peg a CPU core at 100% (you won't see this in modern Windows because the OS will move it from core to core quite frequently). So it's not the amount of work you do that matters.

Both Windows Sleep and Unix/Linux usleep specify that Sleep times are a minimum, not a guaranteed time interval. To quote from the usleep man page: "The sleep may be lengthened slightly by any system activity or by the time spent processing the call or by the granularity of system timers."

So when you sleep for 1 millisecond, you will actually be sleeping for more than 1, and the specification allows it to be much more than 1; this can be sufficient to cause you to miss a vsync interval, or disrupt input. 1 millisecond doesn't sound like much, but if you remember that 60fps is 16 milliseconds per frame, then it's a substantial enough fraction of it.

At this point a typical reaction might be something like "Quake frame times are so short anyway, surely this is just a theoretical problem". So let's assume that a typical frame time is 1ms. The frame runs then it's followed by a bunch of Sleep(1) calls until it's time to run another.

It should be obvious what's going to happen - at some point the last of those Sleep(1) calls is going to fire, and if you sleep for just a little too long you're going to miss the interval and the next frame will run late. Slightly late with vsync disabled, but with vsync enabled you'll drop to 30fps.

So the reason why it's preferable to run flat out is because the alternative is potentially worse.

That shouldn't be read as meaning that all Sleep calls are bad. If you're running on battery your priority changes and you'll definitely want to sleep. But sleep as a general solution should be avoided; the OS should move your program between cores automatically which will prevent individual cores from ever running at 100% all the time, so nothing should be overheating. Or alternatively, if it's a multithreaded game that's already CPU-bound, then you most definitely don't want to be giving up a resource that you don't have enough of to begin with.

None of this is going to convice anyone who's already made up their minds, I know... 

how does this relate to c-states and os power management? Do sleep calls trigger certain c-states? If a system has c-states and power management disabled does host_sleep override that or does it do nothing? 

I don't know about Linux, but on Windows Sleep calls don't define how your program interacts with OS power management. All that the documentation states is that the current thread is suspended for an interval based on the value you specify.

What I infer from that is that if there's other work that the core could be doing, it will do it, so you should have no expectation that calling Sleep will guarantee that you'll go into a power-saving mode. After all - Quake isn't the only program running on your OS. 

Thanks for that detailed explanation, most informative. 

My only objection, for Windows anyway, is the current Sleep docs here seem to state pretty clearly that, if you set the timer resolution to 1ms with timeBeginPeriod, a Sleep(1) will actually sleep somewhere between 0 and 1ms, but not more than 1ms. IIRC, I have measured Sleep(1) sleeping for several milliseconds if you don't call timeBeginPeriod, but if you do it's reliably never more than 1ms. (Of course, this is one random test I did, one PC, probably windows 8.1 or 10, but at least it matched the docs.)

Agree regarding vsync.. it always seemed broken to me, at least in QS (adds so much input lag that it's almost unplayable), maybe most Quake engines (?). If vsync is in use, shouldn't the throttling of the mainloop be left to the blocking "swap buffers" call? 

 

If vsync is active then I suggest don't throttle otherwise, either via sleep or Host_FilterTime. IIRC a glFinish immediately after SwapBuffers helps some; causing input to sync up correctly with display, otherwise the CPU may be running a few frames ahead of the GPU.

Last time I checked vsync was a busy-wait on some hardware/drivers, but that was in the D3D 9 era.