gamma adjustment doesnt work (nothing happens at all when you change its value) in r1034 (x32 binary) on win 8.1 x65 nvidia gtx 560 @ 340.52 driver. 

It's reasonably normal with lower polycounts to get the same, or even a slightly lower, framerate. What's important to realise is that VBOs (and batching) are an optimization for high polycounts. In general you want any optimization to have benefit in that area. Don't sweat the id1 maps; if you see an increase in the big maps then it's doing it's job.

I suggest a move to regular vertex arrays in system memory for MDLs. That will work with any GL 1.1 or better driver (so you don't even need to special-case it) and being able to take each MDL in a single draw call will be of significant benefit. Where you need to multipass you'll also get benefit as you'll only need to do the vertex setup once.

With MDLs and frame interpolation you can't really use VBOs unless you also have vertex shaders (or GL_ARB_vertex_blend which virtually no driver supports) but old-style vertex arrays will work nice.

Be careful that the current colour is undefined after using glColorPointer so you need an explicit glColor3f/4f call for the next immediate mode stuff you're drawing. 

in telefragged, shortly after collecting the gold key, i experience a 'stack overflow.' what do i do?!?!

P4 3.4 GHz, 3 GB RAM, Nvidia GT240, vista, quake injector using the required quakespasm engine (quakespasm svn r980), console screenshot, if it works:
https://drive.google.com/file/d/0BwH0NjAbvI9vTzFDSmZzN0FkMUU/edit?usp=sharing 

Excessive happens at that time, so it is probably just memory overflow. How much ram have you got? 

that has nothing to do with ram, that's a QC stack overflow.
looks some trigger (trigger once/multiple/secret) triggering itself without any delay (presumably via other similar triggers).
essentually an infinite loop. 

New prerelease builds uploaded at http://quakespasm.sf.net/devel/

win32:
http://quakespasm.sf.net/devel/quakespasm-0.90.0-r1036_windows.zip

win64:
http://quakespasm.sf.net/devel/quakespasm-0.90.0-r1036_win64.zip

macosx:
http://quakespasm.sf.net/devel/QuakeSpasm-0.90.0-macosx-r1036.zip

macosx (SDL2 version):
http://quakespasm.sf.net/devel/QuakeSpasm-0.90.0-macosx-r1036-SDL2.zip

source:
http://quakespasm.sf.net/devel/quakespasm-0.90.0-r1036.tar.gz

Linux users can build from the source for themselves.


Changes since the previous r1032 test builds from Sep. 15 include:

* Revised VBO code.
* Version bumped to 0.90.0.

For more detailed list of changes see the README file, or browse the
svn history. 

3GB RAM
command line parameters: -width 1280 -height 720 -bpp 32 -winmem 1024 -heapsize 655360
i'll try the 0.90-r1036 build of the engine.

thanks for the help and info. i meant to post this on the Rubicon Rumble Pack thread. should i repost this over there? 

i used noclip to go over the floor to the gold door without triggering the stairs to continue. 

The Quakespasm.txt compilation instructions say you can enable home directory support on Linux with the homedir_0.patch. However, a recent change turned this into a Makefile option. The current way to enable the feature can be found here.

http://sourceforge.net/p/quakespasm/code/1013/

You should update Quakespasm.txt section 4.1 to include this information. It is in the Changes section already, but some people might read 4.1 first and wonder where the patch file has gone. 

Thanks. Updated documents as of r1037:
http://sourceforge.net/p/quakespasm/code/1037/ 

I must have done something bad in the qc, but never saw the issue myself or from testers. I did see a similar one, but it was just a broken relay as spike says. 

i'm just a grateful fan of the masters who keep quake alive. thank you. 

I noticed a cosmetic visual glitch while playing the Rubicon Rumble Pack's map by Hrimfaxi. In a certain location a lift is not visible from outside a room.

If you are careful, you can catch it a couple of seconds after the timestamp into the VOD by Daz. The lift support pillar is invisible for a small while when he first runs up the steps toward the lift room.

http://www.twitch.tv/tddaz/c/5131707?t=51m10s

I have a save game at this location and a short demo that showcases the glitch. Before packing them up and submitting a bug report, I thought to ask whether this is already a known issue. Should I upload more details for people to look over carefully?

It could be a vis problem instead of an engine issue. It doesn't have any effect on gameplay. The room just looks strange if you happen to backtrack and notice it. 

and was very disappointed to find that it no longer works with my way of launching a mod.

I place my mod files in C:\Quake\Addon\RPP (using Rubicon Rumble Pack as an example), and launch it via a commandline like:
Quakespasm.exe -game addon/rpp

It has worked well for me, as this keeps C:\quake folder tidy without too many mod folders to clutter it.

But it seems that since a few versions back, Quakespasm has introduced some mechanism to prevent using a path as an command line parameter.

Can any one revert its behavior back? Thanks.

Also, is it possible to introduce the capability of using multiple "-game" parameters? In that way, I may even place such folders as quoth into C:\quake\addon, reducing the clutter further. 

I confirm the visual glitch. I noticed before that sometimes, a part could be invisible, then be rendered when the player is close enough.

I firstly noticed this rendering problem on a Cecerello map (jam2). 

Thanks for the report.. I can reproduce it. It's the MAX_ENT_LEAFS limit. I just put in a fix to quakespasm as discussed in this i3d thread: http://forums.inside3d.com/viewtopic.php?f=1&t=5554 

Does the Mac version have multisample? If so, how do I enable it? 

Does the Mac version have multisample? If so, how do I enable it?

-fsaa x (x == 0, 2, 4, 8) 

I had tried that. It doesn't work :(

2011 Macbook Pro running Mavericks - ATI Radeon 6490M

I have GL_ARB_multisample in the list of extensions available. 

I had tried that. It doesn't work :(
2011 Macbook Pro running Mavericks - ATI Radeon 6490M
I have GL_ARB_multisample in the list of extensions available.

Might be an SDL issue. Does the SDL2 version behave the same for you?
(See the latest builds at http://quakespasm.sf.net/devel/?C=M;O=D ) 

I was using the SDL 2 build, 1068. 

I was using the SDL 2 build, 1068.

The latest is 1071, but it won't make a difference wrt FSAA.

FWIW, my situation is similar, both with SDL1.2 and SDL2: It reports that the multisample window creation succeeded but the jaggies are there, so no fsaa for me either.

Eric? Kristian? 

-fsaa works on both SDL and SDL2 builds work on both of my macs (2009 macbook w/ nvidia 9400m, 2012 retina MBP w/ nvidia 650gt).

Try with "-bpp 32" - according to this post, "FSAA only works with a 24 Bit depth buffer on ATI cards" http://www.gamedev.net/topic/382035-sdl-and-multisampling-aa-does-not-work/#entry3526799

What does the "video mode (...) initialized" line in the console look like? 

Adding -bpp 32 didn't work ("-bpp 32 -fsaa 8"). Still have the jaggies. I use E1M1 as the test map.

I don't have a "video mode" line in the console when I scroll up. 

Ok, thanks for trying that.

Hm, really no "video mode" line? the top of the console should look like:

UDP Initialized
Exe: 21:43:21 Sep 28 2014
250.0 megabyte heap
Video mode 1920x1080x32 (24-bit z-buffer, 0x FSAA) initialized
FOUND: ARB_vertex_buffer_object
FOUND: ARB_multitexture
GL_MAX_TEXTURE_UNITS: 8
...

It should also print it if you do vid_restart. I'm just wondering what the "(24-bit z-buffer, 0x FSAA)" part is for you. I guess we'll have to put in more debugging logging, though it seems like an sdl bug atm.