Notes on using CodeWarrior to port games, etc.



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


Author	Notes on using CodeWarrior to port games, etc. (Read 108617 times)
Jatoba 256 MB Posts: 270 System 9 Newcomer!	Reply #15 on: February 01, 2025, 17:47 Here's one more Mac porting note, useful in CodeWarrior and beyond: The OpenGL SDK has its header files appropriately placed in "{OpenGLsdkRoot}:Headers". I came across an issue which is that the program I was trying to get working was searching for "GL/glu.h", but we don't have that file there, and there's no "GL" folder! The neat thing Apple did with OpenGL SDK, though, is that since "/" is a permissible character in HFS and HFS+, to facilitate porting, they took files like "gl.h" and "glut.h", and just copied+pasted+renamed them to "GL/gl.h" and "GL/glut.h"! I compared checksums, they are 100% identical. However, while there is "glu.h" over there, "GL/glu.h" was nowhere to be found. Did they just forget to do this process for that file? So I just copied+pasted+renamed it to "GL/glu.h" and voila! The game that is an early teenhood favorite of mine, which just yesterday I realized is an SDL + OpenGL game since "version 2" from 2000/2001, is Egoboo. More precisely, Zippy-Project's version of Egoboo (HTTPS link, works with cryanc + Classilla). The brother of the author assembled a team, and they took version 1, which was Windows-only and Direct-3D-only, and converted it to SDL 1.x and OpenGL! With this, they released it not only on Windows, but also GNU/Linux. And nothing else -- although many years later an unrelated, different team circa 2008 ported it over to Mac OS X Tiger+ very sloppily, and I personally don't like most changes that the new team made, so I still go back to Zippy-Project's version to enjoy myself some Egoboo, alone or with friends, family etc., even if I need to boot into Windows for it. Thing is, to my surprise, and I totally had forgotten this, team Zippy-Project, without annoucing it ANYWHERE, EVER, had a hidden CWPro5 .mcp file included in their Windows and GNU/Linux sources!!! I was ready to create the whole thing from scratch, but those guys CLEARLY tried and got started on a REAL Mac OS port, rather than OS X. Now, spoiler is: the game doesn't actually work properly. Indeed, I was able to compile its version 2.22 (after fixing Access Paths for SDL and OpenGL, reincluding 3 OpenGL stub libs, SDL, SDLmain, and fixing the GL/glu.h issue I described above, then adding SDL.rsrc and, from Egoboo version 2.1, Egoboo.rsrc file, plus adding a blank resource fork via ResEdit to the broken Egoboo.rsrc file), and AM able to run the game, pick a starter character, load a game map, and... Then the following problems appear: - Textures are all missing, except for your character; - Every equipment / item / enemy / door / game object got replaced with an exact copy of your controlling character; - Clunky controls, can be very-well addressed...; Other than that, the engine technically "works"... The game runs at a whopping 300 FPS on my Mac mini G4 with OpenGL, and looks butter-smooth gorgeous on my CRT monitor that way, running at 75 Hz. Now, I will have to ACTUALLY get started with the "real" porting... That is, to dive into the code... and fix the things I see... @lauland I figured I'd try also helping here, since we all always have been relying on you to do 99.99% of all the work (and 100% of all the work with all those game ports you did and are still doing), so I'm challenging myself with trying to port Egoboo to Mac OS 9 (and System 7 for that matter!), and see if I can get somewhere. There are also technically another 2 issues with Egoboo: - The game seems to be only using up one quarter of my screen real estate, the bottom-left side to be exact. Perhaps it's hard-coded to run at a lower resolution, or perhaps I can change that in a configuration file. I should fiddle with the game's text-file-based settings more; - The game offers 2 kinds of maps: maps in which you create a new character with (by finishing their "starter" dungeon/map), which has all the bugs I explained above, and maps in which you use your EXISTING characters. The latter simply loads the map, but not your character, and the game says "press space to respawn", but you can't. It's as if no "object" data was loaded. It seems nothing but the "STARTER character data" loads, whereas any other "object" data is ignored, hence the symptoms. I will keep on trying things. Still, am very happy to see Egoboo 2.22 CAN run on Mac OS 9 technically! All thanks to our collective SDL/CW/etc. experience! (And the original team's secret Mac efforts!)

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #16 on: February 01, 2025, 18:22 Amazing job! Thrilled to see your efforts and proof I'm not the only one that can do this sort of thing! And both @Jatoba and I are just "mere mortals". Getting it to take up more of the screen will probably be "easy" (by some definitions of that word) and you probably WILL find it is just hard coded somewhere... The missing textures MIGHT be a limitation of MacOS 9 OpenGL, or possibly the video card you are using. That will be a lot harder to track down and start you down a rabbit hole of learning all about 3D and OpenGL specifically. It can be fun and a rewarding experience, but the rabbit hole is VERY deep... ---- At one point OpenGL itself was "moving slower" than innovations in 3D hardware and wasn't keeping up, so instead of adding functions to core OpenGL, "extensions" were used. There was a lot of infighting and some extensions came from one hardware or OS vendor and were specific just to them...other times there would be multiple extensions all doing the same thing, but different conflicting versions from different vendors. Microsoft wanted to push Windows, and ATI and Nvidia were in an epic struggle, etc etc. https://www.khronos.org/opengl/wiki/OpenGL_Extension (modern browser) ---- The point being that some OpenGL "extensions" which many games may use may or may not have Apple MacOS 9 implementations, which could be what you are running into. Egoboo might be using one that is missing. Sometimes there are workarounds, or if you are really clever you can write replacement code to at least draw "something" in the missing place, even if it wouldn't "look right". Anyway, that is a guess right off the top of my head. It could also very well be your video card doesn't have a feature it is trying to use. Again, you could get really clever, detect what features the user's card has, and work around anything not supported...but that's for the future... Or if it's not a "missing feature" some cards have limitations on texture size or they can only be square... ---- BTW the "GL/gl.h" thing you ran into is EXACTLY the same as the "SDL/SDL.h" thing we hit early on with MvM. The problem is if you turn on "Interpret DOS and Unix Paths" in CodeWarior, it stops working, because then you WILL need to move the headers into a "GL" folder. This is why very early in our SDL journey I was renaming "include" to "SDL". I've since changed my mind, especially since I found a lot of games just have "#include "SDL.h" and not "#include <SDL/SDL.h>" anyway. When you're doing a port, you'll more often than not end up changing the code in some little way anyway, so I've been changing the #include's to remove the directory name, instead, when I see them. It's really "six of one, half dozen of the other". ---- The maps issue might be the same sort of directory search or "/" in pathnames or other game data problems that are very typical with ports... Again...AMAZING JOB!
Last Edit: February 01, 2025, 18:29 by lauland
Jatoba 256 MB Posts: 270 System 9 Newcomer!	Reply #17 on: February 01, 2025, 18:50 @lauland I hope the texture for the maps not showing up won't be that much of a rabbit hole... reason being, the playable character's texture is rendered correctly. So tiles/walls should, hopefully, also be able to... About the resolution, it turned out to be an ultra easy fix: just had to open setup.txt, and use values for my resolution in the appropriate fields: [SCREENSIZE_X] : "1024" [SCREENSIZE_Y] : "768" The above being the resolution I use on my CRT. Being a game released in 2000, I'd assume/hope that OpenGL hasn't been around long enough for OpenGL Extensions to be an issue? Or, it is, and Egoboo on Mac is potentially screwed if so. But let's see, I feel hopeful about it somehow. So between the map texture, and the object data loading silent errors, the latter sounds easier to fix. I will try to focus on just that one first. Let's see if I can get results... I wonder how much time it will take for me.

