#780 posted by Joel B on 2014/06/20 16:32:42
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. :-)
Johnny
#781 posted by than on 2014/06/20 19:04:27
Thanks for the info.
I tried replacing SDL, but to no avail. I guess I'll have to wait for a fix :(
I Get This Too, It's Annoying
#782 posted by ericw on 2014/06/20 19:44:50
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!
Same Crash
#783 posted by Baker on 2014/06/20 19:48:34
OSX 10.9
Here's An Sdl2 Mac Build
#784 posted by ericw on 2014/06/20 22:02:14
Working!
#785 posted by than on 2014/06/21 07:47:26
the sdl2 alpha fixes it. Thanks!
SDL1 Crash
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
SDL 2 Beta
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 &^%
#788 posted by ericw on 2014/06/22 03:08:19
@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.
@ericw
#789 posted by Baker on 2014/06/22 03:30:29
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.
#790 posted by Spike on 2014/06/22 05:22:51
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...
Right When
#791 posted by ijed on 2014/06/22 05:57:55
I'm monkeying with this from QC :D
what's the fullscreen gamma bug you get?
When game runs in fullscreen, after a few seconds, or intermittantly, game goes quite dark. Longstanding and confusing thing.
Since it is seen to our SDL2 build too, maybe it is connected to our launcher ?
I think if i install libSDL.so and Quakespasm like on an ordinary Unix , there is no bug.
@Spike
#793 posted by Baker on 2014/06/22 06:48:04
Yeah sure except note the following ...
the code you (baker) linked is contrast, not brightness as you claim
The standard Quake brightness cvar is called "gamma" -- I wasn't about to change a cvar name everyone has used for 15 years ;)
And the function was named SCR_Brightness by MH so I kept the name, besides the slider bar is called "brightness."
Source thread: http://forums.inside3d.com/viewtopic.php?f=3&t=5185
(Looks like Reckless goes by Revelator now.
@stevenaaus
#794 posted by Baker on 2014/06/22 06:55:07
Gamma bug.
Is a major reason why I ditched hardware gamma in Mark V. It stupidly affects Windows and OS X.
I wrote tons of code trying to catch the system event that mucks up the brightness in Windows after switching between fullscreen and windowed mode. There isn't one.
Thread has some interesting infos on the topic: http://forums.inside3d.com/viewtopic.php?f=3&t=5185
SDL-1.2, Rpath And Crash
#795 posted by szo on 2014/06/22 09:52:55
The rpath thing is fixed in a later build+package, and there should be no crashes. Here:
http://uhexen2.sourceforge.net/tmp/QuakeSpasm-0.85.10-macosx-TEST2.zip
Not sure about the gamaa issue, though.
Suggestion
#796 posted by Lunaran on 2014/06/23 03:22:18
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
#797 posted by Baker on 2014/06/23 08:05:50
Except!!!
#798 posted by Baker on 2014/06/23 09:44:47
Spike pointed out some mods actually strategically display console text as a status indicator.
Like Quoth's flashlight indicator bar (example map = Ruined Nation)
Solution
Add CSQC support to Quakespasm.
Newer OSX Builds Using SDL1.2
#800 posted by szo on 2014/06/23 11:47:45
Crosshair With Text
Sounds reasonable to move centerprints up 4 lines if crosshair ??
Down
#802 posted by Preach on 2014/06/23 12:43:09
You probably want to head down in case the text is long...
Command-Tab, Antialiasing ?
#803 posted by Barnak on 2014/06/23 16:54:35
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.
|