https://macintoshgarden.org/apps/sdl2-macos-9-rough-draft login or create an account. recent changes, games uploaded so far Macintosh Garden * ftp * games * apps * + [Search... ] * guides * forum * irc * about This page is a wiki. Please login or create an account to begin editing. Home > Drivers & Hardware Support SDL2 for MacOS 9 "rough draft" Application Screenshot [system-sea] Application Screenshot Application Screenshot Application Screenshot Application Screenshot [Freakin' Awesome!] Rating: Your rating: None Average: 5 (3 votes) [Rate] * Development Tools Category: * Drivers & Hardware Support Year released: * 2025 Author: A cast of thousands Publisher: #1 [www][.se] [ftp][.se] [mirror][.de] [ftp][.de] sdl2macos9.sit (17.47 MB) MD5: 01b958bb8e3fa3c6ae6639aefb635afe For System 7.0 - 7.6 - Mac OS 9 Emulation This app works with: SheepShaver, Basilisk II, This is a "rough draft" of SDL2 for MacOS 9, using CodeWarrior Pro 6 and 7. Enough was done to get it building in CW, and the start of a "macosclassic" video driver was created. It DOES seem to basically work, but much still needs to be done. Event handling is just enough to handling Command-Q, there is no audio, etc etc etc. ---- Dev notes: Getting just SDL2 itself building, did take a lot of effort, but it was mostly "mechanical", dealing with the foibles of CodeWarrior, creating project files from scratch, things it couldn't handle, "simple" things like headers missing that are standard on more modern systems, etc. The first step was doing that with all "dummy" drivers. Was a bit shocked I got even that far. The results did absolutely NOTHING in the test programs. With a dummy video driver, they don't even try to set up textures, etc. The key missing part was a Classic MacOS "video" driver, which also includes event handling. I determined it was not possible to "port" the SDL1 driver due to too many changes in paradigms of SDL itself. Once I'd sketched a new one out, and got it hooked into the proper places, the debug output showed the test programs actually working. I then started adding basic MacOS implementations. This effort is in src/video/macosclassic. (I used the QNX driver as a skeleton as it was the smallest and easier to understand.) Compatibility Architecture: 68k PPC MacOS 9 PPC, MacOS 7.6 M68k, using CodeWarrior 6 and 7 Pro. Comments lauland's picture by lauland - 2025, April 10 - 6:42pm If you get a link error mentioning SDL_GetBasePath(), it is because CodeWarrior (sometimes?) gets confused by files with the same name in the directory hierarchy. It is pulling in the wrong SDL_sysfilesystem.c, in this case the first alphabetically, so the Android version. Replace it with the "dummy" version and things will link. Deleting the drivers for all other platform is probably the easiest way to avoid this. I kept them because they might have useful code I'd want to copy. Otherwise, the access paths in CodeWarrior might need to be tweaked? * Login or register to post comments lauland's picture by lauland - 2025, April 10 - 5:06pm Now on m68k also, believe it or not... (Second testsprite2 screenshot is in Basilisk, running 7.6) So I should probably change the name since it isn't MacOS 9 only... * Login or register to post comments Jatoba's picture by Jatoba - 2025, April 9 - 4:31pm Here's a celebratory picture for the achievement of getting ANYTHING SDL2 up and running on Mac OS just like that! [6eee8ec09f] This is REALLY awesome, @lauland! Although I didn't yet lay even a single finger on anything SDL2 for this Mac OS effort, I will try to get my act together and see if I can help somewhere with joystick or sound... Or even trying to locate a super-simple SDL2 game that doesn't use any of the plug-ins... To anyone reading this, if there are any further volunteers to help @lauland with this... Everyone is most welcome. As long as there is a will, anyone is welcome to try. The VERY attempt of trying to help is in itself appreciated. Please feel free to hop on Hotline (System 7 Today / Mac OS 9 Lives! channel), and feel free to participate! No wizardry expected and no wizard knowledge required... Just a desire to join up! To quote myself earlier in the SDL 1.2 page: I know BARELY much C, and even less C++, and even I could get things compiled! Major thanks to @lauland who patiently tutored me on most matters CodeWarrior, C, Mac API, SDL, libraries, etc. etc.! We learned and keep learning A LOT of stuff as we surf through these various tasks, and publicly share our experiences and learned lessons over at System 7 Today. But if I can do it, ANYONE can do it. We are both just human, and limited in time, resources etc., like everyone else. We are not super humans, and we are not better than anyone else in that sense. (That's also my way of saying, to whoever is reading this, join us today! Don't be shy! You CAN do it! Hit us up if in need of help/assistance.) And also The Platinum Builds thread: If you feel any inclination to porting such things, but don't know where to start, or what to do or look into, just ask! We will be glad to help. Most of this is NOT as hard as it looks or sounds, even if you are unfamiliar with CodeWarrior, MPW, C, C++, SDL etc.. Until December 2024 I had NO idea what to with CodeWarrior or existing C projects, but in about a month later, and I found myself live debugging and successfully fixing various bugs in Egoboo. If I can do it, so can you! I'm literally just human, like you, and so is @lauland, we all learned and had to start from somewhere. * Login or register to post comments lauland's picture by lauland - 2025, April 9 - 3:53pm Probably just "noise", likely random contents of the memory I'm setting up for the update buffer. I included it only to show that I've got the code displaying "something" again. The fact that it is wildly different from the previous noise is...troubling? A good sign? Not sure! It is supposed to be a small red rectangle on a black background, but there's nothing even remotely solid in the noise. The workflow is: The driver sets up a Pixmap for the buffer and passes it to the guts of SDL2. The user code creates a renderer, uses SDL2 to draw something, calls update. Update then uses CopyBits to copy to the screen. So the only thing I KNOW, for a fact, is working is the CopyBits (Well, it copies "something"!). So, if the buffer is right, if SDL2 is actually drawing in it...who knows? Stop presses! I was setting rowBytes incorrectly. I've actually got something really basic now working! Going to try the standard SDL2 test progs...and they work! (Uploaded the whole thing) * Login or register to post comments squiggledog's picture by squiggledog - 2025, April 9 - 5:04am Is that picture of any significance, or just jumbled noise? * Login or register to post comments lauland's picture by lauland - 2025, April 8 - 9:22pm mytests.sit has a couple extremely trivial SDL2 programs, far simpler than the tests that come with SDL2. macosclassic.sit is the driver with updates I've worked on lately. (no other changes to code base). Have it drawing SOMETHING again, and not crashing, so...progress? Taking different easier to understand approach with just a simple offscreen Pixmap instead of trying to wrangle gworlds. Added screenshot of what current build of "draw red rectangle" program displays. Still probably just garbage left over in memory... (Very very rough code, yes there are typos) * Login or register to post comments lauland's picture by lauland - 2025, February 13 - 3:38pm That was the first thing I looked at, but unfortunately the MacOS X driver is VERY well written, and 26 files entirely Objective C...so not even the same language to begin with, and a major pain just to translate...and THEN from Cocoa and CoreImage, etc. Some of the other drivers for other platforms are smaller, but also complex and require OpenGL or do acceleration...which'd be another hill to climb, and I'd love to get just basic 2d working. A few of the drivers are small enough..."arm" (using "pixman"?), n3ds, ngage, pandora, ps2, psp, qnx, and raspberry...that they'd be better starting points. But I'm not familiar with coding on ANY of those, except in theory. I picked the qnx one almost arbitrarily, just because it was quite "bare bones" and so I'd hoped easiest to understand, but one of the others might be better if I try again. I took the qnx one, commented out all qnx api calls, and started adding MacOS Toolbox ones, ie QuickDraw and Event Manager. Event handling (deceptively, it is also in the "video" driver) is relatively simple, but as I don't understand the guts of SDL 2 drivers, I knew what I'd written for doing graphics was "wrong"...with not understanding the difference between the moving parts, especially which buffer was which. I had some sort of buffer, and started fleshing out the "Update" function, etc. I got to the point where once SOMETHING was getting displayed, the more I looked at it, I realized I (probably?) wasn't seeing what I thought I was seeing. The demo test code I used draws an SDL logo, and Smiley face, with one moving over the other. The yellow at the top of the screenshot seems to be multiple frames of the Smiley, and the part at the bottom (maybe?) the final fully rendered buffer with the logo and Smiley on top of it. Everything is skewed diagonally because the horizontal size is incorrect. But I think that all showed up "by accident" as my offscreen GWorld happened to either overlap other buffers or just point at the wrong memory block? Trying to LockPixels the GWorld properly would then show a blank buffer, etc etc. Anyway, it'd be great if someone who actually understood SDL2 drivers took a look...but someone who does, and is also interested in MacOS 9 may not exist, or have enough time or interest. * Login or register to post comments Jatoba's picture by Jatoba - 2025, February 13 - 5:33am Rather than writing the video driver from scratch, perhaps taking a PowerPC-tested version of the SDL2 source for OS X (e.g. @thedoctor45's source compiled for 10.3 Panther) could be a good start to convert from? Of course, I assume there will be Quartz and/ or CoreImage calls all of which will have to be replaced by Color QuickDraw, and I also assume everything will be written in Cocoa, more likely than Carbon. But it might show us the "roadmap", in code form? At the very least, a PowerPC-tested version should help us avoid endianess issues, I'd think. * Login or register to post comments lauland's picture by lauland - 2025, February 13 - 4:11am Well, you had me quite excited for a second there...but sadly, it looks like "SDL-historical-archive-SDL-1.3" is just a branch of 1.2 with a name change. There are a LOT of differences, but many things were actually added to 1.2 post that. Look in the "src" folder and you'll see the drivers there are all "1.2" style. So I don't think it's more than of historic interest. The other "1.3" archives you found are indeed extremely early versions of "2.0", again, the "src" folder gives them away. But, a huge thank you for taking the effort! The "holy grail" would be if there was ever an attempt on a classic MacOS 9 src/video driver for what became 2.0. Because of the work that'd be involved, I highly doubt that ever existed. It's not that support for classic MacOS (and MANY other platforms) was ever "removed" from 2.0, it's that it was never started. The key being working with the new "render" infrastructure. * Login or register to post comments Jatoba's picture by Jatoba - 2025, February 12 - 7:04pm Something I noticed that might be relevant for this effort: before SDL2 was called that, it was being developed as "SDL 1.3" instead. There was never a "release" version of SDL 1.3, and the naming transition to "SDL 2" did not warrant a release in and of itself, either. Quite a while after the naming transition, SDL2 was released, and became what we know it for today. So I went, looked around, and found the following: - The frozen GitHub repo that is a mirror of the final state of the original Mercurial repo that was used to develop SDL projects, inside of which was a SDL 1.3 branch, whose latest source code can be downloaded here; - The latest archive of the source code of SDL 1.3 in libsdl.org before the name change (found here with page from 2012-01-25), downloadable from here (download link from 2012-03-14); - The earliest archive of the source code of SDL 2.0 in libsdl.org after the name change (found here with page from 2012-02-05), downloadable from here (download link from 2013-01-29). What's interesting here is that the GitHub source code still contains the CW and MPW files, although I assume they are outdated and need a little update to include all the files. Or are they already referencing everything, still? The libsdl.org final 1.3 archive does not include them, though. Nor does the libsdl.org SDL2 archive from early 2013 (early 2012 copies were not archived, sadly). Perhaps there could be some use for us in these. Or not. But I'm bringing them up in case it is of some use. There's also this alleged archive of SDL 1.3 supposedly from 2007-07-05, here on archive.org, in case this can also help with anything. This one also lacks the CW and MPW files. By the way, I know some games used "SDL 1.3", at least I have seen some person's comment on using it to compile some Nintendo DS game, although I assume such a game can very well also compile against either SDL2 or, perhaps, even SDL 1.2 instead, and that there are no projects that actually need SDL 1.3 specifically. But, who knows. * Login or register to post comments Jatoba's picture by Jatoba - 2025, January 26 - 4:32pm It's great to have this page as a placeholder for ongoing efforts. It will also certainly harden us against any other code loss accidents. So, yeah, to any other folks reading and wondering, this page is about an effort to bring SDL2 to the real Macintosh Operating System. Currently @lauland has been the sole developer to undertake this monstrously gargantuan effort, but anyone is more than welcome to chime in, for any other like-minded Mac developer. If I can be of help later on, I'd love to contribute. (For now, both @lauland and I are focusing mostly on SDL 1.2 efforts before even thinking seriously taking head-on a project like this.) So, better not have any expectations here, but for whatever effort/ progress that is made, this page is currently a backup of it all, and optionally also a means to share the effort with others who may be interested. @lauland rocks! Smile * Login or register to post comments Disclaimer: Macintosh Garden does not claim rights to any software on the site. To the best of our knowledge, these titles have been discontinued by their publishers. If you know otherwise, please contact us and we will remove them accordingly. Thank you for your attention.