<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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...<br>
<br>
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...<br>
<br>
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?<div class="Ih2E3d">
</div></blockquote><div><br>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 <i>why</i>, <i>what causes</i> 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 <i>usage</i> pattern that determines whether or not one is acceptable or the other. What would help is an explanation of <i>why</i> 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 <i>is the way in which DirectInput is being used</i>.<br>
<br>So, now that we know both are using the exact same API to perform their work, let's move on?<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I don't think that problems with ioq3 should be fixed in SDL.<div><div></div><div class="Wj3C7c"><br>
</div></div></blockquote><div>Let's follow some logic here.<br>Quake3's mouse code is "good".<br>Quake3 uses DirectInput for mouse interfacing.<br>IOQuake3's mouse code is "bad"<br>
IOQuake3 uses SDL for mouse interfacing.<br><br>Your conclusion:<br>The problem is in IOQuake3 and that the problem resides in IOQuake3, not SDL.<br><b>This does not logically follow</b>.<br>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.<br>
But that aside...<br><br>Once again, you've yet to explain how the code differs. <b>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.</b><br>
<br><i>If all you want to do is "fix" (hack) old code from Quake3, then do so</i>.
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.<br>
<br>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?<br>
<br>Patrick Baggett<br><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div class="Wj3C7c"><br>
---<br>
To unsubscribe, send a blank email to <a href="mailto:quake3-unsubscribe@icculus.org" target="_blank">quake3-unsubscribe@icculus.org</a><br>
Mailing list archives: <a href="http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?50" target="_blank">http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?50</a><br>
<br>
<br>
</div></div></blockquote></div><br>