|
|
|
|
| Welcome, Guest | Home | Search | Login | Register | |
| Author | Attempt to add color to MvM running on MacOS 7/8/9 PPC (Read 168220 times) | ||||||||||||||||||||||||||||||||||||||||||
|
Jatoba
256 MB  Posts: 270 System 9 Newcomer! 
|
Reply #45 on: January 27, 2025, 17:20
The "cooking recipe" for taking a stock 3.5.8 MvM source and "colorizing" it is something I will definitely lay out very clearly so anyone can do it. Documenting it doesn't take the fun away from me, I actually enjoy "bridging worlds"... I'd like the page to make it possible for casual Mac users to do it themselves! Maybe another GIF to give them courage, showing them they can also do some copy+paste-fu and that the "Make" button doesn't bite. |
||||||||||||||||||||||||||||||||||||||||||
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #46 on: January 27, 2025, 19:18
|
I think for PPC it is relatively straightforward, and you can just use the normal MvM generator script, as long as you remember to specify sdl, mppc and cw5 (I think those are the params?). I don't think there's any patches needed, except MAYBE changing in OSGLUSDL.c: #include <SDL/SDL.h> to #include <SDL.h> (unless you bother moving your SDL include files, etc, totally optional). Oh...and the goofy unicode/sym fix to get the keyboard to work... The problem if I remember it is with the cw xml project file you end up getting and importing, you need to add Access Paths to your copy of SDL (devel, unstable, or whatever), as it doesn't know where SDL is. Same with MPW version you need to tweak the makefile and/or put SDL EXACTLY where it expects it. I think in CW you have to add ALL the lib files (not just SDL, but MacOS and MSL) by hand too, but can't remember...which is a pain... I think MPW you don't have to do this? ---- The m68k version is a hack, which we will HAVE to distribute as source...the MvM generator script does not create m68k SDL folders. For the record, I took what was generated for PPC SDL (stock as above), added the Access Paths, Libs (but different from PPC's) etc. I then changed the Target Type to m68k and had to get everything set up for that. We will absolutely distribute the m68k version with a project and an exported xml as there were too many tiny changes to list sanely. I then had to make a some changes to the source, I can describe them on the page if you like, or, since color MvM SDL for m68k is just a curiosity (other than when running in Basilisk), we should probably just put the source and binary .sit files up as is, labeled "experimental". ---- The point of all the above is we should MOSTLY focus on "ready-to-run" binaries for people who just want to run the thing. Describing how it came about will be for the curious, but if someone just wants to use it, they can skip over and just download the binary .sit's (and skip the source ones). Or something like that...
Last Edit: January 27, 2025, 19:26 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #47 on: January 30, 2025, 14:22
|
"Mini vMac II Color Builds for Mac OS" page has been created and added to the Macintosh Garden! Will improve / flesh it out accordingly as time permits. Thanks once again to @lauland for making it reality, and to everyone else who also helped! (@MTT and others! This WOULDN'T have been as successful without your valuable input!) EDIT: Here's the link.
Last Edit: January 30, 2025, 14:25 by Jatoba
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #48 on: January 30, 2025, 15:49
|
Wh00t! It's finally "out in the wild", and now the masses will see and try it. Awesome job, as always on your MG pages!!! I think those are actually quite old builds, but fully working and no known bugs... If I remember correctly, the SDL's I used were missing bits at that point, but nothing MvM ever uses. I'll build fresh ones anyway, and update soon! ---- I was thinking about how this actually all came to be and here's the sequence as I remember it... @Jatoba posted this on macos9lives.com, which caught my eye...I was looking for ANY posts here, at MG, there, and on pretty much any Mac sites about programming: http://macos9lives.com/smforum/index.php?topic=7003.msg53775#msg53775 He was actually compiling SDL for Classic MacOS, which I thought was mondo cool! I'd used SDL a LOT on Linux, Windows and MacOS X, but never on MacOS 9 and wanted to get back into Classic coding. So I posted a reply and then started watching his work on SDL using MPW. I then tried it myself... Meanwhile, I was between projects, so I posted about looking for something to work on, and he replied about MvM not being available in color here: http://system7today.com/forums/index.php?topic=3931.msg18038#msg18038 We then both started looking at MvM, and I started building it in MPW (using his amazing "gif tutorial" which visibly showed how easy it was), as he was working on this page: http://macintoshgarden.org/apps/mini-vmac-source-code At some point he mentioned it was possible to pass parameters to the MvM source code generator to use CodeWarrior instead of MPW, which was quite exciting because MPW is...um...not known for user friendliness... I looked at the code and noticed that the MacOS version of MvM only used the original B&W version of QuickDraw, so doing color that way was completely impossible. I hacked around using the more modern Color QuickDraw, but didn't get too far...the MacOS code was VERY old... He then mentioned it was possible to pass a parameter to generate MvM source to use SDL, instead of the MacOS toolbox...which really caught my eye...we both knew that version HAD to use color, and would probably save us a lot of time and just solve the problem in one step....if we tried it with is work on SDL for MacOS 9... At that point I was building SDL using CodeWarrior, and had gotten an experimental 68k build of it going. I put two and two together and wanted to build an SDL 68k MvM, mostly just to test that 68k SDL was possible...which I eventually did, but the resulting MvM is far too slow to be useful on real hardware, or even in SheepShaver, although it runs well in Basilisk... Of course, we'd also built SDL MvM for PPC, and found it ran perfectly, and there you have it! (FYI Added a note about how slow the 68k version is to the MG page) Funny note: In the 68k screenshot on the MG page you might noticed I'd renamed a couple folders with a bunch of a's in them. This was because at one point I didn't have the keyboard working fully...all keys registered as "a"!
Last Edit: January 30, 2025, 16:15 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #49 on: January 30, 2025, 16:55
|
@lauland That about sums it up. What a journey! I couldn't believe only 1 month passed with all this... The whole thing taught me an unbelievable amount of things about CodeWarrior, C, shared libraries, Mac OS programming, SDL programming, linking nuances, various compiler "delicacies" (as in, nuanced settings), debugging, porting tactics and so on... Before I brought it up myself, @MTT had beaten me to the punch in requesting Color MvM on Mac OS. But even more importantly, it's thanks to @MTT that we knew MvM 3.5.8 was fine as long as we used CodeWarrior to compile it instead of MPW. If it hadn't been for this, we all would have been doing work only on version 3.4.1, and reinventing the wheel in trying to "fix" 3.5.8! But now we have both 3.4.1 and 3.5.8 under control -- and in color! It was also thanks to "Mabinogian" over at this Garden page's comments that I learned that version 3.4.1 of Mini vMac still had value over 3.5.8, and still does until we figure out how to compile 3.5.8 with MPW correctly. Now, many chapters have been closed, but still not yet the whole book: - Above all, there's the thought of converting MvM to use Color QuickDraw without any SDL dependency, with 2 main routes available: decarbonize the OS X version and replace Quartz with Color QuickDraw, or Color-QuickDraw-fy the original B&W QuickDraw code, the latter being probably harder; - Then there's building MvM 3.5.8 with MPW correctly, like mentioned previously; - And, then, if we feel adventurous enough... There's the thought of just porting MvM 3.6.x (AKA version "36") and its successor, version "37", to Mac OS, as those versions weren't shipped with a "source code preparer" tool, and Mac OS was explicitly ignored by the author for everything since (and older versions, documentation & compiler services for Mac OS removed from the website etc., for no good reason). Again, still can't believe it's been only 1 month. We went all in into the SDL rabbit hole, as well, and "looted" treasures off it all, with all these brand-new SDL Mac game ports coming out, LOTS of lessons learned, shared... Even SDL2 made a cameo, maybe will even make a comeback later? Oh, and let's not forget Mesa for SDL as a fallback option for OpenGL, in particular 68k... Well, I will now go get "back to Mac-work". 
Last Edit: January 30, 2025, 17:01 by Jatoba
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #50 on: February 03, 2025, 16:37
|
Quote from: Jatoba The "cooking recipe" for taking a stock 3.5.8 MvM source and "colorizing" it is something I will definitely lay out very clearly so anyone can do it. Whew. I actually wrote it step-by-step, so that truly any person able to read can do it, from children to grannies. Instructions for CWPro6, for a PPC build. Thing is, I can't publish it yet, because I noticed we still need to build the SDL shared library for the improved SDL effort, and have that build available inside the .SIT file, so that the steps won't also have to include how to compile the SDL shared lib. @lauland If the code from download #2 in the SDL page didn't change, I don't mind going through the effort of compiling it, then reuploading it to the same page. But I certainly don't want to step on your toes, and maybe you'd like to do that yourself, and/or maybe you have newer code that hasn't yet made it to the SDL 1.2 page? By the way, is it possible to compile Color MnvM with the static lib instead? I tried it just now, but got 40-ish errors of functions not being found...
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #51 on: February 03, 2025, 18:25
|
@Jatoba, please go ahead and try a build when you have time...if only so you might find problems in the process that I may have glossed over, better to be sure you can reproduce it. No MvM code in the PPC version was changed (just the project file needed setting up), the version in the download just used an older build of SDL. None of the SDL changes affected MvM in any way (other than the AppleEvent code and you can leave that out at will), so using all stock code should work, and will be good test. The 68k build is another story, and like I mentioned before is based on the stock QuickDraw version, with the PPC's SDL OSGLUSDL.c, but with a few little patches. Do a "Find differences..." in BBEdit or TextWrangler to find them. The 68040 fpu code I left out was due to CW6 limitation on size of switch statements...MPW build might not need it. Absolutely possible to build everything static (the 68k is only static for now, until/unless I get CFM-68k fully working and prob not worth the effort except for OpenGL). Not sure about the errors you're seeing, describe them and we'll figure them out. I have it building that way and could just upload my version to the page, but, as above, would probably be better to work out any issues in the build process since you're writing up (awesome I'm sure!) instructions anyway... ---- Be sure to have "Enums always int" turned on if you're building in CW...if keypresses don't work, find the keysym->sym and change it to keysym->unicode to get it working if the bug bites you...let me know as I'm trying to hunt it down.
Last Edit: February 03, 2025, 18:30 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #52 on: February 03, 2025, 20:28
|
@lauland Tried using the static lib again, got the same errors (maybe I need to expose the functions somehow?). The errors are all from the linking phase: http://revontulet.org/2025/02/03/e7074884eb5c4071b1aef6b3e3ddb2df.jpg
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #53 on: February 03, 2025, 21:07
|
I put a screenshot showing all the libs I used in Abbaye, just because it is fresh, good example of building static, and put it on the SDL MG page: https://macintoshgarden.org/sites/macintoshgarden.org/files/screenshots/Screenshot_2025-02-03_at_1.56.26_PM.png (We can add an explanation later...ie "You may need the following libs if building static etc") The key with the errors you're seeing is missing Input and Draw Sprocket...but I'm including the picture because you'll likely need OpenGL too. The others like unicode, dialogslib cursordeviceglue etc I needed to add also, I just kept adding until it finally found all needed funcs...but that might EXACTLY be why it is requiring MacOS 8.6...it could be the key to not REQUIRING them is doing a shared and not static SDL lib? So I still need to figure out if what I'm doing is exactly right. I guess you should try NOT adding anything but DS and IS unless you need to...and see what it asks for? Maybe you'll end up trying something different better than what I did.
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #54 on: February 04, 2025, 07:30
|
Quote from: lauland ...but that might EXACTLY be why it is requiring MacOS 8.6...it could be the key to not REQUIRING them is doing a shared and not static SDL lib? Just what I was also thinking, as I was reading you mentioning I might need to add those other extra libs. ...Which makes me think: When I compiled the shared lib for SDL, it was 100% useless (apps depending on SDL could not start as they could not find ANY function in the SDL shared lib), until I added the very-simple, pure text, ".exp" file that is included with the SDL CW source, and configured the project or target settings for the linker to use it. THEN I had a valid SDL shared lib, after recompiling/relinking. So MAYBE... that ".exp" file was also listing not just SDL functions, but sneakily also functions from InputSprocket, DrawSprocket and OpenGL? Shared Lib + a properly set up / "extravagant" ".exp" file = a "weak link" shared lib? Shared Lib + a ".exp" file set up with ONLY the functions that ACTUALLY are in the lib = a "hard link" shared lib? Maybe this is not possible with static libs, because they are technically not all that different from "native" source code or "native" compiled ".o" objects? So if something isn't there in the "code", then there's no "lying" around it? Unlike with Shared Libs? Am I thinking right? I will try to "sort out" your current "SDL unstable" and reupload it to the Garden tonight after work if I get the chance, with the CWPro6 project configured to build the shared lib, and with the shared lib pre-compiled.
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #55 on: February 04, 2025, 15:29
|
I think you're arrowing in on the issue! I definitely don't understand the full implications of the .exp file and/or including the shared libs a STATIC library uses in the project file, if I'm doing it properly or not. Basically I don't fully understand how to USE shared libs at all, programming wise...this is why I'd been mostly building things static, in the hope that I DO understand doing it that way...although it seems not the case! Definitely try things out...I'll be doing so too, but have been more focused on bugs (and building Super Mario War running, and want to get back to work on SDL2). If only because those are "easier" for me, and I know I'm pretty confused about shared libs. FYI I got SDL 68k building as a "CFM 68k" shared lib. I think I used a separate project file to try and keep confusion down, but may have just used the existing "Shared" target in the main project, but, either way, we should work on the fixing the PPC version, it's better because I'm sure there's more knowledge out there about that platform. I really don't like requiring 8.6, Game Sprockets and OpenGL to run apps that don't use them, since I know our SDL works on 7.5.3, but it works with the requirements for now. As far as I could tell the .exp lists which funcs you want to expose in a shared lib. You'd also have one that were just internal, and they wouldn't be listed. Other platforms like Windows have very similar things. A .lib file is really just a collection of .o files, in all compilers other than CodeWarrior, so act the same way. I suspect it works that way too, but you just can't ever get to the .o files, they're all stored glommed together in the binary files in the "project data" folder that matches the .mcp file. You'll noticed they always have byte numbers for code listed in the project file because they're included wholesale in the built binary. I think the trick with shared libraries lies in using the "stub" versions...and maybe that's how you ensure the link is weak?
|
|
Pages: 1 2 3 [4]
|
| |||||||||||
|
© 2021 System7Today.com. |
