since sourceforge changed it's owners in what 2012 I tried steer away from it. I used to like the service but not anymore. I'm always reluctant when stuff is hosted there and it leaves the impression of an abandoned project.

I don't understand why quaskespasm is hosted there. I don't even care that they changed owners again in 2016 because there's github and that service I do still trust in and also really like.

I'd leave sourceforge just for the sake of not making people download from a site they distrust. I don't care if they get their shit together or not. 

Yeah, let's put everything on Github because that is never going haywire. Self host, you lazy people... Gitlab is fun.

flp: Read my post above. 

is this ever going to happen? i cant bring myself to game from a desk when i can game from a recliner.

let me play quake again, please. 

shub: Yes, soon! I have it working pretty nicely - played some of AD with a 360 controller, just need to polish up a few things.

.. continuing from the RRP thread about Barnak's HOMs when using fsaa + "r_oldwater 0" + OSX 10.6...

Baker, I found a workaround, adding "GL_SetCanvas(CANVAS_DEFAULT);" to the end of R_UpdateWarpTextures.
R_UpdateWarpTextures leaves the glViewport configured for the warp texture (the square in the upper-left of the screen), and R_Clear is the next thing to happen after R_UpdateWarpTextures, so my guess is that fsaa activates some code path within the mac GL implementation where glClear is broken and uses glViewport as the area to clear..

Here's what it looked like for reference: http://imgur.com/a/7pF6k
The second shot has gl_clear enabled, but you can see it's only clearing part of the screen. 

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.