VOGONS


Reply 20 of 46, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

OK, I changed this line in the makefile in the main directory and in src, as follows:

LIBS = -L/Users/edward/Development/SDL-forDB/lib -lSDLmain -lSDL -L/opt/local/lib -Wl,-framework,Cocoa -lpng -lz -lX11 -framework OpenGL -framework CoreMIDI -framework AudioUnit -framework AudioToolbox

Still no build, alas.

Reply 22 of 46, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie
Dominus wrote:

I'll try when I'm home since I have another sdl prefix handy.
Please copy/paste the make error

Thank you again. I've posted two versions of the make output, just to make sure you had all the information. First is the output when I ran

make > makestdout.txt

http://dl.dropbox.com/u/271144/makestdout.txt

next is the actual output in the terminal, cut and pasted from the terminal window:

http://dl.dropbox.com/u/271144/maketerminaloutput.txt

I hope they tell you more than they tell me...

Reply 24 of 46, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie
Dominus wrote:

Can't find png stuff. More in two or three days ;)

I'll be traveling - and all this is something you're doing out of pure generosity, so there's no pressure - only gratitude for all you've done so far.

Reply 25 of 46, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

It's a puzzle I think I can solce. I like those. I'm no developer but picked up compiling stuff and like to solve such problems 😉

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 26 of 46, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

it *builds* fine for me with a special prefix but when giving the ldflags and the cflags it messes up.
SO! with a macports installation and a special SDL prefix I got it to work like this:

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'
./autogen.sh
./configure --prefix=/opt/local --with-sdl-prefix=pathtothespecialsdlprefix
make clean
make

(gcov is probably not even needed)

Reply 27 of 46, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

You are amazing - I simply saved your commands as a script, chmod-ed it, ran it - and got a perfect executable that goes to full-screen flawlessly. Thank you a thousand times!

Reply 29 of 46, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

Trouble, alas. The new version is so slow in graphic mode that it is almost completely unusable. Is this the effect of the new SDL version, or is there anything that can be done to fix it? I don't expect that there is any easy answer to this. Thank you again.

Reply 30 of 46, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

In an earlier message, you wrote:

Dominus wrote:
So to build SDL for 32bit pass along the same exports as you do for dosbox. then run ./autogen.sh then ./configure --enable-stat […]
Show full quote

So to build SDL for 32bit pass along the same exports as you do for dosbox. then run ./autogen.sh then
./configure --enable-static --enable-joystick --enable-cdrom --disable-video-x11 --enable-video-cocoa --enable-video-opengl --without-x --prefix=pathtomyspecialSDLbuild
(take not of --prefix=pathtomyspecialSDLbuild this is important to not pollute your macports tree, choose a folder for your develeopment branch of SDL)
then
make
make install (this should put everything into --prefix=pathtomyspecialSDLbuild)
.

Did you follow this procedure when you built SDL? I want to make sure that I use the same procedures that you use. Thank you again.

Reply 32 of 46, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

Thank you again - I hope this isn't the kind of problem that only shows up on my system.

The difference in speed is fairly spectacular. With the system that I built using your instructions earlier this year, WordPerfect 5.1, running in full-screen mode, switches from text mode to graphic-mode print preview (VESA 1280x1024) in 1 to 2 seconds at most. With the new build, it takes more than 100 seconds.

Again, I hope this is an interesting enough puzzle to justify the time it takes you!

Reply 33 of 46, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

Here are some more details. Following what you said in an earlier message about building SDL with the same exports that I had been using to build DOSBox, I've been using this script to build the new SDL:

#!/bin/sh […]
Show full quote

#!/bin/sh

export CFLAGS='-I/opt/local/include -O2 -arch i386'
## export CXXFLAGS=$CFLAGS
export CPPFLAGS=$CXXFLAGS
export LDFLAGS='-L/opt/local/lib -O2 -arch i386'
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'

## try out these AFTER ones above
export CXXFLAGS='-O2 -mdynamic-no-pic -arch i386'
export MACOSX_DEPLOYMENT_TARGET='10.6'
export F90FLAGS='-O2 -m32'
export OBJC='/usr/bin/gcc-4.2 -arch i386'
export FCFLAGS='-O2 -m32'
# export INSTALL='/usr/bin/install -c'
export OBJCFLAGS='-O2 -arch i386'
export FFLAGS='-O2 -m32'

