You'll get the command-line tools if you install Xcode.

You can also get the command-line tools by running "xcode-select --install". In fact you should do that even if you've installed Xcode, since that command will also set up some default Unix/Linux-y paths for the linker and preprocessor (like paying attention to /usr/local/lib and /usr/local/include by default). 

Since an arm injury a few years ago I've only been able to play with a controller.

Today, feeling good, I thought I'd try a mouse in QS again in anticipation for the new Arcane Dimensions.

Sadly, I found that mouse movement 'jerked' or 'stuttered' every few frames or so. This doesn't happen when I use a controller.

Looking around I found some threads pertaining to other games having the same issue. It seems to be an SDL thing.

Is there a way to set raw mouse input in QS?
Does anyone else have this issue?

I have a Logitech g700s mouse on a Win 7 x64 PC with GTX 780 and i7 4770k.

And, no, it's not lag because my mouse is wireless! The mouse is as smooth as butter in other games. :) 

Are you using quakespasm.exe or quakespasm-sdl2.exe? (or the dev builds from http://quakespasm.ericwa.com/job/quakespasm-sdl2/ ?)

Try the -sdl2.exe one, it should use raw mouse input.

Another thing to try is setting "host_maxfps 60".

(I have this problem on OS X, where mouse events only arrive at 60Hz, and there is no raw mouse input in SDL1/2 on OS X.) 

I always use the most up to date dev builds (in this case 1308 and 1310).

Setting "host_maxfps 60" seems to have done the trick though. I had host maxfps set to 72. I presumed, having a 144Hz monitor that half the refresh rate would result in a more solid performance than 60Hz. You live and learn, I suppose.

By the way, while looking around for this issue I found that you're using an older version of the SDL2.dll. Is there any reason for that? Just curious. :) 

I usually set my host_maxfps to 150. 

Problem with variable host_maxfps in single-player Quake is that so much of the engine is FPS-dependent, and often in ways that are gameplay-breaking. 

Ok, glad to hear host_maxfps 60 helped. That suggests QS is only getting data from your mouse at 60Hz which is weird :-(. Try host_maxfps 150 as Fifth mentioned too, although I'm not sure how much physics starts to mess up at 150?

I found that you're using an older version of the SDL2.dll
It's a custom build by szo, made from the latest release (2.0.4) + some patches, details here.

MH - yeah, trying your Inside3d tutorial on decoupling the server / client FPS is on my wishlist. 

Not noticed physics messing up at 150. I find Quake literally unplayable below my monitor refresh rate of 144. I get headaches and nausea. 

I need to get a 144Hz monitor! 

I have a monitor that goes to 100Hz, and even that is a night/day difference. Highly recommended! 

MH - yeah, trying your Inside3d tutorial on decoupling the server / client FPS is on my wishlist.

I've better code since, unreleased but if you're ever looking at this I can give you a code dump. 

In DirectQ, which had client/server decoupling if you turned left or right using the keyboard while moving forward you had jerky movement, like a mild stutter.

DarkPlaces and the QW clients don't, was something I wanted to get to the bottom of.

In 2014, I spent some time trying to implement client/server independence before ultimately moving it to the back of the list because that would have just been a piece of a more ambitious goal like implementing DPP7 or some sort of predictive protocol for better coop.

(Which itself is quite a laundry list -- delta compression, server timestamps, baseline, acks, etc. etc. and of course implementing IPv6 and connectionless connections.)

Merely implementing client/server independence DirectQ style is no small task :( Timing nuances are everywhere, even in a few places they have no reasonable place existing.

Spike takes timing to even more of an extreme by creating a separate thread for the server.

/Pandora's box 

But yeah, when I made a run at it, I had all of mh's notes from insideqc I could find on-screen for reference. 

I'd say multiple controller support and splitscreen in a decent engine is more important ;) 

its DP that can run the server on a different thread. the real issue with running the server on a different thread is that of cvars and commands. cvar_set would require a full-blown sync to ensure the other thread isn't reading cvars that are about to go away, while commands also need some sort of sync - which is not what you want with +forward etc.
on the other hand, running the server in an entirely different process skips over ALL of that, with more understandable behaviour for the user. much fewer mutexes, much less likely to break other stuff, but more annoying to configure.

either way your client needs to be able to properly cope with dropped/delayed packets. 

In DirectQ, which had client/server decoupling if you turned left or right using the keyboard while moving forward you had jerky movement, like a mild stutter.

Part of the problem there was that I'd made a huge mess of the timer code well before then. In earlier versions you can timescale down and see how atrociously jerky it really is, and it took me a long time and many revisions to get things back to something that even approached correct. I don't think I was ever 100% successful either, and I didn't really understand the subtleties of the timer code at the time. 

prev weapon bind does not seem to work for some reason. Anyone else getting this? 

Prev weapon is controlled by QuakeC and QuakeC only. Some mods don't support the prev weapon impulse, one example is Duke of Ontranto and I think another example is Castle of Koohoo.

(Mark V uses the Requiem engine cheat to make prev weapon available in about any mod, but it isn't 100% fullproof and at least one mod --- Neruins --- it doesn't work "right" at all) 

I really, really appreciate the Xinput controller support added to recent builds of QS but I was wondering if it would at all be possible to add rumble support?

My first foray into Quake was on the good old N64. Two things I really miss from that version is centred message text (though I don't think you're interested in adding that option) and the other is the Rumble Pak.

It adds some real heft to the weapon fire. 

please... please please please......

(obvs you'd need to have support for more than 1 pad) 

This has come up quite a few times, and I think Spike has given some good discussions on what's involved, but one thing to realise is that this:

(obvs you'd need to have support for more than 1 pad)

Isn't true.

You need a hell of a lot more.

You need to recode the engine to be able to support 2 or more clients, running concurrently, in the same process. 

And considering how there are more global variables in the Quake engine than atoms in our solar system, that is going to be a huuuge, collosal task.

I wonder, if that's the case, if we should consider instead recoding the engine completely, from scratch. And while we're at it, doing away with the hardcoded engine limits. 

Raised limits have long been standardized -- and mostly don't present a problem in modern times.

What Quakespasm uses as limits is essentially the standard. Those limits are ...

1) BSP2 for map limits
2) For non-map limits, the limits are nearly unchanged from FitzQuake 0.85 (with 2 small modifications, if I recall, max packet size and visedicts)

Protocol 666 --- written by metlslime in FitzQuake 0.85 in 2009. Supercedes protocol 15. If there were awards in Quake, metlslime would have won something like "Best Modification of The Decade" or something.

http://celephais.net/fitzquake --- comparing the FitzQuake 0.85 vs. FitzQuake 0.80 source codes.

http://forums.insideqc.com/viewtopic.php?f=12&t=2450 (summary of protocol 666 changes)

BSP2 --- written by MH in 2011 or 2012. Similarly outstanding like protocol 666.

Spike made a BSP2 patch of Mark V, which was used to easily port BSP2 to Quakespasm ...

http://triptohell.info/moodles/junk/markv_bsp2.zip <--- changes for BSP2

... and later probably the basis of BSP2 support in other engines like Super8 and Qrack, if I recall correctly. DarkPlaces and FTE support BSP2 as well. BSP2 was written by mh for the RemakeQuake engine. 

I was able to get prev weap to work with ne_ruins a while ago based on reQuiem. It may require omission of quaketest compatibility or similar to obtain this result. 

The Requiem impulse 12 hack will crash neruins. Give yourself all weapons and ammo, then use impulse 12 a whole bunch. *boom*