You'd better listen to Baker this time if you don't want to piss people off. 

System, ubuntu 16.04, running latest quakespasm, quakespasm executable (does not occur in quakespasm-sdl2) lauched from terminal without any parameters.

Replicating the bug:

Upon load of the game, new game is selected. *Just* before the console retreats all the way to the top the tilde key is pressed and the console comes down again.

Here is where the bug occurs, the console, instead of staying down, goes back up. Now every time the console button is hit, the console will drop, then return back to the top.

This also affects other keys, if you then hit escape and go to "new game", when you're prompted "Are you sure you want to start a new game", the game will accept no input.

Alt-Enter is locked, so I can't quit the game, Escape is locked so I can't return to the menu. All I can do is change terminals (ctrl-alt-F1) and kill quakespasm. 

I reposted it to the bug tracker, hope you don't mind: https://sourceforge.net/p/quakespasm/bugs/17/

I have seen it before and IIRC it was SDL1.2 sending invalid key presses, but it would be good if QS behaved better if possible instead of locking up.
Good that SDL2 is working properly though, that was my experience as well. 

I've been using the 1.2 up until this point in time because for some reason my system (or quakespasm) wanted 32 bit SDL, vorbis and mad libs.

I didn't have them installed because I've been trying to avoid system bloat. I've installed them now though. Fingers crossed it won't break any of my other games :) 

weird, I'm having trouble reproducing it at the moment. The last time I saw the bug was a year ago or so, but I don't run QS on linux very often, just when testing releases really. I am also on Ubuntu 16.04 with all updates applied, and using the unity desktop.

Just to double check the SDL version you have, mind running this?
dpkg -s libsdl1.2-debian | grep Version 

The command you supplied tells me its not installed, the version I have installed is 1.2.15+dfsg1-3 according to synaptic.

I just looked up what dfsg meant, apparently its debian free software guidelines. Now I wonder if the dfsg version is behind the non-dfsg version. 

I'd just like to make the following correction. Over a month ago , post #2571, I reported a problem with Quakespasm and the latest Nvidia drivers cause an ungodly texture blurring scenario, and I was curious as to why nobody else was experiencing the same issue.

As it turns out it was my fault. I did a complete uninstall/install of Nvidia's latest Windows 7 drivers, totally clean. The problem was gone, so I can only conclude it was a certain graphic setting I had used within Nvidia's control panel, but which one it was I don't know. Or it may have been something else entirely.

But either way nothing is wrong with Quakespasm, nothing (as far as graphics are concerned) needs fixing, and I apologize if I caused any time wasted trying to figure out a problem that was never there. 

Is the culprit responsible for Quakespasm's blurry texture scenario when using the latest Nvidia drivers. Avoid using that setting. 

OK, when minimised, Quakespasm's CPU usage shoots right up to use over 20% of my CPU, and my fan kicks in to overdrive (happens the same whether I'm in fullscreen, then alt-tab to windows - or in windowed mode, then I minimise the window).

I'm using the SDL2 version. 

I implemented a lightmap format change that may help the AD start map performance on your Intel graphics system:

1. unmodified svn r1371
2. new lightmap format (GL_BGRA GL_UNSIGNED_INT_8_8_8_8_REV)

I wonder if you could test these two buildson your system and report what FPS range you get in ad1.5's start map for each build.

link to source code 

I can't measure any difference between those builds on:
-Intel HD Graphics 4400 (2013? laptop)
-Intel 855GM (2004 laptop) 

Back a few years, I tried that modification. Tried the binary on several machines, couldn't locate one where it made a difference (Intel, GeForce, Radeon, etc.)

I believe such machines do exist, but I just didn't have any of them. 

Baker, yeah.. MH mentioned in the insideqc thread:

This is only really important for Intels that have hardware T&L - say, the 965 onwards; it seems as though earlier generations are more tolerant.

I guess my old intel is the more tolerant earlier generation.. and my newer 4400 came out several years after that thread, so apparently Intel fixed the perf issue by that time. 

Yeah, I haven't tested this in a long time but I don't believe it's an issue any more either. GL_RGB should still be an issue, but GL_RGBA should be fine. 

Just for reference, I've tested these builds on a more recent Intel 520 machine without measuring any difference either. This supports my guess that with DX10+ class hardware (where Microsoft forced the vendors to standardise on RGBA) it no longer matters.

A more interesting benchmark would be gl_flashblend 1 versus gl_flashblend 0. That would really help determine if it's dynamic light uploads. 

Thanks. For reference, build #1 I posted above (and QS releases) are using GL_RGBA / GL_UNSIGNED_BYTE.

--
Question for Shamblernaut:
Can you still reproduce the console retraction bug with sdl1.2? I just tried again and can't trigger it (though I remember seeing it like 1-2 years ago).
I tried in the default ubuntu 16.04 Unity desktop as well as the "ubuntu flashback (metacity)" one. Tried both windowed and fullscreen. 

