Hey, I'm having some pretty nasty audio stuttering issues on 0.93.1 on GNU/Linux. I've tried compiling from source with and without SDL2, as well as the amd64 builds on SF, but they all have the same problem. Game runs fine otherwise. I'm on Gentoo. Any ideas?

Command line: quakespasm
Found SDL version 2.0.8
Detected 8 CPUs.
Quake 1.09 (c) id Software
GLQuake 1.00 (c) id Software
FitzQuake 0.85 (c) John Fitzgibbons
FitzQuake SDL port (c) SleepwalkR, Baker
QuakeSpasm 0.93.1 (c) Ozkan Sezer, Eric Wasylishen & others
Host_Init
Playing registered version.
Console initialized.
UDP_Init: gethostbyname failed (Unknown host)
UDP Initialized
Server using protocol 666 (FitzQuake)
Exe: 13:41:52 Dec 14 2018
256.0 megabyte heap
Video mode 1920x1080x24 60Hz (24-bit z-buffer, 0x FSAA) initialized
GL_VENDOR: nouveau
GL_RENDERER: NV117
GL_VERSION: 3.1 Mesa 18.2.5
FOUND: ARB_vertex_buffer_object
FOUND: ARB_multitexture
GL_MAX_TEXTURE_UNITS: 8
FOUND: ARB_texture_env_combine
FOUND: ARB_texture_env_add
FOUND: SDL_GL_SetSwapInterval
FOUND: EXT_texture_filter_anisotropic
FOUND: ARB_texture_non_power_of_two
FOUND: GLSL

Sound Initialization
SDL audio spec : 44100 Hz, 1024 samples, 2 channels
SDL audio driver: alsa - HDA Intel PCH, ALC3239 Analog, 65536 bytes buffer
Audio: 16 bit, stereo, 44100 Hz
CDAudio disabled at compile time

========= Quake Initialized =========

execing quake.rc
execing default.cfg
execing config.cfg
couldn't exec autoexec.cfg
3 demo(s) in loop
Shutting down SDL sound 

Any luck with increasing the MAX_GLTEXTURES limit? Not sure if anyone's looked yet or if it is pretty embedded. 

Alright, explicitly specifying a 'buffer_size' in my /etc/asound.conf seems to have fixed my audio issues. 

MAX_GLTEXTURES is just a define, but I find it difficult to believe that you're genuinely using over 4000 textures. There must be a problem somewhere else with your content that's falsely triggering this. 

It's in my asset-library/feature-test map. Is it a memory limit on level load? Because if I add more unique stuff, it exits to console on map load. Not sure if there is a workaround where I could reference .mdl's or .spr files with text but only load them when the player enters the room and unload them when exiting...I'd prefer not to use killtarget but that might be my only reliable option to limit the textures loaded in memory. Or am I misunderstanding how that define is used? 

This I guess depends on your content.

Each .spr frame is a unique texture.
Each .mdl skin is a unique texture.

With, I guess, some extreme cases, it probably is possible to overflow a 4k texture limit; say if you have some sprites with 256 frames each - 16 of those would overflow.

So I suppose you'll need to talk a little bit more about what kind of content you have, because 256-frame sprites seems a pretty extreme example. 

I have a hall of effects with about a hundred looping sprites to show what kind of effects are possible, a hall of items, hall of enemies, etc. I have no doubt that I'm using every bit of 3999 textures at the moment. If I add one more sprite or one more model it gives me that error. Some sprites have frames up into the 90's, can't recall if any are close to 256.

Do textures repeat...e.g if I have two different types of ogre models but the skin is the exact same on each does ot still count as 2? (I assume yes)

