SDL 1.2.x for M68k attempt...



Welcome, Guest \| Home \| Search \| Login \| Register


Author	SDL 1.2.x for M68k attempt... (Read 118259 times)
lauland 512 MB Posts: 674 Symtes 7 Mewconer!	on: December 31, 2024, 03:21 Using @Jatoba's 1.2.15 from MG. So I took the CW6 project file, and changed the Target from PPC to M68k, set new names for the outputs (SDL.M68k.LIB and SDLmain.M68k.LIB), and changed a few settings in 68K Processor (Smart, 68K 4-byte align, 68020 Codegen, 4-Byte Ints, 8-Byte Doubles) and...after adding two lines for a missing variable in FastTimes.c, it, shockingly, built with no problems. Whether it actually works remains to be seen...I'll try building the tests next. If it DOES work...at all...surely parts of it won't...can't...I'm 90% sure there were never Game Sprockets or OpenGL for M68k, in the very least. I didn't even change SDL_config_macos.h so there may be massive parts missing (like timers?) that just didn't generate any compile problems. And then...in the off chance it does even sort of work, we'll have to see if it is fast enough to be useful for porting any games... Anyway, I'm expecting crashes or runtime errors when it even tries to start...but...this is something... BTW: Some of the 68K Processor settings I chose may or may not be necessary, but they are what I always do when porting ANY project to M68k. 2 byte ints and small segments just don't cut it.

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #1 on: December 31, 2024, 05:20 Screen_Shot_2024-12-30_at_10.14.24_PM.png Screen_Shot_2024-12-30_at_10.14.46_PM.png Just basic support for now...took quite a bit more work...
Last Edit: December 31, 2024, 12:09 by Bolkonskij
lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #2 on: December 31, 2024, 07:32 I did a bit of a crazy thing and built the SDL version of MvM 3.5.8, using CW6, for M68k, using the SDL I've just got working. This wasn't simple, by far, but was it worth it? Well, it was a very good way of testing the M68k SDL actually works... To say it was SLLLOOOOWWWWW is an understatement...but this may or may not bode well (poorly?) for porting SDL games to M68k...it could just be that MvM on m68k is pretty slow itself. And I was running it in SheepShaver... It was running on an emulated 68k (MvM, very slow?), which was m68k code on MacOS 9's built in m68k emulator (Apple's, quite fast), on an emulated powerpc (SheepShaver, not a speed demon), eventually running on the MacBook's Intel processor. A bit of an "Inception" situation.
Last Edit: December 31, 2024, 07:36 by lauland
68040 512 MB Posts: 950 68k - thy kingdom come, thy will be done !	Reply #3 on: December 31, 2024, 12:08 Quote from: lauland So I took the CW6 project file, and changed the Target from PPC to M68k 68040 (aka "m68k") says thanks a lot for your efforts. And a happy new year to you, too (and all the other fellow vintage warriors).

Bolkonskij Administrator 1024 MB Posts: 2023	Reply #4 on: December 31, 2024, 12:13 A very commendable project! Though I do wonder if non-emulated 68k systems will ever be able to hold up performance-wise. With the typical performance of a RealBasic program in mind (which is lightweight by comparison!), SDL seems so much overkill. But a fun project just for the sake of trying :-) Note - your links ran quite long, so I edited them to display just the file name as they were involuntary enlarging the width of the table cell :-) but they'd only throw a 403 on me. Why not use the Mac Garden Image Hosting for the purpose? It's THE utility for quickly sharing a screenshot on the net (retro compatible even!)

