Found this: http://forums.libsdl.org/viewtopic.php?p=2914 … 28fae6fd7d97e09
and this:
http://lists.apple.com/archives/quartz-dev/20 … r/msg00014.html

I've done some debugging on this issue. […]
Show full quote

I've done some debugging on this issue.

CGDisplayBaseAddress() has been deprecated in 10.6 and while it still exists on 10.7, it now returns NULL instead of the display's base address. SDL_SetVideoMode() ends up calling a number of deprecated CG functions via the Quartz implementation including CGDisplayBaseAddress(). It is SDL_SetVideoMode()'s call to SDL_ClearSurface() that actually causes the crash when it tries to clear the frame buffer memory at address zero.

A new set of APIs has been added as of 10.6 and while they let you capture a display, they do not allow direct frame buffer access. Quartz or OpenGL are the only methods that can update a captured display.

The work to switch to the new APIs in the context of SDL is not trivial.

I downloaded a snapshot of the SDL 1.3 sources and see that, sadly, the Mac OS X implementation is still using the deprecated functions.

-Kirk

Can you try another output in dosbox.conf like opengl?

Heh seeing the two main API suckers mentioned in one thread feels nice 😀

DosFreak wrote:

Can you try another output in dosbox.conf like opengl?

output=opengl works in full screen, but not nearly as well as =surface, which is what I had been using for the system I've been working on (which is here: http://www.columbia.edu/~em36/wpdos/wpdosmac-dosbox.html).

With output=opengl, a text-mode screen is not centered in the Mac's full screen, but positioned toward the upper left corner. As far as I can judge, the x position and the y position of the upper left corner are the same number, and that number is calculated this way: y = the height of the screen minus the height of the text-mode box itself. (I hope that makes sense.) So text mode looks very weird, though VESA graphics look fine.

EDIT: Actually, my guess at the algorithm seems to be completely wrong. If I change the number of lines in the text screen, the text screen is positioned differently, but it's always left of center, and in most cases pushed toward the bottom of the screen. The least bad I've seen is a 50-line mode - thanks to a patch helpfully provided (I think) by h-a-l-9000 - which is full-height on my MacBook, and pushed all the way to the left.

Does this help clarify what's going on? I'll be away at various times during the day, but will try to answer questions as soon as I see them.

Edit: output=quartz doesn't work at all; DOSBox crashes after switching video modes a few times.

Edit again: Is there a way to center the text mode screen? I can't see anything in the conf file, but I don't know my way around it like an expert.

Edit again: Is there a way to center the text mode screen?

Is it off-center only for opengl (respectively openglnb)?

wd wrote:

Edit again: Is there a way to center the text mode screen?

Is it off-center only for opengl (respectively openglnb)?

opengl and openglnb produce exactly the same off-center results.

hmm, output opengl does not screw things up for me here (Lion as well).
fullscreen=false
fulldouble=false
fullresolution=original
windowresolution=original

