Side note: Don't want to interfere with the current conversation.

Quakespasm inherited bad centerprinting from FitzQuake. No other engine from DarkPlaces to ezQuake to WinQuake to JoeQuake has a centerprinting problem (Mark V does not have the problem either).

The FitzQuake centerprinting location can't be solved by moving text up or down a line, because "what line" it prints on was never the problem ...

It's a multi-factor problem that will resurface with a different combination of settings if "fixed with a hack" --- the problem is the "definition of a line" is not consistent across various settings.

(Please carry on with existing interesting conversion ...) 

My description is a bit simplistic, I did not simply change a y-coordinate. I reorganized centerprints to its own GL canvas that spans the height of the screen, and I have the lines start printing in reverse order from 1/3rd the height of the screen. This keeps it off the crosshair even when the sbar is fully scaled up. (if there are more lines than would fit in that area, then they do start covering the crosshair, but this would have happened in any engine)

Winquake (and I'm assuming the other quake engines you mentioned) did it by drawing lines 35 pixels from the top of the screen, scaled to whatever scaling values each engine uses. The drawback is the smaller the text scale value the closer it is to the top of the screen, which draws it away from the player's focus more and more.

Quakespasm's old behavior drew centerprints in the Main Menu GL canvas, which originates from the center of the screen. This limited the height that centerprints could start at without shifting up the main menu as well. 

My intention with the widescreen sbar was to be able to construct it in-engine from the sbar graphic, that way it could be compatible with whatever mods replace that graphic. Since QuakeC can't rearrange the HUD, any such graphics would fit the same layout and probably look about as good. 

+1 Sounds like you are detail oriented and anal retentive and do your homework and then plan.

(I like this guy already!) 

I checked Mark V and it seems we had the same idea. Yours just takes into account status bar height as well. Mine doesn't, I based it on Winquake's offset at 320x240.

I guess I remembered WinQuake's behavior a bit wrong, it only used fix offset from the top when there was more than 4 lines.

Still, what I did was make it always originate from about 1/3rd the height of the screen. The difference is I set it so that point is where the LAST line will be drawn. If there are more lines, they originate from higher, unless it would start offscreen. 

True enough, it's why I did this fork to begin with...:P

@ijed: How's this? Now it skips the vertical lines

http://i.imgur.com/5HBFA8B.jpg 

Controller support :)
Amazing the amount of stuff Eric is doing.

@Tarvis

The QW Hud option is great, but i'm not sure about adding the option to the main option window. Probably ok... but the Menu-Item should be something meaningful, like "QW Style Hud".

Weapon Offset changes.. not sure about that.
Personally, i'd favour bigger field-of-view over re-placed weapon models.

The other things - an auto scale option is interesting, but not gonna bastardise the scale widget like that. It'd have to be a cvar only. And not keen on the widescreen status bar. Centerprint should be left as-is if crosshair 0, but otherwise - i don't use the crosshair, so can't say if it's an improvement. 

"The drawback is the smaller the text scale value the closer it is to the top of the screen, which draws it away from the player's focus more and more. "

Where the hell did this guy come from? Engine coders that preemptively analyze for situations that aren't on the screen.

