Notes on using CodeWarrior to port games, etc.



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


Author	Notes on using CodeWarrior to port games, etc. (Read 108614 times)
Jatoba 256 MB Posts: 270 System 9 Newcomer!	Reply #45 on: March 01, 2025, 12:46 http://revontulet.org/2025/03/01/5394a524a7574dffb053dbe9e234b626.jpg Carbon libs compile, CWp7 project file also OK for that (and the other targets), 68k CWp6 project now references Mesa locally (headers/libs copied over to "Support", very light), no reference to "attic" or BeOS, all compiling fine and looking good... ... Except those elusive CFM-68k Shared Libraries, of course. (The actual one and the "stub" for it.) I can't compile any CFM-68k shared lib of ANY kind, anywhere. What is the secret for that that we are missing? I will try to hit the CWp6 docs/manuals... Other than that, gotta deal with older headers for CWp5 to compile SDLmain, like we talked before. And I will have to fight a battle at some point for unSITting the StdCLib folder due to some other conflicting project. Nothing else I'd know how to improve upon after that in SDL 1.2.16+! Then I can move on to the add-ons (MPW mainly) and the games.

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #46 on: March 01, 2025, 23:47 Awesome work! You really pulled it off! Quite impressive seeing all the versions sitting together like a happy family! Yes, the only one missing is an elusive Shared Lib for M68k...which would have to be CFM-68k (which is the secret, you can't mix plain M68k and CFM-68k)...which, BTW would be required to get OpenGL (via Mesa) for m68k SDL. (A LOT more work is needed to "hook" Mesa in via loadso style linking and loading...but it COULD be done in theory...it all builds together, just isn't "hooked" in yet). I did NOT ever get a shared lib version for CFM 68k built...I think I tried, but didn't need it at the time, so didn't pursue it. I did it all static...even for CFM-68k... ---- For the record, there is a difference between building things as CFM-68k apps (ie runtime), and using CFM-68k shared libs. The testing I did with CFM-68k was with a STATIC version of SDL-CFM68k. I have a separate CodeWarrior project for doing SDL CFM-68k. This project file would actually produce TWO NEW versions...a static CFM-68k SDL lib and a shared CFM-68k SDL lib. I didn't include ANY of my CFM-68k stuff in anything I've released as it was all strictly experimental. The way to think about CFM-68k is that it is the same kind of runtime as standard PPC is...ie PPC is ALWAYS cfm. So building CFM-68k stuff is most like building PPC stuff. It could be possible to "roll in" my experimental CFM-68k stuff into the main SDL cw6 CodeWarrior project...but it would be adding THREE new targets...the lib both static and shared, and a new "SDLMain-CFM68k"...yes, that is needed TOO. Anyway, as you can tell, CFM-68k is a big subject, but it all looks good...just adds even more and would complicate our CodeWarrior project as I stated. ---- Mesa for m68k is built as a shared lib only, thus anything using Mesa must be CFM-68k. So adding OpenGL to SDL m68k (using it) would require CFM-68k, which is why I looked into it. It IS possible to build Mesa for PPC static, but I could not get it to work for m68k as static, and all of its projects do not include any m68k static targets (only CFM). It could be done in theory...but PPC SDL loads OpenGL shared, so it might just be easier to keep everything shared to get m68k OpenGL in SDL... ...not that it may be worth it in the end, since it is ALL software rendering and will be VERY slow. But worth pursuing maybe just "because it CAN be done". So...I can package the CFM-68k SDL I have and get you a copy...but at some point we'll have to decide...do we want to keep it a separate "experimental" package, or roll it into our main cw6 SDL? ---- BTW all this work you've done with Carbon and the Shared Libs (and more!) means that your "SDL unstable" is now ahead of mine...as you mentioned before we can just call it SDL 1.2.16, so once you package up and release everything you have, we won't actually NEED my "SDL unstable" anymore...yours can and will replace mine...and I'll need to roll all your changes into the copy of SDL I've been working with. If this were a race, you just passed me...
Last Edit: March 01, 2025, 23:56 by lauland
Jatoba 256 MB Posts: 270 System 9 Newcomer!	Reply #47 on: March 02, 2025, 08:06 @lauland I will put this current SDL work into Hotline, it should be there by the time you read this. Right now, I'm just making sure the SDL test projects also are "fine tuned", and see if they are buildable. For now my only change was to fix absolute paths by changing them to the appropriate relative ones. I noticed some of the test apps in the 68k proj were also still targeting PPC, so I changed those to 68k, but I'm not sure what is the adequate 68k configuration for them, so perhaps you could take a peek at that and see what settings fit them better? Other than the tests, the only "known pending items" in this SDL version I'm uploading are: - CWp5 project: can't build SDLmain (both StdCLib and the usual one) due to older Apple Headers; - CWp6 68k project: shared lib and stub; - StdLibC folder in "Support": Has been unSITted, which might conflict with SOME SDL-related project (I will look into the other projects right away to make sure this is addressed); - Honorable mention: Can the "Carbon Support" folder, which was added to Support:Carbon:, be trimmed down a little? It includes the whole of Apple Universal Headers/Interfaces, which is adding some 50 MB (that's where Carbon.h also sits). By the way, if we included the latest Apple Universal Headers ourselves, the CWp5 project should be able to make use of that and get past its issue of older headers for SDLmain. But you are way more qualified to make this type of decision than me right now, so I will leave that up to you. (I'm fine with either decision.) With this, I'm moving on to SDL_mixer, SDL_image, SDL_net, GUIlib and SDL_ttf next. SDL_gfx will come right after those. ------- EDIT: I forgot to mention one thing I noticed in the 68k tests: one of the Access Path entries for various test apps is "{Compiler}:MacOS Support:Libraries:Runtime:Runtime 68K:Libs:", but shouldn't that be Runtime CFM68K instead? ------- EDIT 2: Likewise, another Access Path is "{Compiler}:MacOS Support:Libraries:MacOS 68K:MathLib68K:MathLib68K (Model Far):", but there's also MathLibCFM68K in there. Shouldn't we be using that one instead, too? (Incidentally, there's also a "MathLib68K (Model Near)" in there... is Model Far/Near related to 32-bit-clean and 24-bit-dirty 68k stuff?) ------- EDIT 3: For the 68k test targets that were previously configured as "PPC" that I changed to 68k, I configured them uniformly based on other 68k tests you had already configured like this: - Gave test app a non-generic name, based on test name + ".68k" (I like the shorter "68k" over "M68k", also so that it matches 3 digits like "PPC", but if you feel strongly about "M68k", we can change the test app names to that, too. I left the ones you worked on untouched, so the output for those apps still is ".M68k") - Default RAM moved up from 384 to 38400; - 68020 Codegen checked - Code Model kept as the default "Large" - Struct Alignment changed to "68K 4-byte" Some of the 68k test projects you worked on had different values for those, though: Code Model "Smart" is used in 1 of them, 68020 Codegen is not always checked, and Struct Alignment is sometimes just "68K". One OpenGL test app even was configured not as "Application", but rather as "CFM68K Application". I assume some of these differences between the apps are likely a "leftover of different past attempts", but JUST in case it is a deliberate decision, I left all such test apps untouched, without normalizing them, preserving the configuration they already had. Last thing we need is me screwing anything up! ------- EDIT 4: All uploaded to Hotline! :Uploads:SDL Uploads:SDL-1.2-main-20250302.sit* Just one final note, since all the Access Paths are fixed in all projects for all targets (even Windows on CWp6), I went ahead and restored the original filenames to the various loadso files. It should no longer cause us any more issues. Also, I don't know if it's related to the crashiness you experienced in CWp6 vs. CWp7, but switching back and forth between the 3 Windows targets for whatever reason destabilizes and bugs out CWp6, and a crash will eventually happen. Although in your case it could have also been just Sheepshaver being Sheepshaver, who knows. ------- EDIT 5: Reuploaded to Hotline with a small fix for the CWp7 proj as: :Uploads:SDL Uploads:SDL-1.2-main-20250302 (fix).sit
Last Edit: March 02, 2025, 14:52 by Jatoba
lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #48 on: March 02, 2025, 20:30 Again...awesome stuff! I'm on my MBP right now, so can't download from hotline without crashing, but will get on my ibook and grab what you put up ASAP! Yeah, I didn't fully finish setting up all the M68k SDL test apps...I only did the ones I needed to test what I actually worked on, and didn't bother changing the project type, settings or ANYTHING for most of them...you doing so (and normalizing the settings) just saved me a LOT of work! Will be interesting to actually run all the tests and see what might still be broken in M68k SDL! (And at same time all the stuff that ALREADY works!) The two (I believe) test apps that had CFM-68k as opposed to plain M68k that you found, aren't mistakes, but are the ones that use OpenGL. I had to build them CFM-68k so I could link with Mesa. I'd only gotten started on all that, and, of course, never got them working. Very important: Because those tests use OpenGL, you can't build them AT ALL using the plain M68k SDL. For the CFM-68k version of SDL (where they WOULD build), ALL the tests would need to be converted to CFM-68k! I don't care about the names of the test apps so ".68k" is perfectly fine. I agree, I sometimes think M68k "looks long"...so we could change ALL references if we wanted... ---- - I'm pretty sure with the kinds of fixes to work around headers (that we did for Carbon) we'll get SDLmain for CW5 pretty easily... - Again, for plain M68k, it will NOT be possible to build a "shared lib" or stub, because there are no shared libs without CFM-68k...so possibly those targets should just be removed. Which then, again comes back to...do we roll CFM-68k into our "main" cw6 SDL, or do we have a separate "experimental" CFM-68k only SDL project? (I'd normally say "roll them in", but it makes the project file more complicated...and thus fragile and confusing...) - I do suspect some issues coming up with StdCLib...you might see then when trying to build some of the add ons...but we'll cross that bridge when we get to it. Stuffing it fixed SOMETHING at some point... - The "Carbon Support" folder isn't even needed for CodeWarrior versions that already include it...which is CW6 and higher. For CW5, if there isn't a Carbon target, it is totally useful thus. If you aren't using it in CW5, you can just toss the entire thing. FYI It is technically possible to build Carbon apps with CW5, but you have to dance around a bunch...if you are interested in that we'll go over everything you have to do... ---- I sincerely hope fixing the access paths makes CodeWarrior stop "accidentally" finding the wrong loadso files...so original names works...but...I TRIED before and it just kept coming back. Don't be shocked if STILL happens, and you end up deciding my renaming them was a good idea! (Cross fingers it won't come back...) ---- FYI I added a couple update comments to the "Platinum Builds" topic in MG. I did a bunch of work with CW8 last night and put my results there, instead of here in the hopes a wider audience will see them (and spark interest? Maybe?). Also put a bit about the more recent SDL stuff I'd done with audio and joysticks, same reason.
Last Edit: March 02, 2025, 20:37 by lauland
Jatoba 256 MB Posts: 270 System 9 Newcomer!	Reply #49 on: March 03, 2025, 07:36 Quote from: lauland I sincerely hope fixing the access paths makes CodeWarrior stop "accidentally" finding the wrong loadso files...so original names works...but...I TRIED before and it just kept coming back. Don't be shocked if STILL happens, and you end up deciding my renaming them was a good idea! (Cross fingers it won't come back...) One way I suspect they have a "chance of coming back" is if we exported an MCP project file into XML, then reimported the XML into MCP. I didn't try it yet, admittedly, but also because I figured we deem the XML format unreliable for CodeWarrior in general based on everything we saw, and so will always stick with MCP. (Side-note: MCP files don't need the resource fork to still work and be shared! Egoboo originally lost its own, yet it still worked, so that's how I know.) Also, really glad to know CWp8 was helpful with more C support! Can't wait to see how CWds9 and CWds10 turn out next! (Sorry I couldn't get to test them for you yet, though!) As for everything else you raised, duly noted on all the points. Hopefully we get the chance to work them out over Hotline discussions again! One other thing I did yesterday was that I moved on ahead to GUIlib, with the intent of going to SDL_net next (since one SDL_net test app originally requires GUIlib), and worked on getting it built via MPW (Make file already present) and CW (no project file included at all). To keep it short, the summary is that there are no official build instructions for GUIlib building for any platform, but by slightly tweaking the Make file to seek SDL stuff (originally SDL 1.1.1, "devel" folder) in the correct paths, it went past half of the build process, but fails with some code errors found in its source code. I should double-check MrCpp was set instead of MrC (as well as double-check other things) since GUIlib, unlike ALL other libsdl.org SDL add-ons, is written not in C, but in C++ (some of its test apps are written in C, though). Halting that, I went on ahead and made a CWp6 project from scratch. I'm not sure if the output is right, and I haven't run any of the tests yet, but I was able to build a static lib out of it with not too much trouble (note: no source code modifications so far). Things, as always, got trickier trying to build a static lib via a separate target. I was able to do it eventually, using stubs for SDL and the various "Sprocket" libs, but only after I had revisited rebuilding a new SDL.STUB file by editing the SDL.mcp.exp file to include a few extra functions, and while that may allow me to build the GUIlib shared lib, it MAY, perhaps, not work. Or perhaps it may work. Have to build and run the test apps against it, at minimum, to hopefully have a chance at validating my shared (and static, for that matter) GUIlib output. My confidence is not very high on this one, but let's see. So, editing the existing MPW Make files is relatively simple, it turns out. At this point, when we look a bit at the code inside, it's rather self-explanatory: set a bunch of paths to variables, make new paths using variables to put inside other variables, say what stubs/libs you need to link with if outputting a shared lib, then build the object files and link via very few MPW commands. That's it, no magic, MPW intimadates all of us, but it's no beast, and the build tools are very "easy" and "straightforward" (ahem, as much as MPW can be). We can likewise tinker the MPW Make files for all the other add-ons like this, too. Main issue with the Make files, though, is that we need to decide on some "canonical" relative path for the add-ons to find SDL, and SDL's include files, then OpenGL etc.. It seems circa SDL 1.1.1, when SDL creator Sam Latinga still had a greater-than-zero interest on the Mac as an SDL target platform, SDL add-ons were assumed to be each contained in their own separate folders, and those folders would be put hierarchically on the same level as wherever "SDL-1.x.x-devel" would sit. In our case, that would be next to where "SDL-1.2-main" is sitting. Just a side note. Another side note is that now our SDL source code root also has a "rsrc" folder with the SDL resource in it, and a "lib" folder in it, just like an official "devel" folder would have. (We still have to put our CW-compiled SDL libs inside that "lib" folder though: right now, it only contains the MPW-compiled version of the libs, as MPW's Make file is configured to put them there by default. I suspect the SDL CW projects were quite possibly added by people other than Sam, and that Sam only did the MPW Make files.) Anchors aweigh! The SDL Mac ship has long sailed and is deep in the high seas!

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #50 on: March 03, 2025, 15:48 So, indeed, it looks like like CWsd9 and/or CWds10 DO fully support all the missing "language features". So I was able to compile both Berusky and FreeDroid Classic...but not link them. The last versions of CodeWarrior STILL are missing certain needed functions (ie not C/C++ the language itself, but the MSL libs). Notable is getopt() which is used to process command line options which FreeDroid Classic needs. (Which would never be needed on classic MacOS). So I'm looking into workarounds. SDL-Ball, weirdly, displays its title with CW8 and CWds9, but NOT CWds10...no idea why. But unfortunately, opendir() even in 9 and 10 still doesn't understand some of the simpler searches both SDL-Ball and Super Mario War need...so I'll be looking into writing a replacement...once I'm sure that's what is going on (pretty sure). For all this I haven't needed to build SDL or the add ons with newer CodeWarriors...I've just been using main and the libs as built with CW6. Since none of them RUN yet, this hasn't been an issue...but we may end up needing to build SDL and ALL the add ons with the newer compilers at some point...or not...we'll see... ---- Awesome that you're looking into GUIlib...don't give up! The add ons are tricky, and took a lot of work and trying things for me to get the others going... Creating Makefiles or CW projects for test apps for the add ons are the same as creating them for the games (or MvM). And instead of having to set them up from scratch each time, you can just copy them, so you don't need to remember which libs you need to include. They'll tend to be the same, as far as which stubs etc are needed. Yeah, MPW Makefiles tend to get a bad rap from many Mac programmers because they aren't gui based...they're just text files, so easy to deal with, and powerful in their own right. One reason they irritate me slightly is I'm so used to standard Unix/MacOS X Makefiles, and they're just different enough to trip me up completely (they aren't "really" Makefiles)...that and the bizarre characters you need to use for separators, etc. As far as canonical "paths" to the add ons...I always have mine at the same level as SDL(-devel) itself. Putting them in a separate folder might "look nice" but requires you to have those access paths, and would require ANYONE using our add-ons to do the same...having them all together with SDL just seems to make sense. All my games assume they are at the same level. FYI you can tweak the CW settings to make it build the libs (and resources) in different folders. I haven't done this, but have seen other projects do it (like Mesa). So it should be possible to get it to build the libs directly into a "libs" folder, by just putting that in the name. Making it build them a level UNDER the CW projects may be possible too.

	Pages: 1 2 3 [4]

© 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.