But I can confirm the crash (and sadly this is true for Exult, Pentagram and Xu4 as well 🙁

I'm pissed!

Dominus wrote:

hmm, output opengl does not screw things up for me here (Lion as well). fullscreen=false fulldouble=false fullresolution=origina […]
Show full quote

hmm, output opengl does not screw things up for me here (Lion as well).
fullscreen=false
fulldouble=false
fullresolution=original
windowresolution=original

The off-center screen occurs only in VGA/SVGA text modes (25-line, 43-line, etc.). Graphic modes are centered correctly. (All this refers to full-screen mode, of course. Same effect occurs if fullscreen=true, by the way.)

Would a windowed mode set to desktop resolution be a suitable workaround until or if this is fixed?

DosFreak wrote:

Would a windowed mode set to desktop resolution be a suitable workaround until or if this is fixed?

I can't speak for anyone else, but for the application I've put together, it probably wouldn't help much. Again, I'm speaking ONLY for my own project, and I'm certain that other people will feel differently. The problems are (1) that graphics in windowed mode are intolerably slow, while they are very quick in full-screen mode, and WordPerfect for DOS uses both text- and graphic modes, and (2) WordPerfect uses all four states of the Fn keys, and these work smoothly (without interference from what the OS does with the Fn keys) only in full-screen mode.

The off-center text-mode screen is an annoyance, not a fatal problem, of course.

emendelson wrote:

Dominus wrote:

hmm, output opengl does not screw things up for me here (Lion as well). fullscreen=false fulldouble=false fullresolution=origina […]
Show full quote

hmm, output opengl does not screw things up for me here (Lion as well).
fullscreen=false
fulldouble=false
fullresolution=original
windowresolution=original

The off-center screen occurs only in VGA/SVGA text modes (25-line, 43-line, etc.). Graphic modes are centered correctly. (All this refers to full-screen mode, of course. Same effect occurs if fullscreen=true, by the way.)

I'm daft, can you give an example? Because when Dosbox starts everything is ok.

Dominus wrote:

I'm daft, can you give an example? Because when Dosbox starts everything is ok.

The best thing I can do is invite you to download and install my application (it won't harm your system):

http://dl.dropbox.com/u/271144/WPDOSBox%20Installer.dmg

It will refuse to run if you don't add the WordPerfect wp.exe and and wp.fil files to the DOSDisk that it installs. If you don't have either WPDOS 5.1 or WPDOS 6.2, then edit the AppleScript in the WPDOSBox51 or WPDOSBox62 application bundle to comment out the section that tests for the existence of wp.exe and wp.fil. If that doesn't work, I'll try to prepare a copy that doesn't require those files and will post a link to it tomorrow. I'll be away from my development machine for the rest of the day.

In my application, Cmd-Enter toggles between windowed and full-screen mode, not Alt-Enter, by the way.

does lock stock Dosbox 0.74 behave the same way with the WordPerfect stuff and opengl?

Btw. through a benchmark I found OpenGL faster than Surface. That is in a 32bit built. SVN in 64bit is much much slower, no matter what 😀

Dominus wrote:

does lock stock Dosbox 0.74 behave the same way with the WordPerfect stuff and opengl?

Have now tested this, as you asked, by temporarily setting up my Application Bundle so that it always runs stock Dosbox 0.74, not my patched version. The answer is: Yes, with output=opengl, Dosbox does not center the text screen. What happens on my 13-inch white MacBook (1280x800 display) is this:

When I switch to full-screen mode, the 25-line text screen is surrounded on the left, top, and right by a black band, but the foot of the 25-line text screen is adjacent to the bottom edge of the monitor. It is centered left to right (with black bands on both sides), but it is not centered top to bottom - all the black space is at the top, none is at the bottom.

I hope that's clear. If not, please ask and I'll find some way of making it clearer!

Also, I've created a version of my application that will show the problem, but does NOT require the WordPerfect program files. (This version uses my patched version of SVN; it is NOT set up to run stock 0.74, but can easily be modified to do so by editing the AppleScript of the application. The application bundle contains both the patched and stock versions.)

Download the DMG as in the link below; run the Install DOSDisk script, and then copy the test version of the WPDOSBox application. You can switch the text mode screen size by entering the commands 25lines, 43lines, and 50lines at the DOS prompt. Here is the link if anyone is interested:

http://dl.dropbox.com/u/271144/WPDOSBox%20Tes … 20Installer.dmg

Please keep in mind that, under Snow Leopard and Lion, this automatically uses a custom version of SVN that includes patches and suggestions very generously provided by wd, h-a-l-9000, HunterZ, dominus, ripsaw8080, TeaRex, and ykhwong. But, as I mentioned earlier, the text mode screen is not centered even with the stock 0.74 version.

I hope I haven't wasted bandwidth on this issue.

There seems to be patched version of SDL 1.2 for Lion, but I don't know if this will help:

http://forums.libsdl.org/viewtopic.php?t=7355

You could try yourself. I'm away from my mac for three weeks until I can test both your opengl problem (I still can't visualize but that is my problem by being not a native English speaker and general problems to visualize descriptions) and the patched SDL (looking forward to that since I provide snapshots for three projects).

OK, I have sdl installed via MacPorts, and I'll experiment with replacing the MacPorts version with this patched one. This may be too difficult for me, but I will do my best.

Meanwhile here is an image that explains the problem caused by output=opengl, with an explanation below it. Note that the blue 25-line text screen is NOT centered on the black background. (By the way, the image is a fake - I added the black background to a DOSBox screen capture. The dimensions of the black background are approximately the same as the real dimensions, but they are not exact. But you can see how the text screen is NOT centered on the monitor.)

Here are my settings for sdl:

[sdl] fullscreen=0 usescancodes=1 autolock=1 fulldouble=0 usescancodes=1 ConsoleWindow=1 sensitivity=100 output=opengl # output= […]
Show full quote

[sdl]
fullscreen=0
usescancodes=1
autolock=1
fulldouble=0
usescancodes=1
ConsoleWindow=1
sensitivity=100
output=opengl
# output=surface
windowresolution=original
fullresolution=original
priority=higher,normal
mapperfile=dosonlykeys.txt
DOSBoxlanguage=default

Under Snow Leopard, with the setting output=surface, when I switched to full screen mode, the 25-line text screen was centered on the black background. The black stripe was equal in width above and below the 25-line screen, and equal in width to the left and right of the 25-line screen.

Under Lion, the only way to switch to full-screen is with output=opengl or openglnb. When I switch to full-screen mode, the 25-line screen is NOT centered on the black background, but appears as shown above. Different text-screen sizes (e.g. 43-lines, etc), are also non-centered, but in different ways.

Please let me know if the image makes the problem clear. It is - as you say - very difficult to describe in words.

As expected, DOSBox SVN builds correctly in Lion with updated Xcode and MacPorts. Now to try to figure out how to use a patched SDL...

A nice alternative to dosbox in Lion is Boxer: http://boxerapp.com/
So far no problems. Very nice interface. Sliders to adjust CPU and Framerate.

Boxer is not an alternative, it's a great frontend for Dosbox 😉
(though frontend doesn't do it justice 😉). Has Boxer been updated to work fullscreen in Lion?

On topic, I tried the patched SDL and it works nicely for Exult, Pentagram and XU4.