(Seven's fixes still corrupted, I don't know why, here's a direct link from QuakeOne)

https://www.dropbox.com/s/j2zixlpqcpt5tjy/ROGUE%20fixes%20V1.11.rar 

Post your QuakeC questions in the following thread, which is a Quake help thread:

http://www.celephais.net/board/view_thread.php?id=60097

Your hipnotic buzzsaw issues have nothing to do with the Quakespasm engine. 

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.