I'm sure you can get a second hand one. Personally when I need a gamepad on PC, I use a Dual Shock 2 with a Madrics Superbox 3 Pro - yeah, fancy name for a little plastic thing. Works good and I prefer the shape of PlayStation pads. 

Just another way of saying xinput support. That's the standard controller library that's replaced directinput on windows for the past few years, you'd be hard pressed to find a PC-compatible gamepad that didn't use it. Supporting the 360 pad is supporting gamepads in general, at least on Windows. 

90% of the work in implementing QS's controller support was stuff that is independent of the SDL2 gamepad api - Subjective stuff like deadzones, easing functions, choosing good defaults and playtesting them. Also making the menus usable with the controller. So this code could still be useful if you like how I did it.

SDL2's gamepad API was, I believe, largely a clone of whatever the modern windows API for gamepads is (Xinput?)

re: 360 controllers dead
true but I don't think this affects software much if at all. 

It would be great if you could include some kind of error logging in a new release, so that we could get some idea of why the GL version crashes instantly as soon as I try to load a map (it runs fine up top that point... in the console and menus).

And maybe also see why the DX version crashes intermittently....

Quakespasm, FTE, Qrack, etc., all work fine in GL for me. I really hope Mark V can be fixed to work in GL for me too. 

They have them at Newegg. I was just looking at it the other day. It's on sale for $30 with "free shipping". 

@ericw - I think your code is pretty tight and well written. Mark V doesn't do DirectInput or XInput, so would be hella lot of work for Mark V support. Definitely not part of a group of 4 small updates, each that don't take too much time.

@gunter - I don't have much time, we'll see. I private suspect your graphics card can't do anything except 16-bit color, are you actually able to use, say, Qrack or Quakespasm in 32 bit mode?

@others - All I am saying is that my interest in a discontinued controller limited to pawn shops, ebay, second hand sales is "meh".

If someone knows of a worthy controller that actually has a future ... 

xinput is the future (for now). The specific type/brand of controller using xinput shouldn't matter much. 

I don't understand, seems like un-needed hostility? Maybe I'm misinterpreting your tone though.

You can still get 360 pads brand new here in Europe, they're marketed as a 360/PC controller.

They're pretty much THE standard controller for playing games on PC, even more than the xbone, PS4 or any number of PC-Specific pad.

You could have just said "it's too much work, sorry" or "it's not a priority". 

Supporting xinput, as far as I know, will allow you to support basically every logitech controller for the past few years, the Xbox One controllers, and the generally established hacks for the DS4. So, basically all the controllers.

Speaking of hacks; aside from the tricks people are pulling to get the DS4 to work on PC, there are also plenty of wrappers out there that will make a DirectInput controller work like an xinput one for most purposes, so there's not much need to support an (actually dead) second system of controller.

Honestly though... how necessary is controller support? Does anyone here, or anyone that someone here knows, actually use it in QS? I certainly don't, and I can't say I see the appeal either... 

Isn't it pretty much the standard for PC controllers because of support built into Windows?

http://www.newegg.com/Product/Product.aspx?Item=N82E16826105438&ignorebbr=1 

The only Quake engine that seems to report the BPP in the console is Quakespasm, and it tells me "24-bit" when I try set it to 32 bpp (either in the menu or by command line).

Of course it reports "16-bit" when I change to that....


How would I verify that any other engine is running in any certain bpp?

Well, I can do more than 16 bpp in any case... (what is it, the stone age? :) 

when I just want to sit in front of the TV playing games I whack on some Quake.

I know KB+M is the best way to play but I originally used to play the game keyboard only when I first got the game... :P 

@gunter - that clears up possible causes of the issue.

@fifth/@rick - I'm not against gamepad support.

As long as the controller support code works with current/future devices (@johhny). 

 

I don't claim to keep up with consoles ...

Does the Quakespasm controller support work with an XBox One Controller? 

According to this reddit post the xbox one controller should work with any game that uses XInput, which SDL2 is wrapping, so it should work in QS. I don't know if anyone has tested it though.

Anything listed here should work out of the box with qs, there is also a community mapping file for more support. 

Ok, that clears up things quite a bit -- it supports a wide array of devices.

When I hear "xbox 360 controller" immediately I think "But the XBox One came out back in 2013?" 

@gunter -- you may discover the Dopa maps surprising automatically download now for supporting clients.

