Ironically, the bugged glClear behavior would be better standard behavior. 

glClear should respect scissor test but not viewport, which is a bit more flexible IMO. 

360 input - awesome

Will we have tons of commands where we can fine-tweak deadzones, accelerations, and all that? 

Yes, the bug I described looks like your screenshot. But on Rubicon3, it is terribly much more messy, with an extremelly luminous background (skybox ?).

I'm still wondering why it only happens with this Mod, and never saw the bug on any other Mod or map before. 

It was probably RRP's quake.rc with settings put in there. I would expect r_oldwater was in there. 

Hello,

I made a few personal changes to Quakespasm to solve a few minor annoyances I had. I was told I should show them off here in case any of them could be added to the main project.

https://github.com/bangstk/Quakespasm

What I've done:

QW hud option (cl_sbar)

Did the legwork to adjust the weapon offset on screen, I noticed some murmuring in here about what the best behavior should be as QS draws it with no offset. I decided to make it work closer to WinQuake, however I also made it adjust according to your status bar scale setting and status bar alpha, so it isn't ever too far up. There's some screenshots in the github link.

Adjusted centerprint message canvas so it's always above the crosshair. Depending on settings they used to cover the crosshair or even appear below it!



Right now I'm adding a new feature, automatic UI scaling. What it will do is when any sbar/console/whatever scale cvar is set to 0, automatically set the scale factor to make it fit the screen as cleanly as possible (integer scaling). That way new players won't have to mess with cvars to be able to read things at high resolution, or mess with the scale slider until it's even looking. Could be handy as a possible default. 

Great work man!! 

I finished and pushed the auto scaling feature. I've also been experimenting with a widescreen status bar implementation when sbar alpha is 1, though it's a bit hacky (lots of tris)

http://i.imgur.com/4lEopwG.jpg

Does it look good or is everyone used to the regular border graphics? 

It's a nice idea, but the empty boxes above bother me more than they should.

Ideally this sort of thing needs a proper layout design first. Try grabbing a pen and paper - for me random scribbles are good during the creative phase and the computer during the productive one. 

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?