Did you manage to find a solution?
I have seemingly the same problem with my (non-OpenGL) libsdl1.2 game (Dave Gnukem) on macOS Mojave, attempting to build and run, I get a white window (the game is working, I just canāt see anything)
In fact, every single non-OpenGL LibSDL1.2 game I install using MacPorts (libsdl 1.2.15, the latest) has the same problem (eg . Only OpenGL-based games work (eg bomberclone, supertux etc. - all have just a blank window) ā¦ so it seems to be either a general problem with libsdl1.2 on Mojave, or something in my system configuration.
I hear audio and keypresses work to do things like exit the game, so the games are working, the window is just white.
EDIT (In case this helps anyone) I seem to have possibly found a solution and have gotten my game to basically work (though the frame rate is extremely slow, for reasons Iām not sure but that may be due to an issue in my own code). I got it working by instead building the latest SDL1.2 from its master mercurial repository (this apparently is more up to date than the 1.2.15 source download on the website). Steps I took are basically:
Install Mercurial
$ sudo port install mercurial
Then create a local folder to put the source in:
$ mkdir ~/s
$ cd ~/s
Grab the latest SDL1.2 source code using Mercurial:
$ hg clone -u SDL-1.2 https://hg.libsdl.org/SDL SDL-1.2
$ cd SDL-1.2
$ ./configure
$ make
Then as a post-build step just add the exec permission to sdl-config so we can get the settings:
$ chmod u+x sdl-config
Use ā./sdl-config --cflagsā to get include settings (but then change this to be where its located in my folder, copy to my Makefile)
Use ā./sdl-config --libsā to get lib settings (likewise change the folder to my own path, copy the settings to my Makefile)
Copy the built libSDL.dylib to my own project folder (all the following fiddly steps are only because I want to use the library relative to own location of executable, alternatively you could probably use āmake installā on the built SDL):
$ cp ~/s/SDL-1.2/build/.libs/libSDL.dylib ~/src/gnukem
So in my case I also add " -rpath @executable_path " at my link stage in my own Makefile so I can use my built copy relative to own location of executable:
gnukem: $(OBJFILES)
$(CPP) -stdlib=libc++ -o $(BIN) $(OBJFILES) $(LIBS) -rpath @executable_path
Then run my own Makefile:
$ make
Then the built linked folder is by default āwrongā inside my executable, as one sees by:
otool -L davegnukem
so in order to run it as a post-build step I added the following to update it to look in same folder as my binary for the libSDL.dylib:
install_name_tool -change /usr/local/lib/libSDL-1.2.0.dylib @executable_path/libSDL.dylib davegnukem
Voila, then it runs. But very slow, ~5 frames per second (though itās possible this is a problem in my source code). I built it as x86_64 (as Iām hoping to produce a Catalina release ā¦ these steps are a bit crude but my aim is mainly to produce a DMG for users with a .app they can drag to Applications etc.)
I did thus not try āmake installā or anything - so all the MacPorts libsdl1.2-based ports are still not working.
(As an aside, I did try build Ryan Gordonās āsdl12_compatā library which is a nice idea but I had trouble getting it to compile ā¦ this may be an alternative solution/workaround for others if in future itās working. I did not get sdl1.2mixer working yet.)
I know I āshouldā update my code to LibSDL2 but the reality is thatās a fairly big job and I donāt have the time at this stage.