/*snort*

/Inside joke, gunter will understand. 

Uhhh... does that mean Polarite updated the server so it will do that now? Hm, yesterday Trans did say he thought he saw Darkplaces download something.... Neat. We'll have to test this more.


We do indeed have the DOPA maps installed on fvf.servequake.com and they work (almost*) perfectly for FvF Quest mode. So everyone should come give it a try! You can use the VOTE menu to activate the custom maps.

* One thing mappers often neglect to do is add Co-op spawn points. DOPA has this oversight... so all the players try to spawn on the one Single-Player spawn point, resulting in undesirable things happening, like people getting pushed into the floor. That can be really bad when there's a lava pit below the floor, heh.

Another "gotcha" you gotta watch out for are trap rooms that lock behind someone when they enter, and if the person dies in there, there's no way for anyone else to get in, so progress is blocked on the map. DOPA contains 2 areas like this, but I work around them with QuakeC code by actually relocating buttons and altering properties of doors on the map, so that the roadblock is moved out of the way or opened from the outside.


But yeah, everyone should come play FvF. The server is almost always in Quest (co-op) mode, so it's newb-friendly.

http://fvfonline.com

(Heck, while I'm self-promoting, here is also a link to find out about my Pogo Piggle games for Android, which everyone should also play :D ) http://tinyvast.com 

Hm, well... we tested today and maps did not automatically download to Darkplaces.

I guess you may be talking about something that has not yet been implemented...?

*scratches head* 

All the old methods of stopping Demos from playing at start up no longer work

It's in the menu so anyone can do that. The cvar is host_startdemos 0 (default 1). 

Wow, that's a really old issue I reported back in 2014, Baker, heh. I think that's been fixed for a long time.... I did find that menu option (that's probably the newer addition). It's very handy.


Probably my main hope for a soon release would be Proquake-positioned Centerprint and "Rankings" scoreboard, so they don't obscure your view right in the middle of the screen.

Actually, I'm not sure exactly how ProQuake's Centerprint positioning works... It seems like if your centerprint message has more than 3 lines or so, it is placed up high, well out of the way of your view. But if your Centerprint message only has 1 or 2 or 3 lines (using \n) it places it down lower near the center of the screen... but still not right in the middle of your view. Maybe it checks to avoid that specifically rather than just moving EVERYTHING up to a certain point (though even the menus are positioned higher). In any case, it's much preferable to having stuff printed right over your crosshair position. 

Can you do a screenshot demonstrating the centerprint issue you are having? My imagination isn't working. 

(Small screenshots just to illustrate the positioning of Centerprints)

http://imgur.com/a/H2qvE

First comparison is the standard FvF Vote Menu. You can see Proquake keeps it up high, not blocking the center of the player's view. Obviously most players aren't going to be running around shooting things with the Vote menu up, but there are other centerprints that happen in the game which have the same issue -- notably, all the FvF splash text stuff when a level first starts... and sometimes there are monster attacking you when the level first starts, so you need to be able to aim :D


Second comparison is me pressing the TAB key to show the scoreboard while the vote menu is still active. I just noticed that Mark V hides any centerprints when you are viewing the scoreboard.... I'm not sure I like that behavior (is there a setting?). A player might miss a centerprint message when doing that.... Well, Proquake shows both things at the same time; yeah, that can end up with overlapping stuff, but a player can easily release TAB when he sees a centerprint pop up.
Anyway, you can see that again Proquake moves the scoreboard up near the top (probably a bit too far in this case, because that can block the second and lower chat line -- there's still room at the very top for one chat line). If there were 4 or 5 players in the server, the Mark V position (which is most likely the standard for Quake) would again block the center of the view, where the crosshair is.

The final comparison shows that the position remains the same when it's a short centerprint with only a few lines (the crosshair positioning may be off a bit, so the relative text position may be exactly the same... or it may be slightly different... not sure). Either way it doesn't block the view, so that's fine.
I'm not sure exactly how Proquake decides where to position stuff, but it seems like if there are 4 or more lines in a centerprint, it puts it way up at the top, but 3 or fewer lines are shown back at the standard location.

These issues become worse if the text size is increased by scr_conscale (I shrunk my text in Mark V to match Proquake, but I usually have it larger, so centerprints sometimes go well below crosshair level). 

@gunter -- re: centerprint position

I connected to your server and tried some of the menus. I thought it looked pretty good with the default settings in both Mark V and ProQuake. If I mess with settings in either engine, I can make it not look good in either of them.

Centerprint consistency has always sucked as tool available to the QuakeC modder, even with GLQuake. If you use a big resolution, the text stops being where it was supposed to be and might even be in annoying place.

If I loaded up Quake with the intended resolution of 320x240, your FVF centerprint will be all over the crosshair. "Gunter? Why u hate DOSQuake so much! Is only real QUAKE! Quake CD comes with DOSQuake, is no GLQuake on Quake CD! GLQuake is a lie!!"

Mark V centerprint starting position is pretty consistent across all video resolutions, but just like original GLQuake if you start changing settings or resolutions it affects the placement (but at least Mark V calculates it the same regardless of any settings/resolutions you can pick).

The centerprint position also relates to the finale printing. I worked long and hard with NightFright to get that all positioned properly and independently even for single player releases like The Rapture that prints incredible gobs of finale text (it's like a mini-thesis, it's that long) --- while also taking into consideration multiplayer mods.

That's called the "fine tuning problem". If you "fix it for one" (combination of settings) then you just "break it for another".