Jatoba 256 MB Posts: 270 System 9 Newcomer!	Reply #5 on: December 31, 2024, 16:26 This is awesome! I did not expect SDL 1.2.15 to be compiled for 68k so soon! (To be more specific, for 68020+ for now, so currently the actual 68000 is excluded.) I guess it working (partially) for 68k Mini vMac II in Color as well also confirms CWPro6 as a proper compiler to target early System 7 with, for both PPC and 68k, eh? Meaning CWPro6 Mini vMac II in Color on System 7 PPC seems to be already successful! As for 68k Mac OS, it's great to see there's already something of Mini vMac II in Color working with it, even if partially, since SDL itself is only partially there. I suspect though that a "speedy" Color Mini vMac II for 68k might only be possible via something other than SDL, even if 68k SDL was fully implemented (which it isn't). But, first things first... What can we do to "finish up" 68k SDL? So far we have missing: - OpenGL - GameSprockets - Overall source code and/or project file tinkering/polishing & build testing for errors etc. - Motorola 68000 support (despite it being even slower) Am I forgetting anything? How was it like to try getting SDL 68k to work with Color Mini vMac II + CWPro6? If nothing else, I'm looking forward to seeing how everything pans out for Color Mini vMac II in PPC and 68k, back on its thread.
Last Edit: December 31, 2024, 16:28 by Jatoba
lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #6 on: December 31, 2024, 19:56 @Bolkonskij Thanks for editing the links! I didn't use the image hosting service because I'd forgotten about it. And put them on the MG SDL page in the off hopes someone would see them and my comment, know what they meant, and, maybe possibly, get excited enough to chime in. ---- Real world speed remains to be seen, and I'll be testing ASAP, I've got hardware and just need to transfer the files. MvM was an EXTREMELY poor test for speed, but I had it RIGHT THERE handy, and knew it'd blow @Jatoba's mind. I also was running non-optimized debug code, SS was in Millions of colors, there were three layers of cpu emulation, etc etc. How fast SDL for m68k runs for real world games just MIGHT be better than we expect. SDL itself IS "big" comparatively, but, as these things go, it is a "relatively" thin layer, and the code is very efficient and well written. I just transferred my build folders to BasiliskII and both the demos and MvM run quite well! I was able to play Shanghai quite usably. So it looks like SS added a LOT of overhead. That bodes well... ---- @Jatoba I did indeed first build SDL 1.2.15 PPC using CW6, with very few problems...and of course the SDL MvM PPC also few problems. Just tested on Basilisk in System 7.5.3 and everything runs, so support for older systems works! I ran into a LOT of issues just getting MvM SDL to build for M68k. I had to modify the sources a little as they assumed PPC. There is also a problem with the m68k emulator and CW6's m68k compiler, so I had to hack out part of the FPU. ---- Most of the changes I had to make to SDL for m68k were places where it assumed it was on PPC (so didn't detect the endian correctly), assumed you had OpenGL (even when you disabled it), assumed you had CFM and could handle disabling the Control strip, and could get to the video hardware's gamma. It looks like an earlier version of SDL already DID support M68k at some point, but PPC-only-isms crept in. A lot of the parts of SDL I disabled I did only to eliminate them as variables and/or things I'd POTENTIALLY have to deal with. I believe I can re-enable most of them, and, dealing with similar assumptions as above, build an almost full SDL. ---- I don't believe there will ever be OpenGL support, as there is no (official) OpenGL for m68k. Even if we find one that works, it will be software rendering, and expect performance will be horrendous. (But there are some fun SDL non-OpenGL games out there!) DrawSprockets was also PPC only I believe. It is no loss, as it is an alternate video driver, the "native" one is good enough. (And, programming-wise, never actually bought you much, even for PPC games, which is why it was rarely used, and died). Technically a 68000 (as in pre-'020/030/040) could probably be easily built, but it looks like SDL requires Thousands/Millions of colors, so where could you run it?...besides...the extremely slow cpu! ---- The changes I had to make weren't clean, as I was cowboy coding, and some (temporarily) hard coded. The end result will be a modified version of the SDL-1.2.15.zip from the MG page. I need to do diffs to see where everything I did actually was, but cleaning it up for release won't take "long". Then, you could use the same source for both PPC and M68k, MPW or whatever version of CW. The only thing that'll need to be changed to build m68k is the settings in "SDL_config_macos.h". ---- Sadly, because it requires Thousands/Millions, you can't run the SDL MvM inside itself! (I know @Jatoba probably thought of that!). More reason for us to continue a Color QuickDraw (not SDL) color port of m68k MvM in the other thread.
Last Edit: December 31, 2024, 20:01 by lauland
lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #7 on: January 01, 2025, 17:45 So, in an attempt to test SDL m68k more, I did a quick search on SDL games at MG and found a couple decent candidates. Others either were SDL2, or required OpenGL. I built both for PPC first. http://macintoshgarden.org/games/sdl-scavenger http://macintoshgarden.org/games/breaker-0 Scavenger I now have a fully playable MacOS 7/8/9 PPC version. Had a LOT of fun with it trying to find its datafiles in directories with "/" or "." in the names, so as a quick hack, just dumped all the data in the same folder as the app, and removed the paths. Will fix that at some point and add to MG page. Interestingly it had the same problem with keys as MvM...it was looking in keysym->sym. Changing this to keysym->unicode fixed it. So that looks like a bug in SDL, which I'll look at fixing. The m68k version launches, draws the screen once, and then crashes both SS and Basilisk. So will debug on real hardware. http://revontulet.org/2025/01/01/be776144cafc460bb4701019bdc8ae31.png Strangely, did NOT run into the same problem with datafiles for Breaker, and it "just worked" after adding a couple type casts. The MacOS 7/8/9 PPC version works very well and will add to MG page. The m68k version THINKS it is running, according to numerous debug printf's, but only shows a blank screen, so likely a problem in SDL. (Or goofy assumption in the breaker code). http://revontulet.org/2025/01/01/86f322bcb78447adbfe1403a64603148.png ---- Looking for fun 2D SDL games didn't show up much, so I guess I overestimated how useful a non-OpenGL m68k SDL might be. A bit shocking finding out there are a lot of SDL things (OpenGL or not) out there that aren't "officially" supported for MacOS 9 PPC, scummvm being an obvious one. There really should be an up-to-date official binary for it, unless it broke hopelessly at some point. I guess MacOS 9 SDL 1.x has been neglected a bit, maybe this effort can revitalize it. I'm calling my SDL "sdl-1.2.15wip", have cleaned up the dirty hacks etc, and it now auto detects m68k and leaves out what isn't supported, so the same tree builds PPC and m68k. Will upload it to MG at some point. @Jatoba and I can use it to try and fold in "1.2.16" updates, as they come, so we'll have a decent updated MacOS 9 SDL.
Last Edit: January 01, 2025, 17:52 by lauland
cballero 1024 MB Posts: 1176 System 7, today and forever	Reply #8 on: January 01, 2025, 18:23 You have no idea how cool all of that sounds! even if I have just a faint idea of the implications of having such an updated tool like this definitely keep posting on your accomplishments and thanks you two, for just attempting these exploits! it’s a New Year’s gift for sure!

