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? 

How does texturescalefactor, which is about drawing the particles and doesn't seem to have anything to do with net traffic, can not be so good with multiplayer?

As for additional features suggested, we can review and possibly merge patches if you submit them to us through our tracker on our project page. 

I think a large part of the particles problem is that the MP community likes to run with high values of host_maxfps (in order to get smoother movement). Because particles are primarily fillrate-bound, lots of particles many more times per second will have a disproportionately higher impact on fillrate (esp when squeezing a 64x64 non-mipmapped particle texture into tiny screenspace areas). 

so are mipmaps actually a performance gain rather than just a (subjective) quality gain? I could mipmap the particles pretty easily if that is the case. 

I never understood that either. I always thought, logically, it should just be a visual improvement but for some reason it factors into performance as well. Isn't it just interpolating across the texture, regardless of the polygon size on the screen? Why do mips matter for performance? 

No, for me it's not about FPS in this case. They just get too big and block view more then necessary. With lots of rockets and explosions it really gets annoying, I tried it. Doesn't matter or may even be a visual enhancement in SP that's why I suggest to have a cvar for it (going from 1 up).
I'd like to see quakespasm to stick to the proquake standards for MP.

Sorry that I didn't make that clear in the original post. 

Ok, patches uploaded to project homepage. 

This more or less says it: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0555a/CHDEIJID.html.

Summary: reduced memory bandwidth and improved cache utilization. 

Cache efficiency, OK, I guess I can see that ... 

Cheers LeopolD.