[quake3] new binaries and new mirrors

[Dirk]

Patrick Baggett wrote:
>> The original id tech 3 code were wrappers around the Linux/X11 API to read
>> input from the mouse... and around the Windows API to read input from the
>> mouse... It wasn't much code and it worked... for years...
>>
>> The switch to libSDL made the life for developers easier because instead
>> of maintaining two wrappers for the Linux/X11 API and for the Windows API
>> they need to maintain now only a single wrapper for libSDL... and libSDL
>> itself does now wrap the different API's of Linux/X11, Windows, etc. into
>> SDL functions... which is great... they have outsourced the mouse input to
>> libSDL that way and need to take care only of the SDL API in future...
>>
>> But the problem is that the libSDL wrappers are different than the
>> original id tech 3 one's... and players notice that... and what's the point
>> of maintaining a game engine the players don't like?
>>
> 
> You've identified the problem, X11/DirectInput code was "good", SDL is
> "bad". However SDL is not a magical black box. It's mouse code must also use
> DirectInput or X11 as an implementation. Yet for some reason, the mention of
> determining *why*, *what causes* SDL's use of the underlying API
> (DirectInput/X11) turns you off. What you fail to recognize is that
> DirectInput is DirectInput, whether or not it is linked in SDL or IOQuake3.
> It is the *usage* pattern that determines whether or not one is acceptable
> or the other. What would help is an explanation of *why* SDL's mouse code is
> unsatisfactory (not just a statement that it is), and how it differs in its
> usage from the original Quake3 code. Again, both are using the same
> DirectInput API -- so functionally the only difference *is the way in which
> DirectInput is being used*.
> 
> So, now that we know both are using the exact same API to perform their
> work, let's move on?

You repeat what I wrote. But your version is easier to understand.

> I don't think that problems with ioq3 should be fixed in SDL.
>> Let's follow some logic here.
> Quake3's mouse code is "good".
> Quake3 uses DirectInput for mouse interfacing.
> IOQuake3's mouse code is "bad"
> IOQuake3 uses SDL for mouse interfacing.
> 
> Your conclusion:
> The problem is in IOQuake3 and that the problem resides in IOQuake3, not
> SDL.
> *This does not logically follow*.
> SDL may not be as 100% polished in all areas as we might like. You suggest
> not using SDL.

I suggested leaving the original id tech 3 mouse code where it was and 
to make it optional at compile time to give people a /choice/.

The new SDL input code can remain the default.

 > I suggest fixing SDL.

...if it really is a bug in SDL that the ioq3 mouse input works 
different after switching to SDL.

If that is the case then switching to SDL-only and abandoning the id 
tech 3 input code was premature.

 > If every time someone hit a problem
> with SDL, they backed out of the changes made to their application, it is
> unlikely that SDL would improve at the rapid rate that it does.
> But that aside...
> 
> Once again, you've yet to explain how the code differs. *It is critical that
> this variance be made known in order for anyone, anytime at having a shot at
> fixing your problem without either side having to give up what they want.
> You get good mouse code and IOQuake3 uses SDL.*

so I should go and compare

SDL/src/video/x11/SDL_x11events.c

with

ioq3/code/unix/linux_glimp.c

and

SDL/src/video/win32/SDL_win32events.c

with

ioq3/code/win32/win_glimp.c

make a Q3_to_SDL_mouse_input.patch... and ask the SDL team to apply it 
because the ioq3 dev who made the SDL-only move wasn't motivated enough 
to do that himself in the first place?

I have to admit that I just started doing that... when I'm done and it 
is a bug, not just a different way, in SDL... we might all be happy 
afterwards... but RIGHT NOW ioq3 doesn't have the feel/handling of id 
tech 3 anymore... so why not leave the old id tech 3 mouse input code 
where it was until the SDL-only solution is a real replacement?

> *If all you want to do is "fix" (hack) old code from Quake3, then do so*. No
> one is stopping you from fixing up IOQuake3 with some custom modification.
> You can even make a website explaining how your IOQuake3 binary has 50% more
> mouse handling goodness than standard IOQuake3. If people are truly
> interested by this and this is a serious, breaking-point issue, you'll have
> a lot of people thank you. Build it and they will come, etc.

Forks are bad, technical solutions to solve human disputes... not 
interested...

> However, you've constantly pushed that the changes made need to be reverted.

I suggested leaving the original id tech 3 mouse code where it was and 
to make it optional at compile time to give people a /choice/.

The new SDL input code can remain the default.

> You've merely complained that a "regression" has occurred and assume that
> the best way to "fix" it is back out on a change. No, that is a fast way of
> getting back to a previous state, not fixing it. When a regression occurs,
> you fix the regression, not back out the change. It really is that simple.
> And right now, you aren't part of the solution, you're just complaining. It
> has already been explained to you what you need to do in order to see some
> forward motion in solving your problem. So what is your next move? Complain
> that DirectInput needs to be back in again?

Yes, I do complain that going SDL-only and abandoning the id tech 3 
input code was /premature/.

If the different feel/handling of the mouse input is the result of a bug 
in SDL or the result of an error made during the move to SDL-only didn't 
concern me much.

I just came here to suggest to leave the original id tech 3 mouse code 
where it was and to make it optional at compile time to give people a 
/choice/.

The new SDL input code can remain the default.

What is so offensive about this GREAT (sorry) idea?

It could be handled like this UNTIL(!) the real problem (bug in SDL or 
error in transition to SDL) has been found.
Not just move to SDL-only and tell someone who dares to complain about 
the substitionless removal of the id tech 3 code that it his fault he 
didn't fix the SDL-only code to make it work like the old id tech 3 code 
which was removed.