At the moment it's hardcoded to use the "first controller in the list" returned by SDL.. agree this would be a good / easy thing to improve.

I don't know what would be a good way to store it in a cvar - just the controller index would work I guess, as long as the OS returns them in a consistent order across reboots.

re: Nightlies, thanks.. rebooted. 

Do you think that sometime in the future you'll create a menu for controller options? Maybe if players can easily change things in a menu it wouldn't be such an issue if they did have to occasionally change the CVAR.

Of course, I've really no idea how much work it is to add menu stuff in Quake... Just curious. :) 

in_sdl.c -> IN_StartupJoystick ...

Replace "for (i = 0; i < SDL_NumJoysticks(); i++) { ... }" block with following.

{
qboolean do_second = COM_CheckParm ("-controller2")
qboolean found_first = false;
for (i = 0; i < SDL_NumJoysticks(); i++)
{
const char *joyname = SDL_JoystickNameForIndex(i);
if ( SDL_IsGameController(i) )
{
const char *controllername = SDL_GameControllerNameForIndex(i);
gamecontroller = SDL_GameControllerOpen(i);
if (gamecontroller)
{
if (do_second && !found_first) {
found_first = true;
continue; // skip to the next one
}
Con_Printf("detected controller: %sn", controllername != NULL ? controllername : "NULL");

joy_active_instaceid = SDL_JoystickInstanceID(SDL_GameControllerGetJoystick(gamecontroller));
joy_active_controller = gamecontroller;
break;
}
else
{
Con_Warning("failed to open controller: %sn", controllername != NULL ? controllername : "NULL");
}
}
else
{
Con_Warning("joystick missing controller mappings: %sn", joyname != NULL ? joyname : "NULL" );
}
}
}


Hipnotic Rogue could just add -controller2 to the command line. 

Someone in the QuakeDroid thread asked for controller support for Android ...

Was about to implement controller support from a SDL2 development blog, then realized if it didn't use the same key names, behaviors and such as Quakespasm would be a missed opportunity.

Short version is that I spent some time researching the differences between the initialization in Quakespasm vs. what I read on the SDL2 development blog, and ended up reading this section of code several times. 

Cool, I hope the QS controller code is useful. I'm biased but I really like how it turned out (pretty clean integration with the engine, playable out of the box, defaults went though a lot of player testing - i.e. cubic easing, the deadzone implementation.)

Here is the initial commit that shows the changes outside of in_sdl.c: (mostly just adding K_ABUTTON and K_BBUTTON to the menu code.)
https://sourceforge.net/p/quakespasm/code/1293/

I made some further tweaks which I think were restricted to in_sdl.c. Let me know if anything is unclear.

(Thanks for the -controller2 code snippet, that seems like a good starting point for multi contorller support) 

Should you have use for it, @insideqc I posted something for "Quakespasm Ticket #27" (Unix path) that isn't rocket science but perhaps will save you 5-10 minutes.

Go to sv_main.c line 1432 (SV_SpawnServer) and applying that to the sv.model_precache[1 + i] (modifying it) *should* in theory solve the problem for models.

Might need to hit pr_cmds.c PF_precache_sound and pr_cmds.c PF_precache_model. And sv_main.c @SV_StartSound and sv_main.c @SV_ModelIndex

Rough blue print.

/If you decide that is worth addressing at all. The counter-argument is that this falls at the doorstep of the mapper -- the mapper fixes the map and re-releases the map. There are myriads of ways a mapper can foobar a map, perhaps the right answer is "Not going to protect mapper from self". 

Yeah, it's a grey area. If winquake.exe and QS on Windows accept it, that's a good argument for accepting the backslashes on Unix OSes, but it should be a developer warning on all platforms (realistically most maps are only tested on Windows before release). 

If winquake.exe and QS on Windows accept it,
that's a good argument for accepting the backslashes
on Unix OSes,

I disagree, we shouldn't have to fix mapper screw-ups.

Not going to protect mapper from self

This is how I see it. 

Plus what about mixed case filenames -- say some guy does a upper case file name that happens to match a lower case on in a pak on accident and Windows ignores it ... but Linux should do what?

Trying to protect mappers from their own choices ultimately leads to choices with unexpected consequences.

/Anyway, just throwing out a thought. 

fair point, I guess this kind of compatibility hack also indirectly forces other engines to apply the same patch. A developer warning would be good though. 

I do want to implement this at some point!

Zomg, sorry I seem to have missed this post, but that is great news :D

The faster / more natural / software faithful way of doing it is to ignore colored lighting and use the colormap.lmp just like software, having the fragment shader read the textures as 8-bit

I'd happily live without coloured lighting just for the true software look, although it's worth having a gander at how FTE does it, which somehow does the proper 8-bit palette look, but then it can still get tinted by coloured lighting afterwards, which neatly avoids the colours getting mangled. 

The way Quakespasm's SDL2 controller support works totally doesn't work on Android (at least not as of SDL2 2.0.8 - March 1 2018).

That being said, SDL2's controller support for Android appears to be better than in the past.

I think SDL2 used a "Steam/desktop computer mentality" to the controller support for Android, and then started to gravitate towards using the existing controller support already that is part of Android (which from accounts I have read, works outstandingly well).

I may yet get some sort of Android SDL2 controller support to work (I have 6 buttons working, no axis working, several buttons not working).

I think SDL2 has done a tremendous job on Android.

Now I think I understand why the SDL2 blog and your code were different.

Anyway, just wanted to provide some feedback to as to how that went. Should I get it to work, having your skeleton of cvars/deadzone stuff will have been very useful even despite SDL2 Android wiring differences. 

I've got a question about an issue that is suuuuper minor -- but I'm curious so I'll go ahead and post it.

When quitting the game, or when using the menu to start a new singleplayer game while you already have a game active, Quake will pop up an "are you sure" dialog that waits for you to press Y before continuing.

Something I've noticed when using Steam streaming with Quakespasm is that the dialog will be visible on the monitor of the PC that is running the game, but it won't be visible on the TV that the game is being streamed to (through Steam link). On the TV it looks as if the game has frozen up. But you can still of course press Y (or ESC) and things work as expected.

(I'm not sure if this happens with other Quake engines too.)

This is not anything I'm losing sleep over, but do you have any guesses off the top of your head why that dialog doesn't make it to the streamed display? 

might be drawn to the back buffer and then the buffers aren't getting swapped before the game stops to wait for input?

Does the same thing happen if you try to start a new game from the single player menu while a map is loaded? 

oh, reading a bit more closely... maybe the streaming to a TV doesn't update the most recent frame? It's one frame behind somehow? 

Nah, what is likely going on is that the screen is blocking in Quakespasm, like it was in FitzQuake and original Quake before it.

So anything that depends on a normal frame or normal event process isn't going to happen.

(A counter-example: in Mark V very recent builds, the dialog screen is not blocking -- you could stare that the dialog screen all day and, for instance, not disconnect from a server. It might be like that in FTE also, I wouldn't be surprised. I may have even got the idea from FTE and then forgot.) 

Although ...

If the issue is "one frame behind" ...

Quakespasm source ...

scr_drawdialog = true;
SCR_UpdateScreen (); <---- I don't draw twice!
scr_drawdialog = false;
...
do {
..
while }

If the stream expects double buffering, it isn't getting it in SCR_ModalMessage.

The test for a solution would be doubling it up ...

scr_drawdialog = true;
SCR_UpdateScreen ();
SCR_UpdateScreen (); // Double buffer it.
scr_drawdialog = false;

(My first reply was on gut instinct about the event queue/not having a normal frame ... because I've experienced a fair number of headaches before due the blocking dialog so I had the blocking dialed in as public nuisance.

But gut instincts aren't always right ...

and although I've run into instances of the blocking dialog not drawing specifically because it is blocking .... may not mean anything at all in this situation ...) 

not all systems even support explicit *SwapBuffer calls.
Eg, webgl takes away control of your main loop, redrawning only when your redraw function returns.
There's other systems that do the same sort of thing, including Android's GLSurfaceView or MacOS's cocoa api.

Plus there are drivers that violate the GL spec and force triple-buffering, so you're never sure how many swaps you actually need to make to ensure that its actually swapped.

As a result, its imho easier to just keep redrawing the screen regardless (which is required on many systems anyway, where the system doesn't repaint unless the app explicitly does so - like windows).
But its best to avoid modal things entirely. Sometimes you don't really have a choice though (like QC debugging).

Regarding video capture, the recording program probably set up some code injection that copies the backbuffer to a pbo (or a compute shader) before the swap. Such things generally check the response the frame after that, which avoids forcing the cpu to sync with the gpu. This requires a couple more swaps before the data is available to encode, which of course makes loading screens really messy.
Hurrah for threads!... 

Am I allowed to sell a mod on steam, using quakespasm engine ? I need some guidance with GNU/GPLv2. 

Here is an example of someone selling something on Steam using a Quake engine: https://store.steampowered.com/app/793670/The_Wastes/

Here is a mod on Steam for Half-Life: https://store.steampowered.com/app/225840/Sven_Coop/

The engine source code license agreement does not have much to do with any of this. 

As long as I give credits to quakespasm creators, and if the mod doesn't include quake materials (models, textures, sounds...) it's ok ? 

You should read this: https://partner.steamgames.com/steamdirect

But then also ask the question: are there people who are going to pay for a Quake map/mod in 2018?

Probably not. 

It's not about the engine, but the vibe (Thirty Flights of Loving, DUSK...)

Thank you for the link. 

In the mapping help thread, you asked about WAD3 (Half Life 1 texture format).

FTE is the engine used in the first link I gave you (to the best of my knowledge) and it supports the Half Life 1 map format, which is like basically Quake map format except for the texture format is different which is why J.A.C.K. can easily do both Quake and Half-Life 1 maps.

I mention that because you referenced something with tons of color, and it is basically impossible in Quake because of the color count restrictions. 

I stick with Quakespasm. Quake palette haven't much "blue" colors, right. I haven't yet looked into customizing palette.lmp

Do ya know PixaTool ?