MacOS Version ?

Post by **criezy** » Wed Jan 21, 2009 4:58 pm

I also moved to an Intel Mac some time ago but I still have an old iBook which I think run MacOS X 10.2 (or maybe 10.3) and already has all that is needed to build ScummVM as I used it in the past for that task (although I might need to update some of the libraries).
I will remove the dust and check if it is still working when I come back home this evening. If it is not I may try to configure my Intel Mac for cross-compilation but I make no promises.

I build Intel builts at regular intervals for myself. If I find it is not too difficult to generate universal binaries I am willing to do so at regular interval if needed (read once a month - or once a week at best - but not everyday).

On a side note, is it normal that I have to disable nasm when compiling on my Intel mac? If I do not, all games crash when starting except BS1 and BS2 with a useless crash log (even when I am compiling in debug).

Post by **eriktorbjorn** » Wed Jan 21, 2009 5:04 pm

criezy wrote: On a side note, is it normal that I have to disable nasm when compiling on my Intel mac? If I do not, all games crash when starting except BS1 and BS2 with a useless crash log (even when I am compiling in debug).

Are you using the HQ2x or HQ3x scalers for the games that crash? Off-hand, that's the only thing I can remember nasm being used for in ScummVM. (Without nasm, it uses C versions of those scalers instead.)

Of course, that still wouldn't explain why it's crashing. I'm just trying to narrow it down.

fingolfin · Post by **fingolfin** » Wed Jan 21, 2009 6:13 pm

I am using nasm just fine here. I.e., default settings. Run "which nasm" to make sure it is using /usr/bin/nasm and not some 3rd party version. In addition, "nasm -v" should print something like

NASM version 0.98.40 (Apple Computer, Inc. build 11) compiled on Feb 19 2008

Post by **criezy** » Wed Jan 21, 2009 6:47 pm

I am using HQ3x scaler by default, and if I remember correctly the BS games do not use the scaler set in the general graphic options because they were originally at a higher resolution than the other games (which would explain why they do not crash).

I just recompiled scummvm with nasm to test the games with another graphic mode (i.e. not HQ2x and not HQ3x) and sure enough it works. The problem seems indeed to come from the scaler.
I never tried to look at this in the past because modern computers are fast enough to handle the C version of the scalers anyway.

And to answer fingolfin:
"which nasm" gives me /usr/bin/nasm
"nasm -v" gives me "NASM version 0.98.40 (Apple Computer, Inc. build 9) compiled on Apr 6 2006", i.e. an older version than yours (presumably because I am running 10.4.11 and not 10.5).