cballero 1024 MB Posts: 1176 System 7, today and forever	Reply #18 on: February 01, 2025, 19:49 Nice one, Jatoba! let me help out you and Lauland's amazing exploits by supplying retro-browser-friendly IA links to a few modern urls you've both posted so far · Super Mario Wars fangame dev page · Super Mario Wars binary releases on Github · Zippy Project's version of Egoboo · OpenGl's extensions page All four links links tested and working in iCab!
Last Edit: February 04, 2025, 13:01 by cballero
Jatoba 256 MB Posts: 270 System 9 Newcomer!	Reply #19 on: February 01, 2025, 19:55 The map/scenario/module wall/floor textures come from mere .BMP files... Is that good news in some way? It seems as if the game just isn't loading them... such as failing to find the files, presumably due to path issues like often happens with Mac ports? The function that seems to be behind it seems to be in a massive C file, "graphic.c", function name "load_basic_textures" defined on line 687 of Egoboo 2.22. It seems to try to retrieve/load the files with a function called "FILENAME", e.g. FILENAME( "gamedat/tile0.bmp" ). I'm assuming it's not returning what it needs, so I will try printfs or other similar logging techniques (can I put a breakpoint there? Will CW actually hit it?), and see if I'm suspecting things correctly, or if I'm off. I will also try to find the definition of "FILENAME", it should be platform-agnostic, but might still be making file system assumptions.

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #20 on: February 02, 2025, 00:28 Extensions have been around as long as OpenGL has...but a little research shows the first Radeon (the 7000) came out in 2001. I can't remember if it or an Nvidia equivalent came out first, but it was definitely one of the very first that had "Shader" hardware, which required extensions to use, as the concepts (which I won't go into) were far beyond what OpenGL originally envisioned. Either way, I'm pretty sure those early shader extensions DID get MacOS 9 implementations...but aren't positive. BMP files are the easiest image files to read because they are uncompressed, so a reader...as long as you take the fact that the numbers are little endian into account...is trivial to write...SDL has one built in. It could just be something as simple as it not finding the texture files. What I'd do: hunt down where it actually loads the files. It might load them by hand, might use an SDL func, or might just use SDL_image's IMG_Load(). When you find whatever func it uses, the game code might not even check the return value, and just ASSUME it got the file (like "Abbaye"). Or, it might check and it's failing, but not writing any error anywhere useful you can see. You can add a printf or fprintf right there and it should go to SDL's stdout.txt or stderr.txt. I frequently fprintf to stderr, and then do fflush(stderr)...the reason being it forces it to write all pending output to the file, so you'll get it even if the game crashes. You'd want to do the same thing around the part where it would try and load alt maps. Be on the lookout for #include <dirent.h> and opendir() calls, which would be trying to find files in a folder. You might be running into the same problem as I am with Super Mario Wars. I can't think of a decent sane workaround for the broken CodeWarrior opendir(), so might end up writing a replacement. It'd look at the path passed, and maybe do the equiv of a chdir() each time it finds a subfolder, and then FINALLY run the real MSL opendir when it gets to the end of the nested path (and then undo the chdir's), so wouldn't be trivial to get right. SMW uses quite nested folders for its data, otherwise, I'd just flatten them all out...might end up doing that to save time anyway. Whatever the cause, just getting a game to find and read its own data files almost ALWAYS tuns up being something you need to deal with when porting. In fact, I'm pretty shocked in cases where it "just works" first try. ---- Such a dopamine rush when you're compiling and compiling and not even sure what you're doing is possible...and then...bam...the first game screen actually comes up! Maybe the colors aren't right, or something else is wrong, and the game doesn't fully play, but you took just a bunch of text files and now things are moving on your screen. A screen where they were never meant to be or just have never been seen before. Like a magic incantation, almost, or at least closest to one that actually works in the real world. Or cooking an extremely complicated meal for the first time... Or playing/acting on stage, etc etc etc.
Last Edit: February 02, 2025, 00:37 by lauland
Jatoba 256 MB Posts: 270 System 9 Newcomer!	Reply #21 on: February 02, 2025, 08:34 Just gonna leave some CodeWarrior notes: To debug CW apps: - You can't even put breakpoints unless, after opening your project, you click on the "Project" menu, and select "Enable Debugger". Whenever you open up a code file for editing now, there will be a small vertical bar added to the left, so now you can click on it to add breakpoints. This was required at least on CWPro5, but you may need to do this for other versions, as well; - Make sure you have the "MetroNub" system extensions added to your Extensions folder. It comes when you install CW, and to add it later, you have to install CW again... Also note that if you have more than one CPU, they suggest, during install, you pick the "MP" version of MetroNub, so use that for your e.g. MDD but not e.g. Mac mini. NOTE: The CWPro5 MetroNub, at least the "MP" version (but probably both), complains upon reboot that it cannot work on Mac OS 8.6 or later, so that might be a strong reason to prefer CWPro6 over CWPro5, despite Pro5 having a better and much nicer UI, and helpful folder icons; - After all is set and you got your breakpoints, click on the "Play" button (rather than "Make"). This should be enough. Also, watch out if you install multiple CW versions, as you may need to activate/deactivate and separate each MetroNub accordingly in your system. Of note, there's also the "(Debugger Extras)" folder, which doesn't contain much, but what's in there IS interesting. Read through the "About_MetroNub_Utilities" text file to see.
Last Edit: February 02, 2025, 08:42 by Jatoba
Jatoba 256 MB Posts: 270 System 9 Newcomer!	Reply #22 on: February 02, 2025, 10:12 EGOBOO MAP TEXTURES FIXED Sorry, couldn't contain myself. Actually, I have to fix the code itself, as I got the "fix" by changing (you guessed it) filepaths, straight in memory during debugging (double-click on variable name, change the value to your liking -- I didn't think I would be able to do this with debugging on C + CodeWarrior! This isn't THAT different, nor that much more limited, than what we very well do today with the likes of Visual Studio 2022 and C#!). What I did was to convert the project from CWPro5 to CWPro6, re-find one CW lib whose name/path was different in Pro6, reactivate my MetroNub extension (from some version later than what shipped with CWPro5, but maybe that also works for debugging in Pro5 in Mac OS 9.2.2?), then the debugger complained it wanted SDL_main.c (why? to debug the SDL_main lib and the true main method?), complained about "file date not matching" or something, OK-ed it, then it asked me for some other file or... so. I already forgot what the other file or method was. But what I know is that I just OK-ed all that too and just "told" the debugger/code to move on already so that my breakpoint would be hit. When it was loading the BMP files, it is odd... Because the filename (filepath actually) had values using "/" sometimes, and... I think those worked? Will double-check. But then at other times it was clearly using ":" as expected in HFS(+), so... what the hell. Anyway, I noticed there was CLEARLY an issue, however, when it added one ":" too many, like the result of some kind of string concatenation mistake (as opposed to intending to "navigate down" one directory level), so I fixed that in memory by hand. But that wasn't all! Then later on when loading a BUNCH of other BMP data, it had MIXED syntax of ":" and "/", so it was tryingto fetch BMP files with something like ":mymap:gamedat:someobject/objdata/tile0.bmp" or similar! So I just changed THOSE to use just ":". So, yeah, like you guessed @lauland, the texture issue was a bunch of "/" and ":" confusion that happens with most porting efforts to Mac, because the code being ported is not platform-agnostic, and did not take any other filesystems into account, certainly not HFS/HFS+. I would NOT be surprised IF, somehow, the "repeated objects" issue in which everything is replaced by the main character being played, is also somehow related to a path mess-up, but... maybe it's totally a different kind of issue since... why would pathname mess-ups cause... ONE object to load, instead of any other object? ... Maybe if it adds the objects to an array, and... then it fails, because the PATH to object data was wrong.... argh, let me stop guessing and just try to look at the code or debug. --- BY THE WAY... It was COMPLETE luck that I was able to put breakpoints in the right place: earlier I was talking about the "graphic.c" file, and I meant to debug THAT first, but... when I ported the project from CWPro5 to Pro6, suddenly I got TWO code errors about an implicit cast which was "illegal" (no idea why it was fine in Pro5, but not Pro6. Maybe a more lax compiler setting got lost in conversion?), the implicit cast being passing a "const char " to a function as a parameter that should be just "char " (why the f#! is it an issue to pass a const there since the type is the exact same?), so I just added a "(char *)" to the parameter being passed and voila, error gone. Thing is, I got this error EXACTLY where BMP files were ACTUALLY being loaded, for use with OpenGL, in a file called "GLTexture.c", lines 16 and 76. It turned out, completely by chance, that's EXACTLY where I needed to put my breakpoints to easily notice the filepath / texture issue!!! I didn't even need to look for it... Happy about the result, sad that I didn't get to "test" myself with trying to "search and find" things via debugging, but... I'll just accept what happened there very gladly. --- Now, I need to ACTUALLY fix the code, so things are loaded into memory correctly, without me needing to poke at a list of variables and variable states during debugging one by one...

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #23 on: February 03, 2025, 04:42 Finally figured out what was going on with "L'Abbaye des Morts", and pretty sure ALL of my previous guesses were wrong. By jumping into Macsbug after it crashes (Command-F12 in MacOS X, very useful!) I could see it was hung somewhere in the sound playing code deep inside SDL_mixer. Commenting out all "music" playing code in the main loop and the game runs perfectly...but without background music. Strangely, sound effects are handled differently, and still work. This likely means most of the guesses and "fixes" for array passing were all blind alleys. I'm going to revert to the original code to back out my goofy "fixes" and find out... So there may be a bug somewhere in SDL_mixer...or, maybe "Abbaye" is doing something weird with the way it plays SOME sounds. Basic sound obviously works, and there no problem with the background music in the intro screens...could be that particular WAV file? Or doing it asynchronously? Who knows. I've half a mind to put it up on MG as is, and just fix it later...other than missing background music, being very primitive (on purpose), you're not missing much, and it is fully playable. ---- So...now that it runs...is the game actually fun to play? Maybe. Depends on your taste. It is very much like many "Spectrum games" being a loving homage to them. The Sinclair ZX Spectrum was quite a limited (some would say even for those days) ancient computer, EXTREMELY popular in Europe for those unfamiliar. (I'm not throwing shade on it, I 'm well aware how beloved it is.) If you've played any "Jetset" or "Dizzy" games or others of that ilk, you'll feel right at home with "Abbaye". If you loved them, you'll probably like this one...but...if you hated them and/or was driven up the wall by them...well...this is NOT for you. (Personally, I had a love/hate relationship with them). You walk left and right, can duck and jump and that's mostly it! It forces you to do countless tricky jumps, sometimes having to time them JUST RIGHT to avoid enemies that move in fixed patterns partially blocking your way. There's no "save game" function, so you can get quite far and get sent back to some checkpoint way way several screens ago (thank god it has those)...having to then repeat all those tricky jumps again because you missed one by pixels... I'm seriously thinking of putting in some "cheat codes" where you could warp to a particular screen. If I wanted to preserve my sanity and actually test the thing thoroughly enough, that would be a very good idea...
Last Edit: February 03, 2025, 05:36 by lauland
Jatoba 256 MB Posts: 270 System 9 Newcomer!	Reply #24 on: February 03, 2025, 07:25 @lauland Awesome! So Abbaye has reached a playable state! (Btw, I'm sure the music will help with dealing with the "difficulty" of the game.) Perhaps as a means of "backup", you could put up the current playable, music-less version in the Garden, and then replace it if you figure out the sound issue? Although it sounds like you are already VERY close to figuring it out. Also, MacsBug, on OS X? And invokeable via Cmd+F12? Wow. I had no idea. So you're using CWPro7 on OS X for it? --- On my end of things, I noticed later MetroNub versions also work with CWPro5, so it turns out I can still use it to debug in Mac OS 9.2.2 that way! Pretty neat. CWPro5 also doesn't complain about the date of my SDL_main.c file, which saves me a click each debugging attempt. Still, gonna stick with Pro 6 now as it is our "standard" that can still target 68k, but is also as up-to-date as possible (might mean better CPU optimizations, better optional AltiVec use etc.?). --- I also fixed Egoboo's textures in code now. I also spent the whole of Sunday debugging and trying to fix the "object loading" issue, which is the only known issue "Macoboo" is facing right now. It's odd, because in memory, everything looks like it is getting loaded fine, and there are lots of error checks throughout the code, but the running code is passing all checks, too... Been stepping over and into all method calls, going line-by-line etc., but... it all just... looks as if all objects SHOULD have loaded? For the record, the game uses Quake 2 "MD2" files for its models. Not sure if knowing this is useful or not. And it IS loading one such model/object correctly, which is the playable character... Except the playable character is all that is getting loaded rather than all the other objects, so e.g. rather than wielding a sword, a character will be wielding another character! And be actually able to swing that! And kill with that! Kinda hilarious... So, those MD2 files are apparently, by design, little endian, and that just sucks. But from what is clear in code, and changelogs, someone in the team in 2001 taking care of the Mac port also took care of all endian-ness issues. (I think we also notice that when comparing version 2.22 with 2.1: when I compiled the latter, the game would run "redder", as in, things looked more red, like fonts, and it isn't supposed to be like that at all.) So I'm lucky that I don't have to deal with endian-ness problems, as we often would have to with Macports (the OS X Macports shall be internally renamed as Xports to me now, WE are the Macports! ). I'm glad someone at that very GNU/Linux-centric Egoboo team cared for the Mac, and got MOST of the difficult, grunt work figured out, with big/little endian #ifdefs, byteswapped functions and everything! So I will see if I can finish it. Anyway... in my attempts to fix the object loading issue, and changing any troublesome "/" into ":", one other thing was fixed: the random character name generator. When you start a game to create a new character, a semi-random name (based on the character class) gets generated for your character. Apparently, I was only getting the first name of the names list (issue sounds familiar?), but after all these path-related fixes (especially fixes so that "::" would not occur), now the names ARE getting generated properly! Otherwise, when you create an "Adventurer" class character by playing the "Adventurer Start" module, he would always be named "Blah". In any case... Egoboo or, perhaps, "Macoboo" is progressing. Will try to continue fixing it if I can.
Last Edit: February 03, 2025, 07:30 by Jatoba
lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #25 on: February 03, 2025, 18:16 Uploaded work-in-progress to: http://macintoshgarden.org/games/labbaye-des-morts It plays too slowly in the original 640x480 on my ibook g4, so I also included a version that runs at 320x240 which is fast enough. Disabled background music during game play due to before mentioned bug. Used CW7 for PPC build, so MacOS 9 only for now. Going to try building in CW6, and also try 68k version but it is likely to be VERY slow. Unsure why it is slower than expected. But even though the "spectrum" style artwork LOOKS extremely primitive, it is still using 32 bit pixels for everything. The drawing code may be inefficient.