I may have to settle for scrapping my hall of effects :( 

Oh also, do textures loaded from the bsp count too? 

image loaded from a file is a separate texture even if the pixels are the same. So your two ogre skins would be counted as 2. 

P.S. if you want a list of those 3999 images, type the "imagelist" command in the console. The names listed should give an indicator of the source of each image. 

Hi, community!
Im used QS 0.93/0.93,1 x64 on my HP laptop with win 7 x64 pro.
After shifting to Win 10 x64 pro I encountering a permanent problem with my mouse: plugged into USB 2.0 port it turns off after one-two min. running QS (LED still lighting, but not moving cursor, after exit QS to desktop - still not works): plugged into USB 3.0 port - mouse moved with freeses and delayes.
Reading this thread shows, that problem encountering many people, and bug rather in sdl2.dll
Im try any QS builds: x86, x64, sdl12 and sdl2 based, but problem still remains.
When Im trying QSS 093.1 , with included sdl2.dll (v.2.0.9) mouse turns off after about 30 min of running Quake. Current version of QS 0.93,1 with sdl2.dll (v.2.0.9) has no sound.
How to resolve problem with it?
My config:
Laptop HP Win 10 x64 pro 1809 (up to date)
core i5 3340m
16gb ddr3 1600
Radeon HD7570 1gb ddr5
Intel USB controller 3.0/2.0
mouse logitech b100
All that works on win 7 x64 pro before. 

Hi, community!
Im used QS 0.93/0.93,1 x64 on my HP laptop with win 7 x64 pro.
After shifting to Win 10 x64 pro I encountering a permanent problem with my mouse: plugged into USB 2.0 port it turns off after one-two min. running QS (LED still lighting, but not moving cursor, after exit QS to desktop - still not works): plugged into USB 3.0 port - mouse moved with freeses and delayes.
Reading this thread shows, that problem encountering many people, and bug rather in sdl2.dll
Im try any QS builds: x86, x64, sdl12 and sdl2 based, but problem still remains.
When Im trying QSS 093.1 , with included sdl2.dll (v.2.0.9) mouse turns off after about 30 min of running Quake. Current version of QS 0.93,1 with sdl2.dll (v.2.0.9) has no sound.
How to resolve problem with it?
My config:
Laptop HP Win 10 x64 pro 1809 (up to date)
core i5 3340m
16gb ddr3 1600
Radeon HD7570 1gb ddr5
Intel USB controller 3.0/2.0
mouse logitech b100
All that works on win 7 x64 pro before. 

I made a quick patch to QS to make it use the unused flashing frames for the keys and powerups when you pick them up. I also added a flash for when powerups expire, which is hardcoded at 29 seconds. TODO: I should really consider that as a cvar or read it from the quakec field for mod purposes.

https://youtu.be/e661Xsy934o

Modified sbar.c is available at https://pastebin.com/Ev0eNp21, very few changes are marked with // c0burn 

2nd link is busted 

Take the comma off. 

that looks cool, though it might be nice if the icon flashes were synced to the screen flashes when power-ups expire. 

Two thoughts on getting the exit flashes to work:

In terms of how to automatically trigger the hud flashes on existing mods, could you expand on metlslime's suggestion, and make the trigger for a hud flash become "a screenflash occurs 27, 28 or 29 seconds after the icon was last turned on"? Don't know how tight you could afford to make the timing for it to work over the network. Maybe you just let the feature fail sometimes in that scenario because it's cosmetic.

Triggering the icons to flash on *any* screenflash would be too permissive, because all the icons would end up flashing when any powerup expires, even if some have a while still to go. That would be less useful than just not flashing the icons at all.

It does mean that mods can't vary powerup length and just expect the icon to flash when they flash the screen. So my second thought was how mods might request the feature - is it easy for QC to resend the message to turn on the icon? Turning the flag on and off again in the same frame won't work. If there's a reasonable way to repeat the message, flashing the icon each time that happens might work. If so, a cvar to opt out of the automatic flashes would be a good idea. 

can't vary powerup length
This includes picking up two of the same powerup within 30 secs.
It constantly flashing for up to 30 seconds would be really annoying. 

[Cross-posting from the general thread ; might have a better better chance of getting a response here:]

Anyone else using Ubuntu 18.04 or one of its derivatives (e.g. Mint 19.1) and getting bad performance and/or weird issues when running Quakespasm -- as in brush faces flickering in and out of existence, the game freezing for several seconds, or outright crashing with an error message that says "i965: Failed to submit batchbuffer: Input/output error"? I've tried three different distros now, all based on Ubuntu 18.04 and all with the same problem. This is on a machine with Intel integrated graphics, for what it's worth.

I've tried googling and searching around on Linux forums, with little success (perhaps because I know too little to even know what to search for). Thought maybe someone here might have run into the same issues and/or know what the solution is and/or be able to point me in the right direction...


PS: By posting this here, I don't mean to suggest that the problem is with Quakespasm. It's clearly something connected with my system; I just don't know what & was hoping someone here might know. The problems started with a recent OS upgrade. On the exact same computer running Linux Mint 17.1 (based on Ubuntu 14.04) I never had these problems (or any problems, as far as I can remember) when running Quakespasm. 

I run Quakespasm on elementary OS 5 which is based on Ubuntu 18.04. No issues here. But, I have an NVidia graphics card, so I expect that your problems are with the Intel graphics hardware and/or drivers. If you search back up the thread a bit you'll find other Intel-related issues. 

This looks like a driver issue. Quake code isn't very good at checking GPU capabilities so it's likely that you're hitting a hardware limit. Does this happen on every map or just some? 

If you search back up the thread a bit you'll find other Intel-related issues.

Thanks for the tip. I just did that, but couldn't find anything resembling the issues I'm having. :(

Does this happen on every map or just some?

Well, it sometimes happens and sometimes doesn't, but does not seem dependent on which maps I'm playing. Sometimes the weirdness is there from the start; other times things start off ok, but then the flickering I described above starts. And once it starts, it keeps happening across any and all maps I try to load, including the original id1 maps. Then it seems to be just a matter of time before the game freezes and/or crashes.

Before upgrading my OS I had no trouble playing anything apart from one or two of the maps in Ter Shibboleth -- and even then, it's just that the framerate was low; the game never crashed or behaved weirdly.