Jatoba 256 MB Posts: 270 System 9 Newcomer!	Reply #9 on: January 02, 2025, 11:37 Quote from: lauland Sadly, because it requires Thousands/Millions, you can't run the SDL MvM inside itself! (I know @Jatoba probably thought of that!). More reason for us to continue a Color QuickDraw (not SDL) color port of m68k MvM in the other thread. Bingo! Now, you see, technically... SDL vMac II should still be able to run SDL vMac II if you have System 6.0.3 ~ 7.5.5 and this installed, but alas not only is that untested, it is not good enough for running System 4 ~ System 6.0.2 with! So indeed it is all the more reason for us to pursue Color QuickDraw if we can. --- It's fantastic you just "casually" got us not 1, but TWO new games working 100% under PPC System 7 ~ Mac OS 9 just like that, while pursuing 68k SDL goals. Two games that were, so far, locked to no earlier than Mac OS X 10.5 Leopard, and only Intel (yuck!) at that! This is epic! Sad to see OpenGL giving troubles to 68k, though. Is the issue with OpenGL + 68k the fact that we don't have the source code to compile a 68k OpenGL SDK with, and/or is the problem that the OpenGL code itself does not support GPUs or other graphical accelerators that are available to 68k hardware? Can OpenGL leverage a CPU, in the worst case scenario, to do "rendering in software", as they say? --- Quote from: lauland I'm calling my SDL "sdl-1.2.15wip", have cleaned up the dirty hacks etc, and it now auto detects m68k and leaves out what isn't supported, so the same tree builds PPC and m68k. Will upload it to MG at some point. @Jatoba and I can use it to try and fold in "1.2.16" updates, as they come, so we'll have a decent updated MacOS 9 SDL. Really looking forward to that upload! A unified 1.2.15 codebase that works for both PPC and 68k, and that is ready to compile out-of-the-box for both MPW and CW? There's nothing else that one could ask for! I assume it will also contain that fix for r->sym / keysym->sym VS. r->unicode / keysym->unicode, right? If you can actually pin this down and address it directly in the SDL 1.2.15 source code, this honestly would warrant a patch via a pull request AKA merge request directly to the official GitHub repository for SDL 1.2.16 (HTTPS link). Another pull request / merge request there is for us to do for 1.2.16 (and locally for our 1.2.15) is to change the value for #define VERSION_STRING in src/main/macos/SDL.shlib.r (HTTPS link) from "1.2.13" to "1.2.16" ("1.2.15" for 1.2.15), so that we no longer get confused looking at the compiled shared lib via Get Info and seeing "SDL version 1.2.13" in there. This seems like a small, unimportant thing, but it's actually a big deal! It really can throw us and other people off. I hope I find some time to assemble a proper "SDL devel" for 1.2.15 within a few days, but I think a "1.2.15wip" SDL devel will be even more interesting! Let's get both set up if we can. Same goes for a "1.2.16 SDL devel", which can be based off 1.2.15wip, and we can drop the "wip" from it since SDL 1.2.16 is an "unfrozen", ever-changing version in-development, and I sure won't accept 1.2.16 if it lacks the patches and Mac OS improvements for both the developer AND end-user that are found in 1.2.15wip! So to me 1.2.16 = adequate, proper Mac OS support with all known bugfixes and improvements, plus whatever else other people added on GitHub to improve over 1.2.15. --- By the way, I investigated again after years, and once more I notice there seems to never have been a Mac 68k official port of SDL. During the SDL 1.0.x days, even Mac PPC was only deemed "experimental", with the "experimental" bit being dropped by the time SDL 1.2.x was out. It IS noteworthy that, up until at least SDL 1.2.6 there WAS "Amiga" support, although I have no idea if that's 68k Amiga and/or PPC Amiga, but it would bode well for 68k Mac if that means 68k Amiga. Starting with SDL 1.2.7, no more official "Amiga" releases were there, similar to how starting with SDL 1.2.14, there were no more pre-compiled Mac OS releases. A FULL archive of ALL SDL (1.0, 1.1, 1.2, 2.0, 3.0, with separate downloads for runtimes AKA shared libs VS. "devel" VS. source code) is still hosted in the official website at https://libsdl.org/release/ . Note that SDL 2.0 changed version numbering pattern some 2 years ago right after version 2.0.22, with the next version being 2.24.0 (which is silly considering they still refer to it as "SDL 2.0, a mistake they also do with SDL 3.0 even for a release like SDL 3.1). --- Since I'm on a roll right now and have a small gap of free time to use NOW, let me also address SDL2 for Mac OS and Mac OS X: The SDL2 wiki's "Installation" section (HTTPS link) mentions that SDL 2.0 dropped support for Mac OS X versions that predate Mac OS X 10.6 Snow Leopard, and incorrectly assumes that architecture is Intel only, as well, and thus they declare Mac OS X PPC as a whole is in itself "unsupported", officially, that is. They even have the gall to suggest adding supporting code to the main official SDL 2.0 GitHub would make the codebase "uglier" (case in which I would ask them to get rid of ALL the platforms they support, those fools), so based on that, they may or may not accept pull requests / merge requests if we restore Mac OS X PPC support ourselves. But! The important part here is, as they say themselves: "That being said, some small changes can make it work". Additionally, this archived link reveals they were once distributing SDL 2.0 for Mac OS X 10.5 Leopard (Intel only) themselves, so no need for Snow Leopard unless if we work with the latest SDL 2.0 (which we might). Since we have our hands full with SDL 1.2 as is, and with Mini vMac II, I think we can safely ignore SDL 2.0 for now. But if we do eventually work on it, and compile the latest version for, say, Mac OS X 10.2.8 Jaguar, we are good to give porting SDL 2.0 to the actual Mac OS, such as Mac OS 9, a try. (And from there System 7 PPC, and from there 68k Mac. But I know, I know, I'm getting WAY ahead of myself. Still, I see the path, so I report it.) We could also eventually keep an eye out for SDL 3.0, too, but only after it's no longer in pre-release (version 3.1.x right now, not "properly" released yet), and only after we got everything regarding SDL 1.2 and 2.0 in working order for both Mac OS and Mac OS X. If that day ever comes, that is! Let us see! --- @lauland If you feel like trying out more SDL projects to port to Mac for SDL 68k testing or even for the very sake of having them brought over to the Mac at all via PPC SDL if nothing else, there's an interesting list of candidates archived in SDL's old website (e.g. BoyCott Advance/SDL, ported for "everything", but not Mac OS). There's mention of there being a total of 185 projects supposed to be listed there, but because they were split in multiple pages, not all of them got archived with the latest timestamp, and so we might not be able to see the names of all of them from there, but we can see most of them if we change the Wayback Machine date around. At least 180 of the 185 were. Links below: With 25 entries per page: 1st page (based on 180 titles) 2nd page (based on 180 titles) 3rd page (based on 180 titles) 4th page (based on 180 titles) 5th page (based on 180 titles) 6th page (based on 180 titles) 7th page (based on 180 titles) 8th page (based on 180 titles) To help identify some of the 5 titles whose names/links might be potentially missing from Wayback Machine: 1st page (based on 181 titles) 1st page (based on 182 titles) 1st page (based on 184 titles) 1st page (based on all 185 titles) 2nd page (based on 181 titles) 2nd page (based on 182 titles)
Last Edit: January 02, 2025, 11:41 by Jatoba
lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #10 on: January 02, 2025, 17:30 MvM running on MvM: I actually lied a little. I think you are 100% correct, with 32 bit (which refers to the pixels, not the code) Color QuickDraw installed, it should launch. But I don't think the emulated Mac in MvM will be able to switch to higher than 256 color mode. So MvM SDL m68k will probably display incorrectly, but run inside itself. I leave that to you to try... I always thought SDL (on other platforms) was supposed to be able to run in 256 color mode, and maybe so it having trouble on MacOS 9 is due to neglect or nobody writing support. But who knows. Maybe even on the "other ancient" platforms like Palm, Amiga, and Atari it REQUIRES a "video card" that can do truecolor? ---- Breaker and SDL Scavenger: Yeah, I've been watching what @thedoctor45 (and others?) have been doing at MG, doing "unofficial Leopard ports" of all sorts of open source games. Commendable effort! But I've always been slightly disappointed they don't include the source code (and Makefiles or XCode projects) they used. It isn't clear why they concentrate on Leopard (no Tiger?) and/or Intel either, and I always wonder "no MacOS X PPC build?!?" when there isn't one. Without the source, I can't tell if they ran into problems, or just didn't bother, if they did include it, someone else could try. Since I got Breaker and SDL Scavenger running on MacOS 7/8/9 of all places in about a day, it is obvious they could've done MacOS X PPC versions! I'm not saying it was trivial, but it was pretty "casual", and not a huge amount of work. I was thinking of separately writing up how I did it, to show other people how, probably include READMEs when I post the two games to MG. What @thedoctor45 has been doing is extremely good, but not necessarily my cup of tea. They're basically providing binaries for people to play, which is wonderful, but I think my time personally might be better spent on the really weird stuff that I seem to have some talent for, and leave porting for others. ---- OpenGL: As far as I know, there was no 3d accelerator hardware for m68k...other than cases where people may have hacked something like an ATI card via got knows what (for example). In the Amiga/Atari m68k world there ARE such things, "relatively" common. It'd be technically possible for m68k Macs, but nobody bothered, since we got PPC... Running OpenGL in software only isn't an absolutely terrible idea...The original Quake on PC (and Mac?) did that very well, they used a subset of it (MiniGL etc). The question is how well it would run on actual m68k Mac hardware. There is "a 68k Version of Quake runs slowly though on a 25mhz 68040 Quadra 700", I'll take a look at it and see how they did it (ie is there an m68k OpenGL, or at least MiniGL, in there?). ---- "wip" verion of SDL: I'll get the "wip" version up there in a few/couple hours. The code is cleaned up enough. I was hesitant because I wanted to test I hadn't inadvertently broken anything in the PPC version...but after reading all you've said I had a different idea: The "wip" version can be a "bleeding edge" aka unstable "release" where things are tried out. People could download it and use just the runtime lib (none of the devel) to try out if they liked. In fact I think "unstable" is an excellent name and will use that. For "unstable" there doesn't need to be a separate "devel" (vs runtime), but you can do one for the 1.2.15 because that might be useful. Or not, as the two of us might concentrate on rolling in 1.2.16isms into my "unstable". The point of having a separate "runtime" download is for end users with no interest in coding just getting the shared lib...and while "unstable" is still considered unstable, which I do consider it without testing it on a bunch of existing games, there's no point in people downloading it just to get new features...bugfixes are a different story though... ---- SDL MacOS 7/8/9 bugs and MacOS X versions: I wouldn't be entirely surprised if the goofy keysym->sym problem is one of the reason interest in SDL on MacOS 7/8/9 faltered. A bug was introduced, games started not working, but nobody bothered to figure out why. I'll see what is going on in the code... Building SDL 1.2.x (and SDL2) for MacOS X versions that aren't "officially supported" is a definite possibility. Probably near trivial compared to getting it on System 7.x m68k...you or I could look into that too at some point. ---- SDL2 and/or compiler features: One big hurdle for SDL2 may end up being the compiler. If they started using a lot of modern features, just getting any of it to build for MacOS 9 could be a challenge. One of the SDL games I looked at porting (I think it may have been "SDL-Ball") used the C++ STL and other modern language features and CW6 immediately threw up its hands. (Newer CW's might work...but porting MacOS 7/8/9 SDL OpenGL games would be a different project...see below...) I looked into Retro68 and have a build of it on my Intel MacBook. (Despite its name, it supports PPC also). It is a "modern" compiler. I'd like to try building SDL for it at some point. Porting old Mac code to any version of gcc is a bit of a pain, but it might be possible...and open up whole new possibilities. Using a cross-compiler is also no fun (compared to just CodeWarrior ON the Mac itself), but probably an eventual necessity in the 2020's and on. ---- Further SDL ports of existing games: As far as porting other SDL projects to MacOS 7/8/9 SDL, like I did Breaker and SDL Scavenger, as I said above about @thedoctor45's efforts, I could do that, if there was a demand...but it wouldn't really be "a challenge". I don't mean to sound all full of myself (I'm sure I must), but that might be better left to others...let them feel the joy and amazement when they see the screen pop up for the first time! It's dealing with CodeWarrior, include files, adding type casts, and other grunt-ish work. It's a bit of what I've been talking about in my other posts about helping people learn programming and empowering others. I'd be truly over the moon if the SDL work you and I are doing inspires someone to do what @thedoctor45 has done, and someone else starting posting new MacOS 7/8/9 SDL game ports at MG...THAT kind of thing, showing others what they could do if they just try, is what I've been wanting more than anything, and trying to get across. ---- Sorry about the extremely long post, I tried to make it readable, but cover everything...
Last Edit: January 02, 2025, 18:19 by lauland
lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #11 on: January 02, 2025, 20:13 Have uploaded my efforts as "sdl-unstable.sit" to http://macintoshgarden.org/apps/sdl-1213-simple-directmedia-layer Will update it with a date note when there's anything new. It includes built binaries for the libs and test programs (I only converted a few to m68k). Only tested in CW6 debug and static, not shared lib. It detects PPC vs m68k in SDL_config_macos.h, and everything is enabled for PPC. I enabled everything possible for m68k, I got audio building, but disabled by default, as I haven't tested it. My Apple Event handling code is in SDL_main.c but disabled by default, as it is fugly, and want to test further.

