Make another standard!

Play them from Qc... 

Yeah it's annoying, I always felt you should be able to use "cd play 4" in quakesapsm and have the track04.ogg play.

But, as ijed says, the right way for a mod to do it is with qc; this should work in DP and QS:

WriteByte (MSG_ALL, SVC_CDTRACK);
WriteByte (MSG_ALL, 2); // 2 is track number
WriteByte (MSG_ALL, 2); // 2 is track number

courtesy of Baker. http://forums.inside3d.com/viewtopic.php?f=2&t=4552&p=41367&hilit=svc_cdtrack#p41367

There's some useful info on how different engines handle soundtracks here: http://neogeographica.com/site/pages/guides/soundtrack_solutions.html

In short, both QS and DP handle music in the form: moddirectory/music/track02.ogg 

"cd play" doesn't save to a savegame file.

So if you use cd tracks for "mood music" and use "cd play", saving the game and reloading it you will notice it didn't preserve. 

If you start recording a demo AFTER a "cd play" and you play it back, it didn't happen.

In both cases using the SVC_CDTRACK does preserve.

Some QC ace here could easily write a bit of QuakeC to expose the correct method within a map. 

no. svc_cdtrack is not preserved in demos. I just checked markv. not preserved.
saved games are server-side. the server doesn't have a clue what the last svc was, and certainly doesn't have a way to update it without potentially bugging out mods.
even if it was saved/recorded, it would still be rewound.
also, sock did seem to explicitly say 'cd play' and not 'cd loop' - and svc_cdtrack doesn't support playing without looping, in which case cutting it short is probably the better choice over rewinding to start and then forcing it to inexplicably loop anyway. 

Even if every engine implemented emulation of the cd audio the same way, it wouldn't be a music system that can be counted on robustly in gameplay/gamecode at all. Trying to use in-world sound entities has even worse limitations.

It'd be nice to be able to just include a .dll in with a quake mod that adds its own locally contained SVCs and builtins. The issue of netcode being rendered permanently incompatible would go away, because id1 would still work like id1 and you have to run Quake with the same mod as other people joining your game or playing back your demo anyway. Then every tin-pot quake modder can gleefully create their own utterly incompatible music systems and particle systems and whatever else without everything immediately reverting to the usual argument about how it doesn't comply with the standards that nobody's upholding. 

It's possible to use a "nosave" variable to detect when a saved game has been loaded, and thus restore things after a save is loaded. No reason why you couldn't code your CD system into that. Of course, playing CDs always start the track over, but I doubt anyone was expecting the CD method to provide anything but a loop. 

Its fine, I have a QC solution already with background tracks and additional ambient stuff triggered on events. The downside is when the console is dropped, QC stops. I was wondering about the idea of looped background ambient tracks and found the console commands were different. Nothing to worry about, doing the QC route. 

 

nt 

@Lunaran, it is a compiler option that can be useful for checking if a map has just loaded. Check the client.qc in the code I sent you a while ago. There is a good example in the playerprethink, playerpostthink functions. 

That's terrific.

https://www.google.com/search?q=qcc+nosave

How does stuff like this get added to literally all new qcc compilers without being documented or written down anywhere? 

So, I recently gave in and bought a Macbook Pro, and like any sane person would do, I have installed Quake on it. However, when I try and run Quakespasm, I just get an error with a load of garbage I don't understand.

Here's the crash log for anyone willing to check it out: http://pastebin.com/En6Tw6Fx


Mini rant:
Seriously, this whole Mac thing feels like it was a big mistake. I feel like less software works than either Windows or Linux Mint, and the default behaviour of some parts of the UI is just baffling. Maybe I'll understand the Mac way soon enough, or maybe I'll just figure out how to get Windows 7 installed first. The hardware is nice at least :)

Keyboard layout is driving me crazy too. Non-US layouts seem to have caps lock in an insane position (the Japanese one does at least). Keyboard also seems way laggier and has shorter/no input buffer compared to Windows, or perhaps that's just my imagination. 