I also tested the games using HQ3x with the 0.12.0 build available on the ScummVM website and it works fine (although I don't know if it was compiled with nasm or not).

fingolfin · Post by **fingolfin** » Wed Jan 21, 2009 7:02 pm

Maybe it's a bug in the nasm version with 10.4 ? Although I never had problems when I was still using 10.4. And yeah, hq3x works just fine here, the asm version of it, built using nasm.

Anyway, despite what I wrote earlier, I just wasted a good chunk of my workday on fixing my old cross compilation setup and preparing a 0.13 universal snapshot. It *should* work on PowerPC 10.3.9 systems, but I have no way to test it: <http://www.scummvm.org/downloads/ScummV ... .13pre.dmg>

Post by **criezy** » Wed Jan 21, 2009 7:49 pm

I have tested your build on my Intel mac. It doesn't crash straight away but if I use the HQ2x or HQ3x scaler I get some strange graphical glitches: see this image or this image (both are at the start of Indy FOA). I don't get this isue with another graphic mode. So it seems there is indeed something wrong with the nasm version provided by Apple with 10.4 (or that it somehow got corrupted on my computer).

Edit: I have removed the dust from my PPC iBook (which is running 10.3.5) and tried you build. It doesn't start and I get the following error: "dyld: ScummVM/Contents/MacOS/scummvm can't open library: /usr/bin/libstdc++.6.dylib (No such file or directory, errno = 2)"
And there is only a libstdc++.a in /usr/lib. I am trying to update to 10.3.9 before retrying (but I first need to make some free space on the disk).

wec · Post by **wec** » Wed Jan 21, 2009 8:11 pm

criezy wrote:I have tested your build on my Intel mac. It doesn't crash straight away but if I use the HQ2x or HQ3x scaler I get some strange graphical glitches: see this image or this image (both are at the start of Indy FOA). I don't get this isue with another graphic mode. So it seems there is indeed something wrong with the nasm version provided by Apple with 10.4 (or that it somehow got corrupted on my computer).

HQ2x scaler seems to work just fine on my PPC G4 with 10.4.11.

Post by **criezy** » Wed Jan 21, 2009 8:26 pm

wec wrote:HQ2x scaler seems to work just fine on my PPC G4 with 10.4.11.

nasm is an assembler code to accelerate some operations (it is supposed to be quicker than the same operation written in C, but the drawback is that it is less portable). I don't think it is available on PPC and even if it was it would not be the same assembler code than on an Intel CPU. Therefore I am not surprised HQ2x works on a PPC mac with 10.4, and it doesn't mean there isn't a bug in the nasm provided by Apple.

fingolfin · Post by **fingolfin** » Wed Jan 21, 2009 9:45 pm

criezy wrote:I have tested your build on my Intel mac. It doesn't crash straight away but if I use the HQ2x or HQ3x scaler I get some strange graphical glitches: see this image or this image (both are at the start of Indy FOA). I don't get this isue with another graphic mode. So it seems there is indeed something wrong with the nasm version provided by Apple with 10.4 (or that it somehow got corrupted on my computer).

That looks like it might be an issue between 555 and 565 mode, not one with the scalers as such. Were those pictures made in fullscreen or in windowed mode?

criezy wrote:Edit: I have removed the dust from my PPC iBook (which is running 10.3.5) and tried you build. It doesn't start and I get the following error: "dyld: ScummVM/Contents/MacOS/scummvm can't open library: /usr/bin/libstdc++.6.dylib (No such file or directory, errno = 2)"
And there is only a libstdc++.a in /usr/lib. I am trying to update to 10.3.9 before retrying (but I first need to make some free space on the disk).

10.3.9 is definitely the minimal required version for that build. I don't have the 10.2.8 SDK installed, which would be required for making a build compatible with older systems. But at least 10.3.9 is a free update for any 10.3. user.

Post by **criezy** » Wed Jan 21, 2009 10:13 pm

fingolfin wrote:That looks like it might be an issue between 555 and 565 mode, not one with the scalers as such. Were those pictures made in fullscreen or in windowed mode?

The pictures were made in fullscreen mode. The display is correct in windowed mode.

Edit: however I have another graphical glitch when switching from windowed to fullscreen or fullscreen to windowed mode in the launcher, as shown on this screenshot. I am going to enter a bug report for that one (if there is not already one) as it occurs also on my builds but it is fine with 0.12.0.

fingolfin wrote:10.3.9 is definitely the minimal required version for that build. I don't have the 10.2.8 SDK installed, which would be required for making a build compatible with older systems. But at least 10.3.9 is a free update for any 10.3. user.

The update to 10.3.9 is finished and I can confirm your build seems to work.

DarkVamp · Post by **DarkVamp** » Thu Jan 22, 2009 7:22 am

criezy wrote:I also moved to an Intel Mac some time ago but I still have an old iBook which I think run MacOS X 10.2 (or maybe 10.3) and already has all that is needed to build ScummVM as I used it in the past for that task (although I might need to update some of the libraries).
I will remove the dust and check if it is still working when I come back home this evening. If it is not I may try to configure my Intel Mac for cross-compilation but I make no promises.

I would love You !

Lets give it a try please !

bushwakko · Post by **bushwakko** » Thu Jan 22, 2009 8:52 am

is this this thing (from the osx compile page):

Also note that you should run ./configure with --disable-nasm. The x86 assembly versions of the HQ2x and HQ3x scalers don't work properly on Mac OS X. Since Intel Macs are, by default, fast enough not to need them in either case, it's not a very big deal.

edit: my builds are run with --disable-nasm btw.

Post by **criezy** » Thu Jan 22, 2009 9:52 am

DarkVamp wrote:I would love You !

Lets give it a try please !

You can love fingolfin now, since he already compiled a universal binary build of ScummVM (see a few post above).

bushwakko wrote:is this this thing (from the osx compile page):

Also note that you should run ./configure with --disable-nasm. The x86 assembly versions of the HQ2x and HQ3x scalers don't work properly on Mac OS X. Since Intel Macs are, by default, fast enough not to need them in either case, it's not a very big deal.

I didn't see that.

But I must confess I don't look at that page often. That would explain it.

But I have downloaded a newer version of the Developer Tools (which I think also install a newer version of nasm) and I will see if it fixes the problem.

DarkVamp · Post by **DarkVamp** » Thu Jan 22, 2009 2:02 pm

criezy wrote:You can love fingolfin now, since he already compiled a universal binary build of ScummVM (see a few post above).

I will try it later at home...
Thx a lot !

fingolfin · Post by **fingolfin** » Thu Jan 22, 2009 6:21 pm

I can confirm the problems with hq2x/hq3x in the fullscreen mode, but I doubt that they are due to a bug in nasm. Rather, it's likely an issue of the scalers not correctly switching to 555 resp. 565 mode. I'll have a look at it.

Edit: Actually, looking again, I can *not* reproduce any bugs with hq2x or hq3x on Intel Mac, using the nasm version. I think the comment in the wiki is obsolete. Yeah the GUI graphics are looking funky, but that's the case with all scalers, the bug is in the GUI renderer which doesn't reload images when the overlay format changes.