[quake3] new binaries and new mirrors

[Patrick Baggett]

> 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?

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 suggest fixing SDL. 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.*

*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.

However, you've constantly pushed that the changes made need to be reverted.
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?

Patrick Baggett



> ---
> To unsubscribe, send a blank email to quake3-unsubscribe at icculus.org
> Mailing list archives: http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?50
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/quake3/attachments/20080506/7960082a/attachment.htm>