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. 

Two ideas, see if you can run vkquake, it's a Vulkan port of Quakespasm. I was able to install it on ubuntu 18.10 with "snap install --edge vkquake" but my drivers didn't support it.

Another option, if you launch quakespasm with the "-noglsl" command line option it reverts to fixed-function OpenGL 1.x. This will be slower but may be less likely to trigger driver bugs. 

I'll look into both of those options as a possible interim solution. However, I would love to solve the underlying issue, if at all possible. Is it safe to assume that it's an Intel graphics driver problem?

I've also experienced seemingly random freezes when not playing Quake, but just e.g. reading something online, looking through pictures on my machine or working on a document in LibreOffice. And on one of the previous Ubuntu 18.04-based distros I tried out (as I wrote, I went through three of those in an attempt to solve -- or sidestep -- the issue), ioquake3 would also randomly crash. I haven't tested ioquake3 on this latest OS yet.

But the most consistent problems have been with Quakespasm. Just to be clear again, I'm not blaming the programme (as I said, it worked perfectly on my old OS), but I thought the particular issues I'm having might be something that you or someone else here would recognise and be able to say "ah, yes, that's because of an issue with X; you need to do Y". 

I guess I clicked it by accident. 

If this happens outside of QS it's definitely either driver or HW problem. Intel drivers are typically pretty solid so if updating[1] to latest doesn't help, start saving for a new machine (if this is a laptop).

[1] Pretty good guide:

https://ubuntuforums.org/showthread.php?t=2072420

Also install mesa-utils (sudo apt install mesa-utils) if your GPU/driver doesn't report its name properly 

Also install mesa-utils (sudo apt install mesa-utils) if your GPU/driver doesn't report its name properly

I already have mesa-utils 8.4.0-1, and as far as I can tell, the system recognises the GPU correctly -- e.g. when I run sysinfo.

Thank you for the link; I might try and update to the latest driver if I can summon the courage (I'm scared of breaking things even more).

Another option, if you launch quakespasm with the "-noglsl" command line option it reverts to fixed-function OpenGL 1.x. This will be slower but may be less likely to trigger driver bugs.

Thanks. I've tried this a few times now and so far, so good -- except that the audio kind of ... I don't know if "stutters" is the right word. Every now and again it sort of misses a beat, as if the system is under strain. I think this happened before too, but the visual glitches were much more obvious, so I didn't really focus on the audio. So far the game hasn't frozen or crashed ... yet.

start saving for a new machine

I hope it doesn't come to this.:(