grab a latte moccachino soy dry and sit on your fixie before trying again.

maybe SDL needs to be installed? 

It looks like you do have SDL (as part of the QuakeSpasm app) but the crash is happening during an SDL call.

I'm not super-optimistic about this helping, but one thing you could try is downloading the latest SDL 1.2.x for OS X from https://www.libsdl.org/download-1.2.php ... looks like the current version is 1.2.15, and the one you have in the QuakeSpasm app is 1.2.14. Then open up the QuakeSpasm app and replace the SDL files (at /Applications/Quake/QuakeSpasm.app/Contents/Frameworks/SDL.framework/Versions/A/SDL ).

However it seems like there may be more going on there that would require QuakeSpasm changes to adapt to. This thread on the OS X version of Mark of the Ninja seems to be dealing with the same sort of crash, and has some developer comments: http://forums.kleientertainment.com/topic/29135-crashes-on-start-11-macbook-air/

Also ioquake3: ioquake3: http://www.ioquake.org/forums/viewtopic.php?f=12&t=1928

Also this (and so forth and so on): https://www.frictionalgames.com/forum/thread-24729.html

Googling about OS X Mavericks crashes in interpolate_table (or when calling SDL_GetGammaRamp / SDL_SetGammaRamp) should turn up more stuff, maybe there are specifics in there about what the exact issue is but I haven't seen that yet & have to leave for work now. :-) 

Thanks for the info.

I tried replacing SDL, but to no avail. I guess I'll have to wait for a fix :( 

Do you have a copy of SDL.framework installed in /Library/Frameworks ? If so, try deleting it or moving it aside, this fixes the crash for me.

Otherwise, I can post a beta build that uses SDL2 and doesn't have this issue! 

OSX 10.9 

http://www.quaketastic.com/files/tools/mac/engines/quakespasm-0.85.10-sdl2-alpha.zip 

the sdl2 alpha fixes it. Thanks! 

Hmmm.. Tried out QS 0.85.9 (12 April 2013) and it works ok on my 10.9.2 box. I dont have 10.9.3

But Oz's latest dev version doesnt work on Lion or OS X 10.9.2 *without system SDL*. It seems to have a malformed dynamic lib path - the @rpath doesnt look familiar to me, and should probably be @executable_path

Dyld Error Message:
Library not loaded: @rpath/SDL.framework/Versions/A/SDL
Referenced from: /Users/USER/*/QuakeSpasm.app/Contents/MacOS/QuakeSpasm
Reason: image not found

Of course, the reported crash above has a different log. I dont have OS X 10.9.3 to test with 

Starts ok on Lion and Mavericks. :) FPS on demo1 is similar ro SDL 1.

But god-damn it , i still have the fullscreen gamma bug on both. What a crock &^% 

@than, cool, glad it works for you!

@stevenaaus, what's the fullscreen gamma bug you get? The brightness slider wasn't working for me for a while, but I found out it was my screen dimming software (f.lux) - I just have to quit that and then the brightness slider works correctly.

The brightness control in SDL kind of sucks, it affects the whole monitor in windowed mode and clashes with things like f.lux. From what I've read the proper way, if recent OpenGL is available, is to use a FBO + fragment shader, but not sure how much work it would be. 

Mark V uses a rather simple mechanism to handle brightness that only affects the window and is entirely crossplatform.

http://quake-1.com/docs/scr_brightness.txt

Called once per frame right before GL_EndRendering ();

No more hardware gamma and all the hassles/complexities.

MH wrote the code and Reckless saved it and pointed it out to me a little over a year ago. 

brightness is additive, contrast is multiplicative, gamma is exponential.

the code you (baker) linked is contrast, not brightness as you claim, nor gamma as the code appears to claim. these things all have quite specific definitions. :s

both contrast and brightness can easily be rendered using the appropriate combiners stuff (potentially requiring multiple passes). actual gamma requires glsl or hardware gamma ramps.

all this stuff will have the effect of slowing down the game.
its worth spending the time to add support for fragment shaders, if only to also fix the uglyness of water and skies...