I'll test later today if I find time. On the SDL forum it was mentioned thatthe new code for Lion has a noticeable performance hit on lower end machines http://forums.libsdl.org/viewtopic.php?t=7355 … der=asc&start=0 (you can also see my report about white/gray screen there).

Dominus wrote:

I'll test later today if I find time. On the SDL forum it was mentioned thatthe new code for Lion has a noticeable performance hit on lower end machines http://forums.libsdl.org/viewtopic.php?t=7355 … der=asc&start=0 (you can also see my report about white/gray screen there).

Thanks - I'm now following that thread.

The machine I'm testing on is certainly not low-end. (I wish I owned it, but I have it only on loan for testing.) It's a brand-new 13-inch MacBook Air, the 1.7 GHz Intei Core i5 model with 4 GB of RAM. It's possible to order a faster machine, but this is the fastest of the stock MacBook Airs.

I'll try it out on another machine, but this isn't one of the "older" machines that someone was talking about in the thread...

hmm, it *IS* slower but for me only a fraction (ha ha) and with cycles set to max it is way faster of course 😀
Tried with up to date Dosbox SVN and the SDL development branch from yesterday with the white/gray fix.
I'm on avery high end iMac (the highest you can get atm)

Dominus wrote:

hmm, it *IS* slower but for me only a fraction (ha ha) and with cycles set to max it is way faster of course

Well, I should have looked more closely at your messages where you said you had cycles set to max. My application has cycles set to 80% in the conf file. When I used the keyboard to increase it to 100% or 105% (the highest it will go) it became very fast - approx. as fast as the old version at 80%.

I had been avoiding max cycles, because it makes this laptop get very hot, but maybe there's no way to avoid it now. I really should have sorted this out before.

Will now build with latest Mercurial code. My application uses SVN from May this year, with my patches applied by hand (I haven't been able to apply them directly from patch files for a while - presumably because of my limited skills here). Probably it's time to apply the patches to current SVN and put out a new build.

One more question: what exports are you using to build SDL these days? I assume I'm using too many (they're listed in an earlier message in this thread).

Dominus wrote:

hmm, it *IS* slower but for me only a fraction (ha ha) and with cycles set to max it is way faster of course :))

Another question about this. I downloaded the current SDL again, reverted the change in which you discovered the error, and built SDL and DOSBox again. This time, I find that even with cycles set to max, everything is very slow. (Fractint shows that black band in the middle). But if I set cycles to (for example) 20000, then everything goes very, very quickly.

I don't understand how "max" or "max 100%" can be so much slower than 20000. I'm trying to figure out what I should specify in the conf file for my application. I used to use cycles=max 80%, which worked well in earlier versions, but that won't work under Lion.

If you have any wisdom about this, I'll be very glad to hear it!

I'm sorry to report more trouble. Dominus, the instructions you gave me worked perfectly to build DOSBox with the new SDL, but the resulting executable was dynamically linked to the SDL dynlib.

I have spent the past few hours trying to use your old instructions to build a standalone excecutable, but I haven't been able to do so. The key part of the instructions seem to be this, from a message you posted some time ago:

You can built Dosbox statically by modifying the makefile.
First type in terminal "sdl-config --libs" (output should be "-L/opt/local/lib -lSDLmain -lSDL -Wl,-framework,Cocoa") then type "sdl-config --static-libs" (output should be "-L/opt/local/lib /opt/local/lib/libSDLmain.a /opt/local/lib/libSDL.a -Wl,-framework,OpenGL -Wl,-framework,Cocoa -Wl,-framework,ApplicationServices -Wl,-framework,Carbon -Wl,-framework,AudioToolbox -Wl,-framework,AudioUnit -Wl,-framework,IOKit"). In the makefile(s) replace the first output with the second one... then make

I can't figure out how to modify this to work with the current SDL code that I keep in a separate directory. I won't waste your time with my failed attempts.

Also, will I need any additional exports? The ones I'm using (at your suggestion) are these:

export CC='/usr/bin/gcc-4.2 -arch i386'
export CXX='/usr/bin/g++-4.2 -arch i386'
export GCOV='/usr/bin/gcov-4.2 -arch i386'

and my ./configure command (again at your suggestion) looks like this:

./configure --prefix=/opt/local --with-sdl-prefix=/Users/edward/Development/SDL-forDB

I'm very hesitant to ask your help again after all the effort you've already put into this. But I hope the puzzle is interesting! Thank you for any help you might be able to give.

Well, after begging for help in building a standalone DOSBox for OS X, with the latest SDL, I seem to have succeeded in doing exactly that. It was dumb luck, not skill, that did it, and I probably did it in the stupidest possible way.

Here's what I did. In the makefile in the top-level directory and in the src directory, I replaced the existing LIBS = line with this:

LIBS = -L/Users/edward/Development/SDL-forDB/lib/ /Users/edward/Development/SDL-forDB/lib/libSDLmain.a /Users/edward/Development/SDL-forDB/lib/libSDL.a -Wl,-framework,OpenGL -Wl,-framework,Cocoa -Wl,-framework,ApplicationServices -Wl,-framework,Carbon -Wl,-framework,AudioToolbox -Wl,-framework,AudioUnit -Wl,-framework,IOKit -framework OpenGL -framework CoreMIDI -framework AudioUnit -framework AudioToolbox

The resulting build ran successfully in a clean system.

What I don't understand is this. When I run the executable on my development system, the console doesn't show any error messages when I switch to and from full-screen mode. When I run the executable on a clean system, and switch to full screen mode, this message appears in the console (preceded by the date and time)

dosbox[3774:407] invalid fullscreen drawable

But it goes to full-screen correctly. What might be happening here?