This time on an Intel HD2000, which is closr in performance to @QuakePone's, but still no measurable difference. 

You can disregard my question, managed to reproduce the console retracting bug 

That's what I get for skim reading.

As an aside, is there any particular reason for console commands being case sensitive? I understand that filenames require it, especially in *nix based systems. Is this just a legacy code thing or are some commands actually case sensitive? 

in certain cases, yes, especially if you're exposing them to qc.
there's no good reason for case-sensitive tab completion though. 

I did test ad_start first by doing nothing and then b-hopping around until I catched those frame drops in each version. The more I tested the less times I encountered them and I usually got different results every time I restarted the map in 92.1 before this.

FPS go around 27 but in 92.1 I sometimes got the framedrops during late tests. It's very unconsistent.

You can't really take my word here, I am very confused about all of this and in the end I will probably need an engine that takes more advantage of unused GPU power. Sorry, I can't be of much help here. 

Ok, thanks for checking anyway. It sounds like the GL_UNSIGNED_INT_8_8_8_8_REV thing is no longer an issue.

My laptop with Intel HD 4400 is faster, but QS doesn't exactly fly on content like AD; some time I will have to look more closely at whether I get the same speed increase when switching to MarkV DX9. 

This isn't something I've sat down and analyzed. I'm just making general observations here.

Even with the fastest lightmap updates in the world, you'll still bottleneck on lightmap updates. In RMQ we had a scene with 20+ flickering candles; every lightmap in the scene would get updated and it would pull the NV 280 (I think) machine I was using at the time down to 20 fps.

GPU lightmaps are the future. Dynamics still have a cost but lightstyles are completely free.

FitzQuake's brush model renderer sucks. If you were to be actively malicious and deliberately set out to write a bad brush model renderer you might do worse but I doubt it. Ideally brush models should go through the same renderer as the world. A map with lots of brush models is always going to run slow.

FitzQuake's sky renderer sucks. If you were to be actively malicious and deliberately set out to write a bad sky renderer you might do worse but I doubt it. I had one of those "sweet baby Jesus" moments when I analyzed a scene in PIX and saw that 80% of the time was spent drawing sky. Any scene with sky in it is going to bog down on slower hardware.

What both of those have in common is per-polygon state changes. In the absence of batching in your own code the driver will make reasonable efforts to batch itself, but state changes will break that.

There are certain items of "Quake lore", such as Quake can't do big scenes, sky is slow, disable multitexturing, and so on. They're not true. The problem is in the implementation, and they can all be solved. 

In Quakespasm, the brush models are drawn with the world, if I recall.

As a general note, since I don't know if you are aware of this -- Arcane Dimensions is a bit less optimal than some other single releases in a couple of departments:

1) First, it uses sprites as particles. So each little floaty pixel is an entity. You can turn this off by doing "temp1 0" and restarting a map, if I recall.

2) Second, you know static entities like torches? Arcane Dimensions doesn't do torches as static entities. And Arcane Dimensions uses a lots of torches.

I haven't checked, but combined with the fact that Arcane Dimensions maps tend to have tons of details and complex geometry and generally the maps tend to have at 200-300 monsters and super-tons of items/books/etc ...

It's a bigger load than most maps tend to be.

And because of the torches and particles, I suspect puts more pressure on the QuakeC interpreter too.

The end result is very cool and creative.

Also: I have never checked, but in complicated maps with huge entity counts -- how much is vis helping? Engines with r_lockvis you might not be able to tell ...

(If I "r_lockpvs 1" in Mark V, then no clip outside the start map it looks like this ...)

http://quakeone.com/markv/media/start_map_r_lockpvs.png

Now, mh, look at this ...

On ad_mountain ...

I type "r_lockpvs 1" and noclip outside map ....

http://quakeone.com/markv/media/ad_mountain_r_lockpvs.png <--- RED ALERT!!!

So ... whatever is going on ... vis is doing a very poor job ...

Imagine how many entities are drawn per frame with vis doing that? 500? 1000? I don't know, but frustum culling cuts some of that down.

So I wouldn't approach this this that the maps are optimal and the mod are optimal from a performance standpoint and the Quake tool are doing a good job.

Arcane Dimensions is a great experience, but there is plenty of room for performance. 

2nd opinion on "r_lockpvs 1" using DirectQ, just to make sure.

http://quakeone.com/markv/media/ad_mountain_r_lockpvs_directq.png

And let's throw ARWOP Roman1 into the mix which isn't Arcane Dimensions ....

http://quakeone.com/markv/media/arwop_roman1_r_lockpvs.png

^^^ With vis generating results like the above, well --- let's just say the wide open outdoors map thing sure doesn't vis very well.