[Scummvm-devel] SDL 1.2.8 and Win98

Max Horn max at quendi.de
Wed Jan 5 16:51:24 CET 2005


Am 05.01.2005 um 23:10 schrieb Ori Avtalion:

> Hey,
>
> Someone named "normal" has reported a problem running FOTAQ 0.7.0 on 
> Windows 98. After a bit of research, the blame was put on the new 
> versin of SDL, included in the windows package.

I strongly recommend following the normal channels, then, i.e. file a 
bug report.

> Running FOTAQ using any version of ScummVM (release, CVS) with SDL 
> 1.2.8 and on Win98 causes a crash. SCUMM games are unaffected. 
> (BASS/simon have not yet been tested)
> I assume FOTAQ uses several SDL functions that aren't in the SCUMM 
> implementation.

Nope. First off, FOTAQ uses, like SCUMM, the OSystem API -- not SDL 
directly. And I am pretty sure that SCUMM uses about all of the OSystem 
APIs (mainly because OSystem was designed around SCUMM).

So to me, it appears quite unlikely that this problem is caused by SDL 
1.2.8, although of course I can't exclude the possibility.. I am 
awaiting hard facts for now: The only way to "prove" that it is indeed 
a SDL 1.2.8 problem would be to make a build of ScummVM 0.7.0 against 
SDL 1.2.7, run that on Win98, and determine whether it crashes or not.

The fact that an older build using SDL 1.2.7 could have many other 
reasons: like a change in FOTAQs engine (there were some) causes it; or 
the release binary is an optimized build, while that older build 
wasn't, etc.


> With 0.7.1 on the 7-day horizon, I think the following must occur:
> * Test other games and engines on Win98.

Only if we want to actively support Win98. Personally, I am not 
interested in that so much... if we can support win98 w/o much pain, 
that's fine, but that's about it. Just my two cents, though, if 
somebody wants to spend an effort on this, I won't object. But I am not 
going to halt a release for this....

> * Analyze and fix the problem - It's probably in SDL, but I can't look 
> into it myself.

I have read the conversation in the channel logs, and I don't 
understand why SDL was blamed so quickly... I can easily think of 
multiple other explanations... not proper scientific behaviour ;-)

> * If it is not fixed, or if it requires an SDL fix that will only be 
> released at a later date, provide the SDL version from 0.6.1b with the 
> new Windows bundle. Are there any critical reasons for the use of SDL 
> 1.2.8?

For the Windows version, i guess SDL 1.2.7 might be OK, I don't see 
critical fixes in the SDL 1.2.8 changes list. However, I am not at all 
convinced that this is an SDL issue.


Bye,

Max





More information about the Scummvm-devel mailing list