But beware - some gfx cards on some platforms don't support app controlled vsync under OpenGL and expect you to set it via their control panel. 

Quakespasm is detecting vsync capability because it probably checking for that GL_swap_control extension, but needs to check for GL_ARB_sync for the Mac at least with the modern Macbook Pros

[That's kind of a fiasco and not fair to the developer. There shouldn't be several different ways to detect sync capability. On Windows even sometimes you have to check WGL extensions instead of the GL extensions. That's just wrong.] 

Well, whenever I run a user mod/map in QS, the Quake video options menu lists vsync as 'n/a'.

Is there away to enable it? 

Not without the developers making a change to Quakespasm. 

GL_ARB_sync is not related to vsync. Apparently that is something else (sync multiple GPUs). 

so basically what you wrote above is all wrong, yeah? If you find out how to handle vsync on OS X, let me know and I'll add it to the mac builds.

AFAIK, OS X has a different architecture than other OSs when it comes to swapping the buffers. So whether you can use VSync also depends on how the window / gl view are created on OS X. At least, that's what I remember - might be wrong or different now. 

But I think the extension check is unnecessary, at least on OS X. 

The Fruitz of Dojo port has had vid_vsync for ages although the cvar name is vid_wait.

void VID_SetWait (UInt32 theState)
{
const long params = theState;

// set theState to 1 to enable, to 0 to disable VBL syncing.
[gGLContext makeCurrentContext];
if(CGLSetParameter (CGLGetCurrentContext (), kCGLCPSwapInterval, �ms) == CGDisplayNoErr)
{
gGLVideoWait = vid_wait.value;
if (theState == 0)
{
Con_Printf ("video wait successfully disabled!\n");
}
else
{
Con_Printf ("video wait successfully enabled!\n");
}
}
else
{
vid_wait.value = gGLVideoWait;
Con_Printf ("Error while trying to change video wait!\n");
}
}

And the part that calls that function:

void GL_EndRendering (void)
{
// set the gamma if fullscreen:
if (gVidDisplayFullscreen == YES)
{
VID_SetGamma ();
CGLFlushDrawable ([gGLContext cglContext]);//CGLGetCurrentContext ());
}
else
{
// if minimized, render inside the Dock!
GL_RenderInsideDock ();
}

// check if video_wait changed:
if(vid_wait.value != gGLVideoWait)
{
VID_SetWait ((UInt32) vid_wait.value);
}


http://www.fruitz-of-dojo.de/php/download.php4?dlnr=2 

All the Core Graphics stuff is done by SDL, but that is how Fruitz of Dojo Quake does it ... 

Maybe my memory is wrong or I'm mixing things up. I guess I'll have to see whether the SDL way actually works at all, in that case I'll just remove the extension check. 

I wish QS would stop spamming the console with all the "FindFile: blahblag.pcx" messages

ok 

It seems that qs has the chase cam bug that older engines have. With chase_active 1 set, if the camera 'hits' a wall, you can partially see through the wall. I think there was a fix for this on inside3d. 

Of the various options, if you want an essentially 100% fix as easily as possible, this one by MH is the easiest to implement:

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

There is a 95-99% fix by R00k that is even easier to implement, but then you'll get driven insane if you notice even a single weird situation that it fails ... particularly stepping backwards at an angle.

The MH fix does not take entities into consideration. This means doors and platforms and such. More "sophisticated" maps of the times where you turn a wall into a func_wall to make it transparent (FitzQuake .alpha support) or in the case of Remake Quake (alpha texture support, like Half-Life ... fence textures per se) the MH fix won't take func_walls into consideration because those are entities, not the "static unchanging world". 

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

Yeah, our chase cam is broken. 

My second post in that thread does do entities, with the exception of statics (it wouldn't be hugely difficult to add statics to it either).

It's definitely worth following the subsequent discussion in it as there's valuable info and experimentation there from quite a few others. 

On at least the current Macbook Pros, there is a delete key where the backspace key would be.

And it works like the backspace key. If you hold "FN" and press the backspace key, it works like the delete key.

But it doesn't work right in Quakespasm. If I go to customize controls and try it bind it to a key, it says "Backspace."

But in the console it doesn't do anything.

The backspace key works right in Open Arena (ioQuake3) and in my modified ProQuake which uses the Fruitz of Dojo input code.

Oddly enough, the SleepWalkr RMQ Engine build doesn't have this problem. But Quakespasm 0.85.6 OS X does.

I'm just making a note of this here so it is recorded. I might incidentally bump into the nature of this issue and post it here. 

Here is the bad code:

case key_console:
if ((event.key.keysym.unicode != 0) || (modstate & KMOD_SHIFT))
{
#if defined(__QNX__)
if ((sym == SDLK_BACKSPACE) || (sym == SDLK_RETURN))
break; /* S.A: fixes QNX weirdness */
#endif /* __QNX__ */
if ((event.key.keysym.unicode & 0xFF80) == 0)
sym = event.key.keysym.unicode & 0x7F; <----------- Baker
/* else: it's an international character */
}
/* printf("You pressed %s (%d) (%c)\n", SDL_GetKeyName(sym), sym, sym);*/
break;
default:
break;
}


It is turning a sym = 8 (backspace) into sym = 127 (delete)

That only occurs for case keyconsole.

If I change #if defined(__QNX__) to #if defined(__QNX__) || defined(__APPLE__) I no longer have this issue.

Am I the only Mac Quakespam user whose backspace key does not work correctly in the console with 0.85.6 ? 

whether pressing the mac Delete key on its own, or Fn+Delete, both act as "forward-delete" in the quakespam 0.85.6 console� i.e. they act like the PC delete key. 

 

Does anyone know how that code got in there? 

If I change #if defined(__QNX__) to #if defined(__QNX__) || defined(__APPLE__) I no longer have this issue.
Thanks Baker.
Oz and Sander put some effort into enabling unicode chars, but i suppose OS X needs more work. Natchurallllyyy 

Baker: ioquake3 has a special handling of 127 in that unicode portion of the code: in sdl_input.c, find this:

if (down && keysym->unicode && !(keysym->unicode & 0xFF00))
{
unsigned char ch = (unsigned char)keysym->unicode & 0xFF;
switch (ch)
{
case 127: // ASCII delete
if (*key != K_DEL)
{
// ctrl-h
*buf = CTRL('h');
break;
}

So, if I change the code around line 363 to the following, does it work OK on osx?

case key_message:
case key_console:
if ((event.key.keysym.unicode != 0) || (modstate & KMOD_SHIFT))
{
if ((event.key.keysym.unicode & 0xFF80) == 0)
{
int c = event.key.keysym.unicode & 0x7F;
if (c == 127 && sym != SDLK_DELETE)
sym = 8; /* CTRL-h */
else sym = c;
}
/* else: it's an international character */
}
/* printf("You pressed %s (%d) (%c)\n", SDL_GetKeyName(sym), sym, sym);*/
break;

(Steve: this also removes the qnx special handling of yours: make sure it doesn't break anything.) 

SleepwalkR:
> Does anyone know how that code got in there?
Take some time to read SDL_keyboard.h 

Do you guys intend to improve the MP experience too? Because this could - at least for us Unix folks - be the engine to end them all.
I saw that you increased the particle size (texturescale var set to 1.27 i think, can't check atm, am @work) which is not so great for MP, would like to see a cvar for this.
Beside that, I checked out the source and added pq_needrl & friends as well as .loc support and other little things, is there interest in this?