(But yeah, that's true and fixed in Mark V. Probably DarkPlaces too I would hope because if LordHavoc cared about getting the gun to be in the same place in all resolutions, no doubt he thought about the text placement too. The gun thing is of course fixed in Mark V.) 

"The difference is I set it so that point is where the LAST line will be drawn."

But you can't do it that way. Some mods print 20 lines of center print.

(Ok, so he's extremely intelligent and introspective but isn't a grand master --- I'm kidding around a little with you) 

Sounds like some nice changes, thanks for contributing!

I'm not sure about http://i.imgur.com/4lEopwG.jpg , I think we'll want to keep the original tiling background. I imagine most people use a bit of status bar alpha so they don't see the tiled part anyway.
One change that could be good though is scaling the dark tiled part so the pixels are the same size as the main part of the status bar; currently QS doesn't scale that part. e.g., here's winquake at 640x480, sceenshot scaled 2x: http://i.imgur.com/OZ8fWvh.png 

Wow, thanks for the feedback guys.

@Baker "But you can't do it that way. Some mods print 20 lines of center print."

Simple "if (y < 0) y = 0" check takes care of that :)


A cvar to disable the weapon offsetting back to regular QS behavior is simple enough.

As for the wide-screen HUD, maybe it's not worth it after all. At least the regular tiling border is a close enough color to begin with (unlike Doom)


As for center print positioning I guess that's a personal preference sort of thing. I guess I just don't like text obscuring where I'm shooting.


Can cvars have multiple callbacks? If autoscaling was made a cvar it would be handy if any changes to the regular scaling cvars would disable it. 

no way. those empty boxes would drive me nuts.

why even show the border at all? just remove the brown areas on the side of the sbar and float the sbar in front of the screen. 

why even show the border at all? just remove the brown areas on the side of the sbar and float the sbar in front of the screen.

Yeah, that would be my first thought too :P 

It's a "What do I need to find!?" OCD thing. 

Omicron Bots mod has a feature Quakespasm can't use.

"registered 2 - the patch does not load the models supplied with the bots"

You can't set registered 2 in Quakespasm.

Reference

Omicron Bot Mod Download 

Finally committed this! Windows builds available here ( r1293): http://quakespasm.ericwa.com/job/quakespasm-sdl2/

I'll need to add some documentation later, here is a first stab though:

Cvars:
* joy_deadzone - fraction of the stick travel to be deadzone, between 0 and 1. default 0.2.
* joy_sensitivity_yaw/pitch - max angular speed in degrees/second. Defaults are currently 300 for yaw (turning left/right) and 150 for pitch.
* joy_exponent - for the look stick, the stick displacement (between 0 and 1) is raised to this power. Default is 3. So a value of 1 would give a linear relationship between stick displacement and fraction of the maximum angular speed.
* joy_invert, joy_swapmovelook - enable to swap the move/look sticks or invert the look stick. Default is move on the left stick, look on the right stick.

Buttons:
Some of the controller buttons are hardcoded: back=TAB, start=ESC, dpad=arrow keys. The others are normal bind-able keys: L/RTRIGGER L/RSHOULDER, L/RTHUMB (pressing in the sticks), A/B/X/YBUTTON.

quakespasm.pak's default.cfg has been updated to give some default bindings, so make sure to install the quakespasm.pak. L/R shoulder buttons are bound to weapon switching, L/R trigger are jump and attack. A and B are hardcoded to operate the menu, but they're not bound to anything in game by default. If you choose "reset config" in the menu, these default bindings will be loaded, and I think "exec default.cfg" will also do it.

Other stuff:
The key bindings screen in the menu now supports 3 keys per action. This could be annoying for non-controller users, so maybe controller bindings/settings should get their own menu page. I just try to avoid adding things to the menu if possible.

Anyway feedback is welcome! Especially, are the default sensitivity/acceleration settings good? 

Amazing, this feels really responsive on the default settings. I blasted through episode 1 and I don't feel like I was hindered too much by the pad.

I bound jump to LT and shoot to RT and it was great. I wanted to have weapon up and down on X/Y but for some reason weapon down doesn't work??

I'm really hoping that at some point we can get split-screen working 2-4 player so I can run "lan" deathmatches and co-op from a single pc set up. I'm not sure how you would implement multiple pads but this would be a dream come true IMO.

Yes, I still play games in the old-school console way with my buddies even though I'm an old codger. ;) 

Here's a demo of me playing through Episode 1 with a pad -

http://www.quaketastic.com/files/demos/5thpaddemo.zip

As you can see I didn't really have much trouble, admittedly I can go through a bit quicker with the keyboard and mouse but it's still fun. In-fact it's almost more fun because of the slight handicap, some of the challenge was reintroduced. 

Awesome, glad to hear! Not sure why weapon down didn't work.
Yeah, local multiplayer would certainly be cool to have for lan parties.

I've had a lot of fun testing this too, played a few maps from AD with it while working on it. 

Possible feature?

Instead of weapon cycle it could be interesting to use the D-Pad to cycle through weapons.

Left = SG/SSG switch
Up = NG/SNG switch
Right = GL/RL switch
Down = Axe/LG

It will be a little bit like a weapon wheel but less crappy. 

Years ago there was a way of getting splitscreen to work on Quake 2 I think it was. The implementation was a bit funky, you opened separate executables and there was a window that allowed you to input the in-active window as well as the active window. You connected to your own pc through your LAN.

I tried searching for it but all I could find was this Quake 3 Arena source port that has native split-screen -

http://spearmint.pw/ 

 

Open up 2 Quakespasm clients.

Use the new borderless feature.
Carefully position the windows and then toggle the borderless. Do this twice.

For the Window you touched last, the player uses the mouse and keyboard because only the active window can actually receive keyboard and mouse input in Windows.

For the Window you didn't touch last, the player uses the 360 controller. This will work because I suspect the 360 controller code won't check to see if it is the active window (but I didn't look) because the original Quake joystick code never did.

Now the guy using the mouse is going to own the 360 controller dude, so play coop.

You might want to set sv_aim 0.93 (the default Quake sv aim) so the 360 controller dude gets a little bit of aim help. 

D-Pad weapon cycling could be hacked in like this:

alias ng1 "impulse 4; alias ng ng2"
alias ng2 "impulse 5; alias ng ng1"
alias ng ng1
bind leftarrow ng

That would make leftarrow cycle between NG and SNG. The problem is you might have to tap it twice if you have the SNG but not the NG, the first press would try to select the NG.
Not sure if that can be improved on without doing it in QuakeC.

I can add a cvar to select which controller number is used, I assume SDL2 properly handles multiple controllers plugged in. Running multiple QS executables as Baker mentioned might work OK, I'm not sure if the background window gets joystick events, need to check. Also, currently sound is muted when a QS window loses focus. 

If the mouse/keyboard computer ran Quakespasm older Quakespasm without controller support and the 360 controller window ran newer Quakespasm with 360 support ...