try updating pak0.pak. Is there a zip on quaddicted? I guess this should be covered on:
https://www.quaddicted.com/quake/installation which currently doesn't say anything about patching.

(hmm, weird my pak0.pak - from Steam, I think - doesn't match the md5 sum listed there. the pak1.pak does though.) 

Found it here via a google search: http://community.pcgamingwiki.com/files/file/411-quake-shareware-pak/

Haven't checked to see if Quaddicted has it too.

Anyway, that seems to have worked. :) Here's hoping I haven't inadvertently broken something. 

Just checked and both my pak files have md5sums matching the ones on Quaddicted. So I seem to be up to date -- finally. :)

Thanks for all your help. 

The quakespasm engine does not seem to work nicely on the raspberry pi. It has slow framerates and broken geometry. Oddly, the more demanding darkplaces engine works smoothly. Any clue why this is happening? 

QS needs desktop OpenGL, whereas DP is able to use OpenGL ES.

It sounds like desktop OpenGL has been software emulated only until recently, see: https://www.raspberrypi.org/blog/another-new-raspbian-release/

Do you have a Pi2? Try enabling the experimental hw-accelereated OpenGL option. 

The experimental drivers do help with qs, but effects like dynamic lights slow it down, and some other factors I haven't pinpointed yet. Would it be hard to allow OpenGL ES with qs? 

adding full GLES support is possible, but relatively a lot of work.

there may be some simple tweaks to the lightmap format that would fix slowdowns with dynamic lights.. but we need some developer with a RPi to do it. 

Would it be hard to allow OpenGL ES with qs?

It would need a rewrite of much of the renderer because it still uses a lot of glBegin/glEnd calls which don't even exist in ES. BSPs and MDLs IIRC use vertex arrays/VBOs but they're the easy ones to port. 

It would probably be worth it on the long run but sacrifice compatibility for some ancient hardware maybe? 

The network drivers for vanilla have this class-like structure with function pointers that are filled with the proper functions for a specific net driver. I don't currently see a reason why we couldn't use such a mechanism to incorporate multiple rendering engines. (id Tech 2, the engine for Quake II, actually uses that).

Also, if you're interested, I had to implement ES on the iOS VR target of my port... might guve you some useful pointers :) 

GLES1 pretty much just requires using vertex arrays instead of glBegin. The rest is basically just omissions. It should be easy enough to update quakespasm to use this, but you'll probably want to handle batching properly to compensate for the batch-merging work desktop drivers do with small glbegin batches.

GLES2 requires glsl too, which is a little bit more messy, but also offers significant speedups.

GLES3 is a strict superset of GLES2, thankfully.

FTE's gl renderer dates back to when glsl was still new (and slower). as a result it still copes just fine with glsl on some times and not others (also, yay q3 shaders).
tbh the only significant difference is whether glsl is available or not. There's a few extra limitations from using GLES, but tbh those things should probably be avoided even on desktop GL, so its not a huge problem really.
Of course, this is assuming you're willing to have gl1.1 as a minimum requirement - this may mean you need to use a quake3 minidriver instead of an older one, so I don't personally see this as a serious issue, even for those old cards. 

If you need to develop on one, they are like 35$ dude. I have no idea on your linux ability, but it shouldn't take long to learn how to code on one. Seriously, the OS comes with gcc and g++, it's super easy to compile anything. 

If you need to develop on one, they are like 35$ dude. I have no idea on your linux ability, but it shouldn't take long to learn how to code on one. Seriously, the OS comes with gcc and g++, it's super easy to compile anything. 

 

All developers have their own interests and own things they are interested in contributing to a free project.

ericw may or may not be interested in this task.

It sounded like he was inviting someone else to step up the plate and pursue this item of interest.

Everyone likes to armchair manage what someone else "needs to do", but really free projects depend on new volunteers.

/One opinion, my opinions are often wrong. 

and I really have no idea how to bloody use it. I'm sure if I struggle hard enough I could offer up some testing... 

Seriously, the OS comes with gcc and g++, it's super easy to compile anything.

Yeah, type "make" and you can compile anything.

Riiiiight.

Let's get serious. Compiling stuff is the single most basic part of the build process. It's expected to be easy and it's expected to work. So the part of the toolchain that's supposed to be easy is easy? Big swinging mickey. Gimme decent debug tools and we can start talking. 

I wish compiling on OS X was easy. My other poject is a pita on El Capitan which i'll have to solve some time soon. They symlink gcc to freaking clang! and have separated the command line tools from Xcode in some mess i have to resolve. Mebee it's not too hard. 

Xcode is good. Xcode is your friend. Accept the Xcode. Let it flow through you.</spooky> 

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.