cballero 1024 MB Posts: 1176 System 7, today and forever	Reply #26 on: February 04, 2025, 13:23 All I can say is awesome job!! I'm playing it in SheepShaver on a '09 Xeon Mac with High Sierra and it's playing perfectly!

Jatoba 256 MB Posts: 270 System 9 Newcomer!	Reply #27 on: February 04, 2025, 19:12 Egoboo update: 1. I think I got all the "::" and both Windows and GNU/Linux path styles squashed from the Mac version's filepaths, very programmatically. Found it very annoying how one of them was coming from a TEXT FILE, which was loaded into memory, then READ, and the reading being saved to a local variable... Of course, the text file wasn't even part of the CW project! Drove me nuts. But that cr4p has been sent to oblivion and is fixed now, for what it's worth... 2. The object loading issue I was trying to originally fix all along, although is still not fixed, I believe I found the cause: unimplemented I/O functions for a Mac-specific C file, responsible for saving/storing temporarily a bunch of MD2 object files in the filesystem which, eventually, the game also deletes (deleting is also unimplemented). But unless they are created into the filesystem, the game can't load them into the actual game round when you load a map AKA module. I'm not 100% sure that THIS is the reason I don't get other objects besides the starter character (who is also replacing all other objects), but I'm pretty darn sure this is why. There is also 1 Win-specific file and 1 GNU/Lin-specific file, which implements those functions. The Mac-specific file DECLARES the functions, but leaves them blank, unimplemented. So the solution is for me to do some Mac file I/O in C, which I have no experience with whatsoever, but I'm not afraid to do it, I know it's no magic nor a big ordeal (I hope). BUT, maybe I should backup my system first just in case I mess it up and start overwriting all my Mac files and corrupt my filesystem and lose all data? Hopefully my understanding is right, and hopefully that will also mean Mac Egoboo is close to being truly a thing. But... Let me make some HFS+ BD-R backups of my stuff first, just in case it all ends up in a burner.
Last Edit: February 04, 2025, 19:15 by Jatoba
lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #28 on: February 05, 2025, 03:09 Wh00t wh00t! Closer and closer... 1. Yeah, the paths thing is a pain and almost all of the games so far have given me at least a LITTLE trouble with that. If the filenames are hardcoded it's as easy as finding them and just fixing them. A lot of times games want to put things in "/usr/share" or places like that and you have to take care of it. I had a devil of a time with SDL Scavenger wanting to create a ".scav" (or whatever) folder in the "home directory" and copy all its data and run from there. Never got it QUITE right, but forced it to use code similar to what it does on Windows with a "scav" folder where the app is located, so close enough, etc etc etc. 2. I have faith in you! Does sound like a bit of a bother, and writing new code, but nothing major...hopefully! That may just be the final key piece to the puzzle. Amazing sleuthing work so far...very impressive! ---- Forgot about all the debug printfs I still had in "Abbaye" so it was printing a TON of things to "stderr.txt" WHILE the game plays. Going to remove them and then it might run well on my ibook! (At least it'll HAVE to be better). Looked at the main game event loop and didn't see it not freeing anything it should, so will be hunting down memory leaks in the countless functions it calls. Built an m68k version, which required me to get SDL_ttf building in CW6...first PPC and then m68k...so that is done now too. But when the game starts it immediately tries to open audio and won't run without it (which is disabled due to crashing on m68k). So going to be looking at whatever is wrong with m68k audio...and might find the problem with Abbaye crashing playing background music to boot, if I'm lucky... ---- http://macintoshgarden.org/forum/custom-software-builds-os-x-leopard-32bit I've been lurking on thedoctor45's Leopard Ports discord channels and reading all the amazing things those guys have done. You wouldn't believe the amount of games that ScummVM can run having NOTHING to do with LucasArts. It looks like it is evolving into a general "games using bytecode engines" solution so they've been able to port some wonderful things to MacOS X that way. Definitely a modern MacOS 9 version would open up vast vistas. I downloaded the ScummVM source and took a glance and the latest version is pretty huge and intimidating. Anyway definitely a future project to at least try. They also, very cooly, have a huge collection of source code collecting their work on the ports. We can, of course, grab things from there to try "MacOS 9 Ports" or whatever we might call them. The ones they've done for PPC will especially be useful because they will have already fixed any endian problems. The ones for Intel MacOS X less useful than you may think, since first just getting PPC and THEN CodeWarrior will still be a LOT of work...but it is a very library of possibilities...I'm sure there are some excellent candidates in there that use SDL 1.2. But, regardless, there could also be some synergy with their efforts/group reflecting on ours.
Last Edit: February 05, 2025, 03:11 by lauland
Bolkonskij Administrator 1024 MB Posts: 2023	Reply #29 on: February 05, 2025, 13:52 Quote from: lauland You wouldn't believe the amount of games that ScummVM can run having NOTHING to do with LucasArts. It looks like it is evolving into a general "games using bytecode engines" solution so they've been able to port some wonderful things to MacOS X that way. Definitely a modern MacOS 9 version would open up vast vistas. YES! I think I mentioned it in the other thread, it's evolving really nicely and would open up an interesting path for Mac OS 9. However, given the broader approach, code sure got more complicated with time. Maybe it would be an idea to look for an older candidate to port first, in that it'll be less confusing? Once you figure things out, porting a more recent version might become more realistic. EDIT: Just remembered that there actually WAS a Mac OS 9 version of ScummVM. A very early v0.20. I had uploaded it to the Mac Garden many years ago. I wonder if that's a possible entry point with ScummVM in that you rather "backport" functionality from later updates instead of trying to do a 1:1 port. The v0.20 might give you the stable base for that. (project file / sources are included in the Garden download, have a look if you find it interesting)
Last Edit: February 05, 2025, 13:58 by Bolkonskij
	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.