What Tamarisk is referring to is this: http://www.howtogeek.com/218764/warning-don%E2%80%99t-download-software-from-sourceforge-if-you-can-help-it/

Summary:

Developers must opt in to a new "DevShare" feature.

If you opt in, your project gets embedded in SourceForge's custom installer.

That custom installer may bring crapware along for the ride.

Important thing is that if the developer doesn't opt in, none of this happens.

Personally I think that Tamarisk is scaremongering a bit. 

Scaremongering eh? Did you even read that article mh.

While true that the DevShare is opt-in, SourceForge has been caught red handed doing other not so nice things. Repackaging "abandoned" projects for one. 

Anyway, I'm done with this thread until it goes back to the real purpose, to discuss Quakespasm. You know this is just typical of the BS online nowadays. Try to post some useful information and get some nitwit shooting you down. Have a nice day folks. 

Func_msgboard is home of critics. It's what makes this place high quality. Participants here are expected to be able to explain/prove what they say or defend their thought process.

If you want to say Sourceforge is messing with a .dll fine, but you better be prepared to back it up with evidence.

That's just high standards at work. 

Sourceforge has new owners, clam down...

Antivirus is a fucking laugh. 

"If you want to say Sourceforge is messing with a .dll fine, but you better be prepared to back it up with evidence."

^^ This.

I mean, seriously, dude .. YOU brought it up! Don't get pissy when someone asks you to prove it. 

Kinn, when I download using https://sourceforge.net/projects/quakespasm/files/Windows/quakespasm-0.91.0_win64.zip/download the file I get has this SHA1 sum: 080f764fd7ace0764906a4d524e9463c47731f3a
If you want, check the sha1 on the zip file you download to make sure it's the same.

Here's an alternate download with the dll's:
https://github.com/ericwa/Quakespasm/archive/0.91.0.zip
The libopus-0.dll file is in the subdirectory: quakespasm/Windows/codecs/x64/

Note that this dll should be binary-identical to the one in the quakespasm-0.91.0_win64.zip from SF (it is for me.)

My windows defender info is: http://imgur.com/7OBTNJb
The archive comes up clean with both Windows Defender and Trendmicro HouseCall.

Sorry you had to deal with this, hopefully it's a false positive. 

Thanks - both of those links work for me without Defender shitting a brick :)

The SHA1 I get is 080F764FD7ACE0764906A4D524E9463C47731F3A

which is the same as yours (typical it comes out uppercase making it more annoying to compare hehe)

My defender version is now this: http://i.imgur.com/d9mz5h1.png

So yeah it looks like a false positive and Defender's new virus definitions have sorted that shizzle out hopefully. 

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!)