|
|
|
|
| Welcome, Guest | Home | Search | Login | Register | |
| Author | SDL 1.2.x for M68k attempt... (Read 118262 times) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
lauland
512 MB  Posts: 674 Symtes 7 Mewconer! 
|
Reply #15 on: January 03, 2025, 16:53
I've uploaded Breaker and SDL Scavenger to MG. Give 'em a try and let me know if they work (or crash) on your systems... http://macintoshgarden.org/games/breaker-0 http://macintoshgarden.org/games/sdl-scavenger Both probably don't have sound, as I was working on that in SDL at the time, so these are just snapshots of work in progress. I'll update them as they, hopefully, become "stable". |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Last Edit: January 03, 2025, 17:11 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #16 on: January 03, 2025, 20:05
|
I left feedback to both on their respective pages.  Awesome stuff, again. Thanks for sharing!Both of these games turned out to be more fun than I expected, too.
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #17 on: January 03, 2025, 20:29
|
A few notes on m68k SDL: M68k, but not PPC, has a non-AppleEvent way of handling documents dropped on their app's icons, or via Creator codes, called "CountAppFiles()". I have unfinished code in SDL_main.c for this. It'll be easy to finish it at some point. Sound compiles, but I haven't tested it. It relies on a few "Atomic" functions I don't believe exist in M68k's driver support library (but do on PPC). I added "atomic_hack.c" which has braindead (non-atomic) replacements that may or may not be correct. Technically, it is not possible to do true atomic operations on M68k Macs for "reasons" I won't go into. I doubt this really matters. There is a linker problem with CW6, with it not finding "tolower()". I believe this is actually a mistake in the SDL code not including <ctype.h> where it should be. To get around it I copied the implementation from ctype to "tolower_hack.c", which is fully functional, but a stupid thing to do. I'll fix the mistake and add the includes where they are needed. The standard MacOS SDL timer is dependent on PPC cpu realtime support, but there is an alternate called "SDL_MPWtimer.c" which compiles fine with CW. I enabled CDROM support, but haven't tested it. Joystick support is disabled, as it looks very PPC and HID dependent. If support for (very obscure) M68k joysticks were desired, a new implementation would be needed. Shared libraries probably would work with CFM-68k, but there's very little demand for that in the m68k world so I didn't bother and disabled it. There were conflicts with some headers in Support:MacOS:StdCLib, which may only be needed for MPW and not CW. I have only built with CW6 and CW7 so far, so don't know if these are real problems. The only real things disabled at this point for M68k are DrawSprockets and OpenGL. The funny thing is, both compile, but (obviously) fail to link. This means if some replacements were found, somehow, support COULD be enabled. A software only OpenGL is a real possibility, but, as mentioned before, the real world performance may end up be poor. I've only built/fixed the Debug versions and not Release yet.
Last Edit: January 03, 2025, 20:31 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #18 on: January 04, 2025, 15:54
|
Just a quick note, @thedoctor45 (and others, from what I read), have been successful at porting early-ish (certainly not latest) SDL 2.0 versions to PowerPC Mac OS X, at least as low as Mac OS X 10.3.9 Panther. https://www.mediafire.com/folder/023jiycr49e8r/Custom_Intel_10.5_Builds#bskox83fznerf I'm not sure if the source is included, but we can worry about that after SDL 1.2 is "complete".
Last Edit: January 04, 2025, 16:43 by Jatoba
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #19 on: January 04, 2025, 17:25
|
@lauland I asked @thedoctor45 about his modified sources. He quickly got back to me: Quote from: thedoctor45 All my sources are available for download on the Leopard Ports Discord server: So there we go! If only he chose Hotline or IRC over Discord, though... Should we make a "Mac OS ports" Hotline server? Then again, who will host it... *glance at @Knez & @Bolkonskij*
Last Edit: January 04, 2025, 17:28 by Jatoba
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #20 on: January 04, 2025, 22:08
|
Oh man! The Leopard Ports discord looks extremely cool! I've signed up and can't wait to explore! The "porting tools" sections look awesome! One way out thing to, erm, think about, seeing Wine talk at Leopard Ports...dare I even mention it, and my brain hurts just considering it would be Wine for MacOS 9...which would make porting Windows software "easier"...that is easier by some very stretched definitions of the word. I don't know if anyone ever even tried such a beast, a quick search doesn't turn up anything. But you never know...it might be possible. I have a PPC build for Tiger on my ibook, but never did anything with it beyond than "Hello World" level tests. Anyway...I think my priorities should be "finishing" (again by some definition of that word) what I already am working on. ---- I think maybe Breaker is good as it is. The controls are funky, but they were in the original. I'm going to put a note on MG to ask if anyone finds anything wrong with it, but otherwise consider it done. I'll get sound working in SDL Scavenger. I took some liberties on how I handled not having getopt() (used commonly in the Unix world to parse command line) and want to clean that up. I also need to figure out why it couldn't find its data in folders. After I do that I might as well consider it "finished" too. ---- SDL PPC: The AppleEvent stuff I wrote is ugly, and I wanted it cleaner before "submitting it as an official change to the maintainers"...but if it turns out there's nobody else out there maintaining SDL for MacOS PPC, well, then it's "good enough", right? I'll handle keysym->sym thing by checking if it is zero, and just copying keysym->unicode to it if it is, which is quick and dirty, but solves the problem. That is unless looking at the code shows what is really going wrong. Otherwise I'll just be helping Jatoba bring in 1.2.16ish changes if desired... SDL M68k...obviously getting Breaker and SDL Scavenger working. Since MvM already seems to work fine, SDL is "basically working", and figuring out why they don't will show up any real problems. I'll also test if sound actually works, I think it will.
Last Edit: January 04, 2025, 22:10 by lauland
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #21 on: January 04, 2025, 22:12
|
What we could do, to start off a nascent "Mac OS Classic Ports", would be create a new topic here for that. Anyone could post a "Would a port of SUCH-AND-SUCH be possible?" question, and we could take a look at the source. If it were something that could be done "casually" ie just nobody has ever bothered to build it for MacOS 9 PPC or M68k, we can take a stab at it. If there are other hurdles, like no MacOS support, or SDL2, etc, we can explain that there. That way we'd slowly build up a library of ported apps/games, adding them to MG as we go. On the other hand, if you guys create a Hotline (or whatever), let me know and I will obviously gleefully join...
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #22 on: January 04, 2025, 22:48
|
Quote from: lauland SDL PPC: Right! I'd be beyond surprised if anyone else is maintaing SDL 1.2 for Mac OS. Rarely ever do we see someone even compiling it (like Matej or I), let alone maintaining it, and providing new code that fixes or adds stuff! Once our hands are free from SDL 1.2 and MvM, we can look into opening up a "Macports" thread (word pun intended). Whether that's eventually followed up or not by a Hotline server, or KDX, or FirstClass, or IRC or so... only time can tell.
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #23 on: January 05, 2025, 02:02
|
Breaker: Got an m68k version working...for what it's worth...it is...NOT fast...running in Classic on a 1.33ghz ibook g4. Had to turn on "relax pointer types" to get it running...turned out they are doing something slightly non-kosher with a function pointer type. Don't know why this was ok on PPC. Had the bright idea to work on a non-debug optimized version of SDL, and build Breaker with optimizations, but probably screwed my projects up as now build just crashes even when I try and back out what I did. Oh well. Will go back and be more careful! SDL Scavenger: Added a lot of debug printfs and can't see where it is going wrong...the m68k version will sometimes actually run fine for a few seconds but then crash, other times it crashes at start, or shows scrambled screen for a few secs (and crashes). When it crashes, it has trashed the heaps and I have to restart Classic, so it is really trashing memory. (Already had "relaxed pointer types" turned on). I reenabled sound and fixed the goofy getopt() stuff for PPC. Still want to fix how I handled the data directories. ---- I took a very close look at SDL sound, and can't figure out why it doesn't work on m68k, added some error checking, and it seems to think it is working, but never actually makes a peep. It really should be working, but it may be using some "advanced" Sound Manager features that didn't exist on m68k (and so is failing silently...hehe). Would think I'd be seeing runtime errors though...
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #24 on: January 05, 2025, 08:31
|
Quote from: lauland One way out thing to, erm, think about, seeing Wine talk at Leopard Ports...dare I even mention it, and my brain hurts just considering it would be Wine for MacOS 9...which would make porting Windows software "easier"...that is easier by some very stretched definitions of the word. I don't know if anyone ever even tried such a beast, a quick search doesn't turn up anything. But you never know...it might be possible. I have a PPC build for Tiger on my ibook, but never did anything with it beyond than "Hello World" level tests. I forgot to comment on this earlier. I just wanted to say: that's an awesome idea to have. Brain pain from considering it is expected on multiple levels, but that's definitely one cool idea to keep in the Mac backlog. Also, are you suggesting you have an earlier version of WINE and its source code that runs on PPC? WINE on PPC was called "Darwine", right? Or were there PPC versions of WINE proper, too? It's not quite the exact same, but the way MacRelix brings "UNIX" (so to speak) to Mac OS natively (unlike Power MachTen, which runs inside a PPC VM), creating all these typical UNIX and GNU/Linux folders (subfolders) with the "root" being pointed to the MacRelix environment is very akin to, and reminds me of, what WINE does for the Windows folder structure. There's no reason it's not possible. But... challenges surely are ahead! Running a Windows app directly might imply challenges with memory management and, probably even more so, with pre-emptive multitasking, although technically the Mac OS 8.6+ nanokernel IS pre-emptively multitasking, and the Finder and most Mac OS programs run within a single thread within the pre-emptively multitasking nanokernel (what Apple used to call a "pink thread" or "pink task", as opposed to the "blue", co-operatively multitasking/multi-threaded ones). Then... converting DirectX calls to Color QuickDraw... and Direct3D calls to RAVE and/or QuickDraw 3D (or OpenGL)... Well, an idea to consider for later for sure.
Last Edit: January 05, 2025, 08:37 by Jatoba
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #25 on: January 05, 2025, 09:57
|
Quick note about SDL 1.2 on Mac OS, I stumbled upon an HTML file included with the 1.2.15 source code describing multi-threading stuffs, and in it the warning: Quote Note: SDL's threading is not implemented on MacOS, due to that lack of preemptive thread support (Mac OS X dos nt suffer from this problem) (Note: The typos there are fixed if you grab the 1.2.15 source code from the "releases" page on GitHub (HTTPS link) instead of libsdl.org. Weird. No source code differences, though.) Funny timing for me to see this, as I just wrote about Mac OS's ability of true pre-emptive multitasking regarding WINE, above. In short, the SDL documentation is wrong about Mac OS, IF supporting ONLY Mac OS 8.6 ~ 9.2.2, although I have absolutely no idea how to make a Mac app make use of the so-called "pink tasks" that meet the pre-emptive multitasking criteria. I heard that using CarbonLib either is THE way to do that, OR the easiest way to do that, although based on the Mac OS 8.6+ requirement, I wonder if this is only true if a high-enough version of CarbonLib is used, such as 1.6.1, and 1.6, which are not compatible with Mac OS 8.5.1 and earlier. Just making sure to write this down. Could be relevant if we improve Mac support in SDL 1.2.16. -------------------- For the record, here are some potentially-helpful release dates, to give us an idea of what to expect in the 1.2.16 "unfrozen" source compared to the 1.2.15 "frozen" source: SDL 1.2.13 release date: 31st December 2007 SDL 1.2.14 release date: 20 October 2009 SDL 1.2.15 release date: 21 January 2012 SDL 1.2.16 latest commit: 27 October 2024 Most commits to 1.2.16 seem to come from people who, like us, sought to improve platforms not supported by SDL 2.0, such as the Atari ST. There's a surprising amount of commits in the past 13 years since the release of 1.2.15, although they are clearly lessening more and more with time. Here's the list's beginning in descending order (HTTPS link). I will try compiling 1.2.16 to make sure it "still works". I will test it against SDL MvM PPC. Then we can feel more confident over the thought of putting the latest Mac SDL patches in 1.2.16. However, if we find issues, then we stick with 1.2.15 and keep the patches just there (OR add patches to 1.2.16 anyway, AND fix whatever is wrong, if anything, in the current 1.2.16).
Last Edit: January 05, 2025, 10:01 by Jatoba
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #26 on: January 05, 2025, 14:19
|
Quote from: Jatoba (Note: The typos there are fixed if you grab the 1.2.15 source code from the "releases" page on GitHub (HTTPS link) instead of libsdl.org. Weird. No source code differences, though.) I mispoke: for some mysterious reason (SDL project disorganization, it seems), there are extremely few differences. Since I used Windows to download from GitHub, I went ahead and also used WinMerge to compare: http://revontulet.org/2025/01/05/8d009639f04e4545bc8d75883f216406.PNG The "left" side is the GitHub one. The "right" side is the libsdl.org which is the exact same one hosted in the Garden and the one we have been using all this while. It seems the "right" side one is "complete", so that's a relief. I'm not sure what's the impact of GitHub excluding include/SDL_config.h, but I imagine that can't be good. Same for SDL.spec (and maybe the configure files there?). In any case, since we are working with the "better" libsdl.org origin, then we can move on nonetheless.
Last Edit: January 05, 2025, 14:25 by Jatoba
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #27 on: January 05, 2025, 19:27
|
I'm a bit confused about the post 1.2.13 stuff (patches versions who what where official or not), but it sounds like you've got a hand on it...or are very close to that. There's a 1.2.16 zip at the MG page, I presume you uploaded, if not, some other angel is watching us. I like having "main" at the top and "unstable" right beneath it, with NO version numbers. We can track all upcoming updates into those, both of them "bleeding edge", but "main" is stable vanilla and as official as it gets. ---- I used to be a bit of an OS geek and did a LOT of looking into threading and multitasking in kernels. Hold on...let me get my soapbox ready... From what I can tell, Apple had a full multitasking, threaded, modern kernel for the Pink project (which was not based on, and didn't use, any of their existing MacOS code). When that faltered, they took the kernel and tried building Copland on top of that. They immediately ran into problems with the MacOS Toolbox, which had several design issues and assumptions where it couldn't be done easily, at all. They compromised, and split the Toolbox off into the "Blue World". On Copland, it isn't a separate "box". You can either have apps that use the Toolbox, or that don't. Apps that use the Toolbox can thread within themselves, but can't really have more than one task. This is a subtle difference, and doesn't sound like a big deal. The problem is that Copland can't multitask more than one Blue task, so it can't switch tasks until an App goes into its event loop. This is shockingly similar to Windows 95's win16mutex, but MS had it better for too many reasons to go into here. Copland failed for other good reasons, and we got MacOS 8. Which is basically System 7.7 with a multithreaded Finder (different, but based on Copland's). OpenTransport originated in Copland, and has its own bespoke threading inside it. Otherwise, MacOS 8 has no (true) multitasking, and nothing else from Copland. The threading API wasn't even new to 8. When MacOS 8.5 came around, and multiprocessor Macs started becoming more common, Apple took the way Copland did multitasking, and reimplemented it in the nanokernel. (Astonishingly it is the same interface). This is Multiprocessing services, and allows true multitasking on MacOS 8.5+...with the same caveat you had on Copland. Only one task can use the Toolbox at a time, and those can't be switched between by the kernel. So a MacOS Classic app can launch a separate task, but that task can't interface with the user in any way, or even do file io, networking or anything that'd call the Toolbox. Carbon is really two extremely different things. First is a reimplementation of the Toolbox on top of Cocoa for MacOS X (Mach-O or CFM on PPC). They fixed, worked around, or added new APIs (like opaque structures, no globals, and Carbon Events) to get around limitations of the design, and it is fully multitasking. The second, "other" Carbon, is the MacOS 8+ CarbonLib (CFM only), which is a shim that implements the new Toolbox APIs, but doesn't add any Unix, Cocoa, or other features. It doesn't add any new multitasking or threading to MacOS Classic, beyond what 8/8.5+ already had. ---- So, where does that leave us? SDL doesn't implement threading on MacOS Classic. But...here's the catch. Threads are not tasks. MacOS Classic on PPC actually can do pretty decent threads. (Even very close to real preemptive, but not on M68k where Apple never implemented them). So, from a technical standpoint, threading COULD be done in SDL, but would need a brand new implementation...which'd be a major pain to write since threads on MacOS Class are very alien to threads on Unix or anything else. Threads vs tasks: Threads basically have their own stack, but otherwise share their parent task's file handles, context, address space, etc etc. They can be preemptive, where they are co-equal with the "original single thread" that is started when a task is born...or they can be cooperative and the switching done "manually". (This is different from pre-emptive vs cooperative multi-tasking). An program is born with a single task, with a single thread within that task. Threads live within tasks. From decades old memory, I believe MacOS Classic on PPC's threading was "done right", but would have to take a fresh look. They were pretty alien, not easy to use, and I didn't need them at the time, so didn't look further back then. How useful really are threads? If a game or whatever required them, it might be worth looking into...otherwise, I can't blame the SDL authors from not bothering. ---- On a completely different note, I might look into Mesa (an open source OpenGL) for M68k. Seeing how the performance of SDL on M68k is probably not going to be great on real hardware, even in 2D, it is probably a lost cause, but I might as well take a look. Technically, the trick will be the interface between MacOS/SDL and OpenGL, the equivalent of AGL (GLX on Unix, WGL on Windows), which may be missing, but needed. (Apple provides it in their OpenGL for PPC MacOS 9). The pimary way SDL works with OpenGL is providing a surface to render to, and just letting it do its thing. This might not be too hard to cobble together. The acceleration parts are the drawing (OpenGL) and the flipping (SDL or the OS). On M68k those are both either missing or probably pretty slow, going from Breaker's performance. Either way, it isn't likely we'd end up with anything but tech demos.
Last Edit: January 05, 2025, 19:48 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #28 on: January 05, 2025, 20:56
|
Just a "quick" update from my part: today I played a lot (for my standards) with SDL... did all sorts of code comparisons, code analysis and compilations, lots of rereading from topics here and editing at the Garden, and there's more of that (especially the code stuff) I'd like to continue doing throughout this week. Alas, Sunday has already ended from where I stand. About the SDL Garden page, yeah, right now it is a bit too overwhelming with too many download options and too much information that is confusing to discern. I was indeed the one who added all the stuff, the latest 1.2.16 source upload included. But worry not, I will "trim" that page quite a bit so that it can be more helpful with time. Thanks for that whole multitasking breakdown, it made complete sense and explains everything I was wondering about. So technically, the more we avoid the toolbox, ironically, the more multi-threaded we can get on PPC Mac OS 8.5+ (not 8.6+ and the v2 kernel by Rene?), and Carbon doesn't help with this (and is in fact still reliant on the toolbox behind-the-scenes?). I will remember these lessons. I will write about SDL in more detail later as time permits, but for now I will say that I was able to compile 1.2.15 with CWPro6 for the first time, and, if you figure out that you need a blank "macos_prefix.h" and to make the project file "see" OpenGL etc., it's easier to compile with than with MPW. In fact, the MPW instructions are only enough to compile the shared lib of SDL itself, and nothing else. But with CodeWarrior, you get targets for everything... the shared lib (debug/release, no need to tweak anything for optimization like we do with the MPW make file as Matej reported), SDLmain which is used as the "real main() method" of any SDL-based program, the otherwise-elusive Resource (.rsrc) file and everything else! What is up with that blank "macos_prefix.h" file anyway? Why is the project searching for it? I don't see explicit #include calls in the .c files to look for it, nor do I see anything set in the MCP project file. Where is this being... "requested" explicitly? Also of interest, I noticed that the "Release" target builds SDL as a shared lib, not static. Maybe we can squeeze a wee tiny bit of extra performance if we set it to static lib? I know the project is like this because many programs built with SDL 1.2 are not libre or "open"-source, but the LGPL license won't allow that with static lib linking, only shared lib. (SDL 2.0 and 3.0 switched from it to zlib license so that either way was fine.) But in our case, we are making the source code available for everything we are doing with SDL here, so both ways work fine for us, too. I also spent a gooood amount of time to "diff" and look at the changes between 1.2.15 and your (awesome!) 1.2.15 "unstable", and found the changes pretty clear in intent: I see the 68k-excluding ifdefs, the commented-out AppleEvents pre-processor flag, the code that AFAIK handles drag'n'drop into the app icon (useful for not only Mini vMac, but any other SDL app on Mac), the couple of new "*_hack.c" files that you described earlier, the life-saving blank "macos_prefix.h", and so on... Very educational, and the longer I stared at the code, the less alienated I felt. It'd be awesome to see much, or all of this, eventually pushed to the SDL 1.2.16 GitHub repo someday. Here's what I will try to accomplish, respectively, this week: - Compile vanilla SDL 1.2.16; - Put together SDL 1.2.15 devel and add it to the Garden. No "tweaks", make it just like as if it was an SDL 1.2.15 devel release from the main SDL team themselves; - Same as above, but for SDL 1.2.16 as well; - Same as above, but for your SDL 1.2 "unstable", too; - Clean up SDL 1.2 Garden page, it doesn't need to be so massive and overwhelming, I can do better than how it is currently; - Help with the bleeding edge "unstable" SDL wherever I notice I can do something for it, even if it is something as small as getting the detected version to be "1.2.16" or "1.2.16 unstable", rather than an errouneous "1.2.13" label; - Back to Mini vMac II with Color! I will also try to "understand" the changes done from 1.2.15 to 1.2.16, again using "diffs". (BBEdit really is awesome with this!)
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #29 on: January 06, 2025, 02:27
|
The problem with Breaker on M68k turned out to be sound. With it disabled it is fine. I added lots of debug printfs to src:audio:macos:macrom:SDL_romaudio.c and am pretty sure there is a bug dealing with buffers. It will consistently crash on m68k at a certain point, with a bad pointer. The PPC is more forgiving about the stack, and it is probably getting partially overwritten or parts of it trashed. I think this is a bug in SDL for MacOS itself, as otherwise the MacOS parts of the code look good to go on M68k. I'll be looking into it, as it could cause problems on PPC in certain conditions as well. I have an M68k Breaker that runs without sound, and even have it default to the smaller window size, so it runs well. Will upload it to MG soon...but... ----- ...I decided it was high time to do some real world hardware tests, and, of course, realized my PowerBook 540 only runs in 256 colors (no Thousands/Millions). Booted up my Performa 630, and it also only goes up to 256 colors. The more I thought on it, the more I believe Apple never released any M68k hardware that could do Thousands of colors. So only someone with a high end video card (pretty rare) could even run SDL! I wanted to then test performance of the PPC SDL on real hardware and dusted off my PB 5300 (surely the slowest, most miserable powerpc machine there is). You guessed it, only goes up to 256 colors! ---- Since MacOS Classic SDL, even on PPC, doesn't display properly in 256 colors, this has tempered my enthusiasm a bit...or at least pointed in a different direction to head into. I've got everything but audio working, and it runs well in Basilisk...but will probably way slow down further M68k endeavors. Even the color M68k MvM will require Thousands, if we use SDL. So I'm going to look into 256 color mode some. I'm expecting the MacOS SDL code doesn't even try it, so will look at the Amiga and Atari worlds (and other obscure platforms) and see what they have been up to. The thing being, if an SDL game is written in truecolor, converting to 256 colors in realtime on the fly can't be quick, and I don't expect good performance at all, even if I do get something. But we'll see what I see...Amiga and Atari people are particularly crafty. ---- I did "Find Differences..." between "SDL-1.2-main.zip" and "SDL-1.2.15.zip" and saw way more than expected. It looks like main is newer, and some things were removed, for example support for older PC Borland and EMX compilers, just to start...but at the same time, a lot of work for Watcom on OS/2 and other oddness, and ARM64 work. Let me know which I should base any new changes on... ---- You mixed up threads and tasks. I believe threads are not limited in their toolbox calls, but I am relying on decades old memory. As far as actual multiple tasks (not threads), the Classic Toolbox is not multitask safe, and there is no good solution (MachTen multitasks within itself, technically closer to threads, but still must ultimately call down to the ToolBox). This doesn't mean you can't multitask, you just can't call the Toolbox AT ALL from anything but the primary task. CarbonLib on MacOS 8+ is just a layer over the Toolbox, so it is zero help. This is probably a non-issue for games, but some high end apps really need fork(), at least. Multitasking existed before multithreading did, so you do run into code that needs more than one task...and they'd likely expect to be able to do file io, so you do run into that being a problem on MacOS Classic. ---- Yeah, the SDL source is a bit of a mess, from a MacOS Classic standpoint. Missing things, having things in weird places. The very least we can do to contribute to the world is an updated "CWprojects.sea.bin" that works out of the box! Although shared libs do add "some" overhead, I doubt there's much impact real world, expect in cases where you might be running on very low end PPC hardware...but wouldn't hurt to try.
Last Edit: January 06, 2025, 02:55 by lauland
|
|
Pages: 1 [2] 3 4 ... 8
|
| |||||||||||||||
|
© 2021 System7Today.com. |
