|
|
|
|
| Welcome, Guest | Home | Search | Login | Register | |
| Author | SDL2 for PPC MacOS 9 efforts... (Read 66238 times) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
lauland
512 MB  Posts: 674 Symtes 7 Mewconer! |
Reply #15 on: March 09, 2025, 19:44
Ok...next steps...get back to where I was before I lost my code: Add all opengl code back in, only stubs for now, but the hooks will be in the driver at least. Add back in handling multiple event types, but just keypresses and mouse clicks for now, probably. (Not sure how to handle coordinates for mouse movement). Separate out the "mac blit" function again. Handle more than one rectangle that needs updating. Add pixel depth as a variable again...right now it is hard coded, the code I lost had it separate. Try and reproduce the code up to the point where I was getting the "garbage" display...even though I know it isn't anywhere near correct, it was displaying SOMETHING of what it was supposed to. Look (again) at the drivers for other platforms for clues on how the driver is supposed to work. I used the QNX version as a skeleton to build on, which was a good idea because it was so small, but seeing how the other platforms work will help. Unfortunately, all the other drivers that are small are for platforms I know nothing about...the drivers for ones I do, like Windows, Linux, MacOS X and Amiga, are very large and complicated and hard to understand, they all do SO much and have lots of moving parts. They also all support OpenGL, which is a very large subject, and a bit messy on Classic MacOS and one I'd like to put off tackling as much as possible. ---- I built SDL2 for Linux, so I can understand more about the build process and the code itself. No big surprises expected or found. I also tried SDL12-compat (on Linux), which is an SDL 1.2 compatibility layer to allow code for it to use SDL2 libraries. It is a weird beast! Instead of being a thin layer, it actually builds an entire SDL 1.2 library and headers, that is actually calling SDL2. It will be VERY useful for testing the MacOS 9 SDL2 since I know oodles more about SDL 1.2 than I do about SDL2. I also built SDL3 for Linux, but haven't even tried it out yet. It isn't distributed standard with Ubuntu (or probably ANY Linux distros). Depending on how different it is from SDL2, yeah, I might even try a MacOS 9 version...or at least "sketch one out". I don't expect that to bear any fruit, but will at very least take a look at how feasible it would be. I'm also looking at the code from DevilutionX that allows it to run on Amiga...the game itself is supposed to be SDL2, but the Amiga version uses a tiny shim layer to map a few things and add needed funcs, so it runs on SDL 1.2...(like classic MacOS, there is no SDL 1.2 for m68k Amiga). If I pull this code out, we MIGHT be able to use it to create a tiny library and at least try getting something that uses SDL2 to work on classic MacOS. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Last Edit: March 09, 2025, 19:49 by lauland
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #16 on: April 09, 2025, 17:10
|
http://macintoshgarden.org/apps/sdl2-macos-9-rough-draft Wh00t wh00t! It works! (At least what is there works...much more needs to be done)
|
Bolkonskij
|
Administrator 1024 MB  Posts: 2024 
Reply #17 on: April 09, 2025, 17:23
|
Wow! You've got it to work. That's amazing. What about some "simple" SDL2 ports. Do they work too?
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #18 on: April 09, 2025, 17:56
|
Several of the tests that come with it work (see the screenshots). Any basic non-OpenGL drawing probably will "just work". Event handling needs to be done, the mac part is there, but the SDL events aren't set up at all. It just handles Command-Q. Haven't even started audio. Just using the "dummy" versions of everything except the "video" driver (which also handles events). Debug output is in stderr.txt Way way way more work would need to be done to get an actual game working. Most games use SDL "add-ons" like SDL_image, SDL_mixer, etc, so SDL2 versions of those will be needed for any "real game". I'd be thrilled beyond compare if I didn't have to do all the work solo, but am realistic. If I end up being the only one to work on it, don't hold your breath...
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #19 on: April 10, 2025, 18:42
|
Now on m68k MacOS 7.6 too! The required Mac version depends on the compiler used to build. CW7 I think will build apps that require 8.5, but CW6 older. For M68k it is, obviously, older, but maybe PPC too. FYI I trashed all the code I was trying using offscreen GWorlds, and copied some code from an old Pac-Man clone I'd written years ago, which I knew was rock solid and ran on EVERYTHING. It uses a hand created Pixmap for the buffer, and just CopyBits() it to the window.
Last Edit: April 10, 2025, 18:43 by lauland
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #20 on: April 17, 2025, 16:19
|
Much work continues. Added more tests, now builds carbon, CodeWarrior 8, etc. Mouse clicks in theory are working, but I'm not sure. Keyboard scancodes may or may not be right, but I've done a lot of work on them. Cleaned up all the code, fixed spacing. Started sketching out a blit that just straight copies to video memory, instead of using QuickDraw, which has the potential to be super fast. Added switch to turn off debug printfs. Got the dummy joystick working, but only in CW8 and carbon for now. Added github repo. Etc etc etc.
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #21 on: April 17, 2025, 19:22
|
@lauland These are very exciting!! I can't wait to try out all of these tests on the mini tomorrow! (I wish I could just skip work!) Will grab your latest SDL 1.2, 2.0 and 3.0 from the S7T hotline tomorrow at the first opportunity!! Then recompile and run everything I can, and see how it goes in their current state!
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #22 on: April 22, 2025, 16:10
|
Now builds with retro68. I stole the Makefiles from AmigaOS 4 and OS/2 to get it working! The Makefile for the tests is still a bit broken, but almost all now build and run, so it's much easier to see what doesn't work and still needs to be done. Will fix this soonish. Like I did for SDL 1 and the game ports, there's "Makefile.r68" for m68k and "Makefile.r68ppc" for ppc. (So "make -fMakefile.r68ppc" etc). Use the "-i" flag with make when building the tests, as it will get stuck building some, but you can ignore the errors and allow it to build many more.
|
cballero
|
1024 MB Posts: 1181 System 7, today and forever
Reply #23 on: April 23, 2025, 20:51
|
Wow! Talk about unstoppable! Bravo my friend!! 
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #24 on: April 24, 2025, 15:57
|
Yeah...just TRY and stop me! I have ports of SDL2_image, SDL2_mixer, and SDL2_ttf in the works, very early but lots of progress, all done using Retro68 (and not CodeWarrior so I didn't have to torture myself setting up projects). Most games use at least one of them, and many all three. So they'll be needed for any "real" SDL2 game ports to MacOS 7/8/9. It was "relatively easy" to get their standard gnu autoconfig Makefiles to work. They build, produce libraries and their test apps, but all the test apps just immediately quit when started, with no output even to logs. This is actually expected, and not a bad sign, for two reasons. First, all the test apps (showfont, showimage, playwave, etc) expect command line parameters and there's no command line on MacOS 9. SDL 1 has a clever dialog box that comes up if you hold down the command key when launching an app as a workaround. I'm going to try "borrowing" it. Second, Retro68 doesn't have as good a "console" for standard io as CodeWarrior does, much trickier to use. Also, I have standard io redirection for the log etc in SDL2 only init'd once a program opens the video driver. So any output before that is currently lost. If they don't open the driver, but just print a message, that is never seen. Both these reasons are due to me attempting to not have an "SDL_main" for this SDL2 port. SDL_main is a "fake main" that is run before the app's main and can set up all sorts of things. Many ports of SDL 1 and 2 (and 3) need this, and I was trying to avoid it, but looks like one will probably be needed. I'm going to try to use the one that Mac SDL 1 comes with, with heavy modifications of course. That includes the handy "command line parameter dialog box" so it will come along as a bonus.
Last Edit: April 24, 2025, 16:00 by lauland
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #25 on: April 27, 2025, 18:50
|
Got the SDL1 SDL_main working for SDL2, which fixes a LOT of the standard IO problems. Can't test the dialog box for command line on Linux since "Command click launching an app" doesn't seem to work as the command key is mapped to alt, and alt clicking on the icon is swallowed by the Linux gui. Will need to test on a real mac, but expect it to mostly work. SDL_main does something really clever storing whatever command line you might type in, and if you choose the DrawSprokect driver vs QuickDraw (which is obviously not in SDL2 but the choice is there), in as "prefs" in a resource in the app you build with SDL. That seems to be broken a little, as it currently THINKS it is reading prefs, even when the resource isn't actually there, so the command line is hacked out for now. I now use the same resources for SDL2 that SDL1 had, so could have a mac menu, etc at some point. The resources are there, but not used yet. Found I actually DIDN'T have the dummy drivers for a bunch of things, but instead had them disabled. This meant the APIs weren't available. Now have ALL the dummy drivers available active. This is a bunch of things that will probably never get done on MacOS 7/8/9 such as haptic, sensors, sophisticated game controllers, etc. But at least the APIs are there now. Joystick dummy also, and for that I might be able to adapt the SDL1 driver using Input Sprockets. Joysticks are fun, so that is something I might actually work on at some point. Also am now using "RetroConsole" for standard io output, when it's not redirected to a file, for Retro68 builds. Using that, and the more better standard io handling in SDL_main means the second useless window that is opened no longer needs to appear. Created scripts for linking on retro68 since that step is always painful, and they automatically include the right libs and resources. Reorganized the files a bit and named some stuff better, and the retro build now copies the built lib and include files to the root of the folder. This is for building apps that use SDL2 easier, and you don't have to copy them to your Retro68-build folder anymore. Tweaked memory requirements of built apps to now be 6m required, 32m preferred, as I've been testing SDL2 in MinivMac which only has 8m of ram. It looks like 6m is plenty for more trivial apps, but probably not nearly enough for some games. Enabled OpenGL and can now see my driver's stubs being called. It actually tries opening windows at least 4 times, I believe it is trying the different versions of OpenGL (such as ES and ES2) and all (of course) fail, but it then falls back to the software renderer, which is nice. In SDL2 there's both OpenGL as we knew it in SDL1, but also an OpenGL renderer, which is being built and probably trying to be used. Amusingly (at least to me) the PPC retro68 build is crashing, but the m68k one is rock solid, even in 7.5 (haven't tested in 7.0, but no reason it wouldn't work). I am thinking it might be due to the OpenGL work, and it is calling a NULL pointer function, tho wonder why it wouldn't also do that for m68k. Could be something else I broke somewhere else!
Last Edit: April 27, 2025, 18:53 by lauland
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #26 on: May 02, 2025, 20:57
|
I took all my changes/additions, and re-merged them into a fresh clean copy of SDL 2.3 from their github. A lot of the tiny little fixes turned out to be only needed for CodeWarrior, and I am temporarily leaving them out, as I've been having a great time with Retro68. I did this so now the same source tree builds and works for MacOS 9, modern MacOS X (on apple silicon at least) and Linux. It should work for all the other officially supported platforms, but those are the only ones I'm testing as they are the ones I actually use daily-ish. It looks like SDL2 officially only supports MacOS X 10.7 or higher...and I'm wondering how well it even supports versions that old. I believe I have 10.8 on an older machine and will see... ---- Found the PPC crash was in SDL_main, so I've made SDL_main optional, although standard io is handled much nicer if you use it. You'd also get the dialog box to enter command parameters, but I've never tested it. I wonder where the problem is, the same code is fine in SDL1...will want to test it on a real PPC mac so I can use MacsBug to see where it crashes. From my other post about Retro68 you can see I've got SDL2 building on PPC Tiger using the TigerBrew version of Retro68, with some trickery for the linking of the apps. Otherwise it works very well. Did some more work into looking at what OpenGL support would entail. Unsure if it's possible with the ancient version of OpenGL that MacOS 9 has or not. I will probably need to get loadso support working too, which will be a major pain. I'm going to try copying over the SDL1 OpenGL code and will start hacking on that. Started work on the audio driver. There now is a "macosclassic" one that has all the plumbing, but none of the functions do anything. Things are way too different to be able to use the SDL1 code in any straightforward manner, but I can hopefully copy parts. This isn't necessarily desirable, as the classic Mac SDL1 driver is a real mess. There are actually two different drivers in there...it looks like they abandoned working on it before finishing. It'd be better for me to write one from scratch, but I don't know audio as well as I do graphics. Looked at performance, and it is not good using the software renderer. I started work on a bare metal blit function that copies straight to video ram and will likely work more on it. It will be painful because when you're doing stuff like that tiny mistakes cause crashes. ---- Did a a lot of testing to see exactly how much memory is needed, on an 8m MiniVMac running 7.5. The OS isn't the problem, and will probably even run in System 6, but 8m is just not enough, at least with System 7.5. The OS itself just takes up too much room. I'm going to try on System 7.0/7.1 and there might be enough memory free. Heck, System 6 might actually work, if OS usage is low enough. I was able to get a bit more than 6m free in System 7.5, but even that wasn't enough. All the testing on small System 7.5 machines (with 16m of ram) showed that the code works fine as-is in 256 colors. Previously it was showing everything purple, but it now looks fine. It will be super slow, as all the pixels internally are 24bit, and QuickDraw is having to do the conversion on the fly, for every frame drawn!
Last Edit: May 02, 2025, 21:02 by lauland
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #27 on: May 04, 2025, 01:00
|
I've been discussing SDL2 for older, unsupported, versions of MacOS X with someone. That isn't directly related to my efforts on classic MacOS 7/8/9, so I'll be discussing it over here, in case you guys are interested: https://forums.macrumors.com/threads/sdl2-for-older-macos-x.2456453/ (modern browser) Anyway, won't discuss it further here, because very much not related to System 7!
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #28 on: May 09, 2025, 20:56
|
Took a very close look at SDL2 for Tiger PPC. Everything there will probably work on Intel and newer versions too. (Up to a point, maybe 10.9?) I have two different working builds, and am planning on merging at least one of them into my SDL2 for MacOS 7/8/9 tree. The only problem is that both of them probably break building for modern MacOS X. SDL 2.32.4 for X11: This uses X11 instead of Cocoa for video and events. It works very well with OpenGL, but Cocoa, audio and joystick is broken as Tiger is so old. This is extremely close to what I have my current MacOS 7/8/9 based on. Most of the actual Mac drivers don't work. SDL 2.0.3: This is very old, but Cocoa, CoreAudio, OpenGL and joystick (with patches) work very well on Tiger. X11 is broken, but since Cocoa is there, it doesn't matter. Basically everything else works, the only downside it is such an old SDL2. ---- My SDL2 for MacOS 7/8/9 is based on the current 2.32.2, which includes modern MacOS X drivers, so far too new for Tiger. So, unclear which direction to take, as I'm looking at three different versions of MacOS X drivers. When faced with multiple choices, my answer is almost always "Why not ALL of them?!?". So that's probably what I'll do. I can just swap out the drivers, but otherwise have the same SDL2. ---- A side project would be taking the Cocoa, CoreAudio and joystick drivers from the 2.0.3 build and getting them working on 2.32.4. This would enable the current version of SDL2 to fully run on Tiger, with all drivers. This wouldn't be simple, as SDL2's driver interface has changed radically between 2.0.3 and 2.32.4. I did the naive thing of "just trying it" and things were badly broken. So it'd take work...how much I don't know yet.
Last Edit: May 09, 2025, 21:05 by lauland
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #29 on: May 09, 2025, 21:03
|
The other thing I'm looking into is taking as many of classic Mac SDL 1.2's drivers and reusing their code for SDL2. This includes threads, timer, audio and joystick at least. I got the timer and thread code building in SDL2 with minor fixes, so very promising. The "thread driver" also includes mutexes and semaphores, so quite useful (despite the fact in SDL 1.2 there isn't any actual real Mac thread code anyway). The thread code hangs, but I believe this may be because SDL2 makes HEAVY use of threads, if you have a driver, and it isn't just disabled. Because the SDL 1.2 thread code doesn't do any actual threads, it hangs because SDL2 by default tries to thread EVERYTHING. The mutexes and semaphores may or may not be useful alone, will have to see. Didn't test the timer code, so no idea if it works or not. The SDL 1.2 video driver code is probably not worth looking into since I wrote my own driver from scratch for SDL2. But might reuse portions of it. Especially OpenGL which what I've learned on Tiger is helping me understand how the way SDL talks to it works. Joystick support was expanded to a huge degree in SDL2, so the code from SDL 1.2 doesn't work as is, and will probably take a lot of work to wrangle, but otherwise looks promising and useful. (This is Input Sprocket based, so no m68k, sadly). The audio driver in SDL 1.2 is a mess, the authors abandoned it halfway through, and reusing is not a good idea. As mentioned before I've started my own SDL2 driver, this time based on the Android version as a skeleton, and will be able to copy "the good parts" when I work further on it.
Last Edit: May 09, 2025, 21:07 by lauland
|
|
Pages: 1 [2] 3
|
| |||||||||||||||
|
© 2021 System7Today.com. |