./autogen.sh

./configure --enable-static --enable-joystick --enable-cdrom --disable-video-x11 --enable-video-cocoa --enable-video-opengl --without-x --prefix=/Users/edward/Development/SDL-forDB

make clean

make

make install

Using this script to build SDL, and then your recent instructions for building DOSBox, I built that slow-in-graphics-mode build that I described yesterday.

Since then, I've downloaded the latest source for SDL 1.2, and used the same SDL-building script for building it, and then used the same DOSBox-building script that I used yesterday to build DOSBox. The result is that, with the new SDL source, when I switch to full-screen in DOSBox, the screen becomes white - nothing else is visible. In full-screen mode, anything I type seems to be ignored.

However, if I switch BACK from full-screen to windowed mode, then the window is still entirely white, but I can type "exit" and close DOSBox normally.

I kept last week's version of the SDL code on my system, so I was able to confirm that whatever is going wrong is something that occurs only with the current version of the code.

Very curious!

Reply 34 of 46, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

hmm, I got the same result with the white screen with current SDL dev code.
Try the snapshot download from the 5th of August from their download page whether that also has the slowness (it doesn't have the whiteness of death 😀)

I know I asked in another thread but how do I check for the slowness?

Reply 35 of 46, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie
Dominus wrote:

hmm, I got the same result with the white screen with current SDL dev code.
Try the snapshot download from the 5th of August from their download page whether that also has the slowness (it doesn't have the whiteness of death :))

I know I asked in another thread but how do I check for the slowness?

Will try the 5th August snapshot later tonight - thanks for the suggestion.

As for checking slowness, perhaps the simplest thing to do is run the DOS version of FractInt from:

http://www.fractint.org/

I haven't tried FractInt yet in my application, but the effect is obvious with WordPerfect. If you're interested in trying it with WordPerfect, I have quite a few legal copies that I can spare, and I can send you my complete application with instructions. Just let me know.

Reply 36 of 46, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

if you revert this change:http://hg.libsdl.org/SDL/rev/8e0dd46ad0e0 in up to date SDL code the white/gray screen issue is gone. Currently reporting this to the SDL devs.

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 37 of 46, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie
Dominus wrote:

if you revert this change:http://hg.libsdl.org/SDL/rev/8e0dd46ad0e0 in up to date SDL code the white/gray screen issue is gone. Currently reporting this to the SDL devs.

Will do - thanks!

Reply 38 of 46, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

about fractint, can you be more specific what to do with the program and what to expect and what actually happens? Sure I can start it and in the first mode everything moves quite slowly but so does Dosbox 0.74. With cycles max it's quite fast.

Reply 39 of 46, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

First, your reversion worked perfectly. Now I can build DOSBox without getting the white-window-of-despair when I switch to full-screen. Unfortunately, it's still very slow.

Here's one way to use Fractint to test speed. I'll spell out every detail (you won't need all the details, of course) in case anyone else wants to experiment with it.

1. Install Fractint to a folder, and mount the folder in DOSBox (or mount a folder that contains the Fractint folder).

2. Alt-Return to full-screen mode (with builds made BEFORE the new SDL arrived, you will need to have output=opengl or =openglnb; with builds made WITH the new SDL, you can have output=surface or, of course, opengl etc.)

3. Run Fractint.exe.

4. While the credits are scrolling, press Shift-F7 to draw a fractal in VESA 1024x768x256 mode. Pressing Shift-F7 is the equivalent of this sequence of keystrokes: press Esc to reach the menu; press Del (or select the menu item "Select Video Mode"; scroll down to "SF7 SuperVGA/VESA Autodetect 1024 768 256 etc."; press Return.

5. A fractal image will appear on screen and immediately start redrawing until it reaches full resolution. Now, here's what to watch for:

When the image first appears, either (a) or (b) will happen:

(a) In the old builds (output=opengl or =openglnb required), the screen will almost immediately fill with the image and start redrawing. BUT:

(b) In the build I made today, the image is written very slowly from the top and bottom, gradually replacing a black horizontal band that appears across the middle of the screen. On my system, it takes almost 30 seconds for the black band to be completely replaced by the image. The same slowness occurs with output=surface and output=opengl.

I hope that's reasonably clear. If not, please complain, and I'll try to see if I can find a better way to explain it.