Jatoba 256 MB Posts: 270 System 9 Newcomer!	Reply #12 on: January 02, 2025, 21:10 @lauland I know what you mean about @thedoctor45, he's a cool guy who did lots of awesome compiling/porting work, occasionally even for PPC Leopard (and rarely Tiger IIRC?), but somehow I hadn't yet thought these projects were SDL 1.2.x, and/or how "close" they actually were in being Mac-OS-compatible. But after seeing you sprinkle some Mac-life powder over these projects, it became clear how big a deal this is: "Where's the source?" Being the cool dood that he is, I have a feeling @thedoctor45 would gladly share the sources / project files of his efforts, IF we ask him. So I will try asking him this weekend, if he's still around the Garden. By the way, you don't sound full of yourself at all about the whole "challenge" vs. "grunt work" bit, that's completely understandable, and a point you always made clear to everyone. I'd love to become one of those people who "randomly start porting over SDL stuff to System 7 & later & posting them over at the Garden" and, honestly, seeing all these SDL & Mini vMac developments lately, and you pulling off all these binge-compiling stunts with amazing returns IS very inspiring to read and keep track of. So I'm sure these accomplishments equally resonate with others reading along all of this, as well. Programming, compiling, porting... all of that isn't magic, and while there ARE challenges for most of us, myself included, it is all perfectly attainable if we just sit and dip our feet into the water. In fact, that is why I created that "How to compile Mini vMac" GIF, because I wanted to make the point none of this is scary, and that "YOU, the VIEWER" can do it, too. If you actually make a "README" or whatever for the compiling steps you took for Breaker and SDL Scavenger, I know for SURE I'd go ahead and compile it, even if part of the steps is tweaking source: that'd be a GREAT teacher, and a massive encouragement to just independently start tackling such projects on one's own, for US to also eventually make our own "README"s for others regarding other porting efforts. By the way, I wasn't sure if Retro68 had also PPC targeting support, that's very reassuring to hear... Now I know I don't have to have my reservations towards it, whenever I'm not on Mac OS for whatever reason. (But I will still favor MPW + CW on the Mac directly whenever possible, like you said.) Retro68 as a means to bridge later language revisions of C++ (and possibly even C)... That's a great idea. I hadn't really thought much of it, but it highlights how awesome Retro68 really is. I'm looking forward to doing something or the other with our SDL efforts and ambitions, hopefully this weekend... I'm also really looking forward to seeing further developments on your "unstable" SDL releases! Personally, bringing forward 1.2.16-isms is totally fine for it! Like you said, it being the "bleeding edge" SDL 1.2 release, with even partial 68k support added, makes the latest 1.2.16 code changes perfectly fitting for it! A reminder for myself, and for anyone else following along, using BBEdit's "diff" tool to compare that "unstable" codebase with the "1.2.15" codebase will also be highly educational... and a good guide.
Last Edit: January 02, 2025, 21:13 by Jatoba
cballero 1024 MB Posts: 1176 System 7, today and forever	Reply #13 on: January 03, 2025, 05:44 @Lauland: you, Jatoba and so, so many here and in ll the Mac retro forums have brought so much life into this otherwise forlorn space when Classic Macs were officially retired, that it serves to instill hope for so many more cool things to come from it, including a new generation of Classic Mac programmers and enthusiasts! Most definitely keep posting your adventures and yes, youtube videos do help provide further incentive to those less versed in all things programming, myself included! Thanks again guys!

Bolkonskij Administrator 1024 MB Posts: 2023	Reply #14 on: January 03, 2025, 14:42 Quote from: Jatoba So I'm sure these accomplishments equally resonate with others reading along all of this, as well. Yeah, I want to stress this. I'm reading all the posts, at times with a bunch of over my head, but generally learning a lot. I just shut up and listen because I don't have much to add, and that's how a lot of readers feel I suppose. So don't feel disheartend if you don't get five different replies. You're making an impact. In fact, reading about all your efforts has me feeling the urge to pick up coding in C on the Mac again ... :-)

	Pages: [1] 2 3 ... 8

© 2021 System7Today.com.
The Apple Logo, Macintosh™, Mac OS™, and others property of Apple Computer, Inc.
This site is in no way affiliated with Apple Computer, Inc.