Something that's always bothered me: hide the crosshair while centerprint text is on screen. Otherwise it just looks awful with the big + jammed in the middle of a word.

I've tried doing this in qc with stuffcmd, and it works okay, except there's no way to remember what the user's original crosshair preference was if the map loads or the player f9's while text is on screen. I default to just assuming everyone wants it on, but I know someone's going to come out of the woodwork and complain if I do that.

It's a tiny bit of polish that should just always happen, and the proper place for it is at the engine level. 

Don't draw crosshair if centerprint code.

http://forums.inside3d.com/viewtopic.php?f=12&t=5474 

Spike pointed out some mods actually strategically display console text as a status indicator.

Like Quoth's flashlight indicator bar (example map = Ruined Nation) 

Add CSQC support to Quakespasm. 

http://uhexen2.sourceforge.net/tmp/QuakeSpasm-0.85.10-macosx-TEST3.zip

This is built against and packaged with today's SDL-1.2:
http://uhexen2.sourceforge.net/tmp/SDL.framework-1.2-HG-20140623.tar.gz

And here is a test build of hexen2 along with it:
http://uhexen2.sourceforge.net/tmp/hexen2demo_aug1997-macosx-TEST3.zip 

Sounds reasonable to move centerprints up 4 lines if crosshair ?? 

You probably want to head down in case the text is long... 

Guys, please, could you add the FSAA (Antialiasing) option to the OS X version ?

and also the command-Tab feature (as in Quake3) to switch app, without having to quit Quakespasm. 

Hmmm - some messages shown with SCR_DrawNotifyString are just too big to mess with positionally. But simple cases such as E1 entryway (SCR_DrawCenterString) have been moved up one line for the crosshair

@Barnak Where is the relevant command-Tab code ? Maybe i'll go look for it.

OS X FSAA has been talked about somewhere else. Maybe SDL2 with OS X makes a simple implementation possible. 

Mark V has anti-aliasing (cvar = vid_multisample, set to 2, 4 or 8) --- if you are staring at edges you can tell the difference. But who is doing that during regular game play?

I'm not arguing for or against such a feature, just saying I haven't seen anyone even comment on the availability of the feature and I forgot it myself. 

Since quake doesn't use much resources, I play it in the native resolution of my monitor, and aliasing is not such a big problem. I'm sure it looks better with, but aliasing in quake hasn't really bothered me since winquake at 320x200. 

Anyone know how to make the engine look like this? shown here 

 

 

I had it figured out. 

There are a lot of commands useful for testing maps that you can bind to a key in your autoexec.cfg file.

Examples:

bind "m" "r_lightmap"
bind "f" "r_fullbright"
bind "g" "notarget"
bind "c" "noclip"

When you don't add a value, then it will toggle. Hit the key once and it turns it on, hit it again and it's off. Quick and easy. 

some of those you need to add the word "toggle" in there (the ones that are cvars and not commands) 

I thought that was correct because copied those right out of my autoexec file. I just now thought to check and for some reason I also had the correct commands in my config.cfg, which is why it was working.

bind "m" "toggle r_lightmap"
bind "f" "toggle r_fullbright"

Not sure why I had them mixed up like that, probably from experimenting when I was first trying to get it to work. 

 

I set up a Jenkins server that automatically creates win32 builds from Quakespasm SVN:
http://quakespasm.ericwa.com/job/quakespasm/

Assuming this works, it should be the best way to help test QS development. Jenkins should automatically do a new build whenever someone commits a change in SVN (within an hour). There's even an RSS feed that should notify you when a new build is available.

The current build there, r935, has things like bsp2, non-power-of-two textures, part of mh's dynamic light speedup, shifting messages when the crosshair is present, new default keybindings in quakespasm.pak (WASD, mousewheel weapon switching, mouselook on).

Note that I have some patches which haven't been accepted into quakespasm SVN; for example, SDL2 support, improved audio resampler, some loading and rendering speedups. These aren't in the above build, but I'm planning to set up another project in Jenkins to build with these not-yet-accepted patches so you can test them too, if you're interested.

Also, making this produce OS X builds is on my todo list. 

Thanks for your efforts eric, AND all you other guys! 

looking forward to the sdl2 stuff, since the secret sdl2 haxx0r build I was given is the only one that runs on my mac. Everything "just works" on my windows box ;) 

if anyone's bored, i'd love help testing this build! http://quakespasm.ericwa.com/job/quakespasm-ericwa/lastSuccessfulBuild/artifact/quakespasm-recf89c033cb2aa771388a92e76be36062d1df81f.zip

does it sound good?

leave "-sndspeed" at the default of 11025; it will actually output at 44100 but it does the filtering to 11025 internally. Mostly I'm interested in whether I have the filter set up right - is sound too soft/muffled, or just right? It is a bit less harsh sounding that windows' resampler, but I can tweak it.

the point of this is, if you use music, it will be mixed in at full quality (44100) :) 

I tried it on Win7. Seems like it's working to me:

I compared the test build to v0.85.9, either using "-sndspeed 44100" or not, loading directly into DM4 to hear the Quake theme music.

The test build's music was the same quality as the sndspeed 44100 music for 0.85.9, regardless of whether I specified sndspeed for the test build.

sndspeed did affect other sound effects on the test build. 

If there are nuances of the test build's sound I'll probably miss them, but I'll keep using it for a while to see if anything else occurs to me. :-)