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:
$ 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
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:
$(CPP) -stdlib=libc++ -o $(BIN) $(OBJFILES) $(LIBS) -rpath @executable_path
Then run my own Makefile:
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.