Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

<asie> why is it when i press right mouse button the sounds go quieter #272

Open
iamgreaser opened this issue Jul 13, 2016 · 8 comments
Open

Comments

@iamgreaser
Copy link
Owner

iamgreaser commented Jul 13, 2016

The new sound code doesn't compensate for the hiccups we get with wav_cube_size and all that shit when zooming is used. The main reason we compensate in the first place is because of backwards compatibility and whatnot.

We could consider using a flag (wav_cube_autoscale_enable() could be a call) to allow working around this shitty behaviour. Or we could just assume that if you're running old code on a new engine or new code on an old engine then it's your own stupid fault.

pkg/base/obj_player line 1300ish has this:

-- BUG WORKAROUND: adjust wav_cube_size dependent on zoom
if client.renderer == "gl" then
        client.wav_cube_size(1.0*this.zoom)
else
        client.wav_cube_size(1.0/this.zoom)
end

I'm of the view that we might as well just drop this and do it properly in the sound code.

Here's what we're fighting against.

src/vecmath.c:

// Front vector (Z)
model->mzx = dx*zoom;
model->mzy = dy*zoom;
model->mzz = dz*zoom;

src/wav.c:

dx = odx*tcam.mxx + ody*tcam.mxy + odz*tcam.mxz;
dy = odx*tcam.myx + ody*tcam.myy + odz*tcam.myz;
dz = odx*tcam.mzx + ody*tcam.mzy + odz*tcam.mzz;

Ultimately we just need to get the length of tcam.mz* and divide dz by it.

@asiekierka
Copy link
Collaborator

asiekierka commented Jul 13, 2016

oh no
i'm an issue now

@iamgreaser
Copy link
Owner Author

@asiekierka has been declared problematic.

@rakiru
Copy link
Collaborator

rakiru commented Jul 13, 2016

Or we could just assume that if you're running old code on a new engine or new code on an old engine then it's your own stupid fault.

By the time we merge to master, running old code on new engine or vice-versa is going to have little chance of even working at all, so +1 to just breaking it and doing it properly.

@NotAFile
Copy link
Contributor

exactly, I thought not worrying about backwards compatibility was what dev was all about

@iamgreaser
Copy link
Owner Author

Except it isn't. dev is for not worrying about bumping the version. dev feeds into master.

But this is a backwards incompatibility that's fairly minor.

@rakiru
Copy link
Collaborator

rakiru commented Jul 14, 2016

^

Although in this instance, I say make all the breaking changes we need to remove any hacks and such. It saves having to build on top of them for any future changes, where we will not be breaking things without good reason. Basically, some of this stuff needs removed at some point, so might as well just rip it all out in one go.

@asiekierka
Copy link
Collaborator

Just as a note, the three servers up nowadays are all ran by iceball developers.

@NotAFile
Copy link
Contributor

the users too, unfortunately. But it's not unlikely that somebody will discover a folder called "iceball" while clearing out their hard drive and decide to give it a whirl again. Although those people might try downloading a newer version by themselves, some kind of notice to upgrade before any code that crashes the client is executed would be nice.

Asie's point still stands that backwards compability is less of an issue if the player base is 0 ±1 people, and there are no third-party servers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants