|
|
|
|
| Welcome, Guest | Home | Search | Login | Register | |
| Author | Notes on using CodeWarrior to port games, etc. (Read 108616 times) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Jatoba
256 MB  Posts: 270 System 9 Newcomer! 
|
Reply #30 on: February 06, 2025, 17:39
Still backing up my Mac Things (tm) before adding/testing I/O code in Egoboo, but in that time I found this: http://macintoshgarden.org/games/cave-story-doukutsu-monogatari Cave Story, I believe, needs no introduction. But what needs introduction is that an engine to run it, called NXEngine, can use its files and play the game normally. That is, if you use a fork by a guy called "BLX", who fixed a bunch of stuff in NXEngine and made it awesome in a way its original author always wanted it to be! I wrote a comment in that page so that anyone can get access to the source and all, but the important thing here is: It is based entirely on SDL 1.2 + SDL_mixer + SDL_ttf. It is BEGGING for a Mac OS 9 ~ System 7 port! After I'm done with Egoboo, I'd love to look at this! It's in C++, though, which confuses me quite a bit, but... Will gladly learn it via trial & error if need be. They ported it to ALL kinds of crazy platforms! I'm hoping the "hardest part" will be just setting up a simple CW project file. EDIT: Typo fix. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Last Edit: February 08, 2025, 17:05 by Jatoba
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #31 on: February 16, 2025, 04:54
|
So status of various games I'm working on, all currently with CodeWarrior 7 pro...in no particular order: Super Mario War and SDL-Ball both fully build, but when they run they are unable to find their data files due to CodeWarrior's opendir() not handling subdirs, or even paths with path chars in them (":", "/", or "\"). Berusky mostly builds except for one file which has over 70 very large "designated initializers", which would be a MAJOR pain to fix. But it also uses quite a few functions missing from CodeWarrior's standard C library...among them: fork(), waitpid(), fnmatch(), alphasort(), mktemp() and scandir(). All of those will vary in how hard they are to replace or workaround. FreedroidClassic also is full of "designated initializers", but smaller and more scattered, so would be easier to fix by hand. It also has many places where it declares arrays using "calculated sizes" ie not constants or simple single variables. I think these could be replaced by malloc's or something like that, which I've had to do for other games. lbreakout has extensive network code, and a client/server architecture. It isn't very clear which parts are needed for just the client, or how to build it without network support, but I'm looking into it. It might be possible to build with net support as it uses SDL_net...if I ever get THAT to work. ---- New work on previously done ports... Have been able to build Snoopy and the Red Baron for m68k with sound (using the old "non-RYAN" driver). Testing to make sure it is stable, but will likely release to MG soon. SDL Scavenger seems to work very well with joystick/gamepad support...will release that version to MG. Still haven't figured out why the m68k version spontaneously quits. SDLRoids also works with joysticks...but the game starts at maximum thrust thinking the stick is held to the upper left...not sure if this is a bug in SDL itself, Input Sprockets, or SDLRoids. Might as well release it anyway, with a warning about it. Will probably be able to get sound working in the m68k version, but may also have broken it, as it quits immediately even with sound disabled now...sigh... Abbaye des Morts background music still crashing...but believe I may be figuring it out...it is likely trying to stream ie playing while reading from disk. This leads to it trying to call C file io functions from deep within the audio callback, since this is done at MacOS interrupt level, it is likely causing the crashes. The CodeWarrior file io functions are probably not "reentrant" ie interrupt safe. If I can get it to full load the .wav files before playing, instead of trying to stream them remains to be seen... ---- Then there's also trying CodeWarrior 8, and MetroWerks "Dev Studio" versions 9 and 10, to see if they support more modern language features like "designated initializers" etc...
Last Edit: February 16, 2025, 04:59 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #32 on: February 16, 2025, 05:31
|
Quote from: lauland Will probably be able to get sound working in the m68k version, but may also have broken it, as it quits immediately even with sound disabled now...sigh... Can relate... Best thing to do is to develop a habit of doing a backup every time right before working on a project. I'm saying this because yesterday I resumed working on Egoboo and, while I fixed a bunch of things, SOMEHOW I also broke at least registration of pressing the Cmd key, which is used in Egoboo alongside a click to turn around the camera. Later on I also tried to replace Lf with Cr across thousands of text files, but accidentally got some non-text files caught up (even though "text files only" or some other similarly-named setting was checked) via BBEdit, and it saves straight to disk, so I screwed up all source code and most binary files. Had to throw the whole thing away, and I was thinking how I should haved SIT-ed the whole thing first before trying. Fortunately, by pure chance rather than merit, BECAUSE I was so neurotic about backing up my mini this past week, that also backed up Egoboo up until now, so upon realizing that, I was able to undo ALL of the above... But if it hadn't been for that... I'd have had to restart and redo all my work on Egoboo from scratch... I will definitely do quick .SIT backups a lot more often from now on... AND store these backups with a date + time stamp, and shove them in a folder. -------- On another note, I finally implemented some Mac I/O on Egoboo (lazily throwing Windows code at an AI generator a LOT, and telling it to give me FSSpec-y stuff instead, which it kinda did OK and kinda failed to all over the place, and so manually had to fix a bunch of stuff). I don't trust the new I/O code is working, but I didn't quite get to test it much in the first place, because in the end, while that code has to be eventually written, it turned out it is NOT related to the main Egoboo issue of the same playable character being loaded instead of the various other objects (chests, doors, torches, enemies, weapons, items etc.). So then I went back into massive bughunt modes via the debugger, went through all the loaded routines... bla bla bla... Hours later, again it is as if everything is loaded correctly, and supposed to be rendered accordingly, but... It just isn't. This has be me completely stumped. Eventually I noticed there were some sneaky ".bat" files (yes, Windows batch files) that were inside each folder for each of the objects belonging to a module, and I instantly went "m*th3rfkr!", but it turned out, those were also there in the GNU/Linux version of the source code. I don't think they are being used nor invoked at all by the source code, based on the debugging I did... Seems like an old leftover. I also noticed all text files are Lf-formatted, rather than the Windows CrLf, or the Mac Cr. But this is true for both the Windows and GNU/Linux versions, and the Lf-separated values in configuration text files all seem to be read... correctly, I think? I can double-check, but... I believe they all are loaded and read correctly... So... yeah. Damn. Porting Egoboo is hard for me. Will keep on trying, though.
|
wove
|
1024 MB Posts: 1363
Reply #33 on: February 16, 2025, 17:34
|
Quote from: Jatoba [Fortunately, by pure chance rather than merit, BECAUSE I was so neurotic about backing up my mini this past week I think TimeMachine is one the finest things that Apple has developed. I have my machines just set to automatically backup. I have used the backups to move to new hardware, both all new machines but mostly just to move to a bigger hard drives. The biggest use I get though comes from recovering from memory lapses where I have either forgotten to to save and then the system crashes, or when I foolishly or mistakenly delete something I should have kept. I imagine that making, organizing, and keeping backups is rather important and useful in development work, or any work that involves carefully stepping through a minefield of incremental steps.
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #34 on: February 16, 2025, 18:15
|
Yeah, @Jatoba had been taking quite a bit of time perfecting his backups...I was just about to tell him maybe they were "good enough"...but then this! So, no, keep up the backups, as "perfect" as you can get them! I work on multiple machines so have a kind of built in backup, but not in an organized logical kind of way. And obviously when I lost the SDL2 code I'd been working on, it is not "good enough". But now, uploading to MG is also a backup...so the m68k version of SDLRoids that is up there has no sound, but doesn't spontaneously quit...so I can just compare it with my "current" source folder. I'm pretty sure it is actually not code, but CodeWarrior project settings related to "enums always int" which turned out to be the fix for the keysym->unicode/sym bug. I need to make sure my m68k SDLRoids and all its dependencies have the exact same language and processor settings.... I've never actually used Time Machine because I didn't trust anything I couldn't see how it was working...and there was just way too much flash and "magic" involved...but that's just excuses. ---- CodeWarrior in general doesn't care about cr/lf's, and will deal with unix or mac or windows format with no problems. This isn't true with the very early versions, but CodeWarrior 6 pro definitely does. I wouldn't bother worrying about them any, and, as you can see, difficulties can arise from trying something like changing them globally. CodeWarrior itself can change cr/lf's for a file...it's at the top of a file edit window it's the 4th icon that looks like a little document. Just use that to be safe and resave the file. ---- If you truly feel like you are stuck, I can take a look at Egoboo...and in turn, if you like, you could take a look at the games I have in the pipe. If you already have CodeWarrior 8 pro (or 9 or 10) installed, it'd save me a lot of time, if you tried building them with it, to see if they support newer language features. I can upload everything to s7t's hotline as .sit's with dates on them. When I'm back on my ibook later, I'll go ahead and do that anyway... The .bat files definitely won't be used on Linux, but some games might have .sh equivalents that ARE in part of the build process. So far I haven't run into any in the ones I've been looking at, but I can imagine something like a shell script that might modify the source in some way in some project at some point. It'd be a sloppy way to do things, but, as you've seen, build processes can be arcane...just look at MvM!!!
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #35 on: February 17, 2025, 08:07
|
@wove Does it create a backup of a file every single time the file is changed, or does it follow a schedule? If the former, that's great, but if the latter, my files would have been lost. Somewhat like @lauland, though, I don't like "unsolicited extras", such as Spotlight and Time Machine, and also do like it better when I can "see" past the magic, as I also cannot trust it fully. But even if I could, I don't think Time Machine is good enough for us to do away with the practice of occasional, manually-made, solid backups anyway. (Single-layer non-LTH BD-R discs + some redundancy via copies in remote locations.) I do agree Time Machine should be able to help, though. As in, you can combine it with such manual backups that I speak of, rather than use only one option or the other. But I cannot rely on it alone. There is also another concern, though: both Spotlight and Time Machine are highly suspected for causing unrecoverable or hard-to-recover BTree errors in Mac OS, which means it can have the opposite effect, and that's very bad, for Mac OS users (versus OS X users). Although years ago I used to use OS X on the mini alongside Mac OS 9.2.2, and I never even once encountered such errors, but then again, that might have been because I wasn't really using Time Machine, nor much of Spotlight. Perhaps the issue is simply that both of these tools keep writing to your disk all the time, thus increasing the frequency of disk errors over time (and also shorten SSD life, or increase chance of needle getting stuck in an HDD). And/Or, there's something inherently incompatible about what they do that can damage Mac OS. But I don't know much about that, as I never encountered such an infamous BTree error. ---- @lauland "Trading cards" with our projects sounds interesting, and like a good idea (hope you don't mind my "dirty laundry" with ugly code hacks!). Yeah, I have CodeWarrior Pro 8.3 available with me anytime, and even the OS X DLSD has Dev Studio 10 IIRC (and if it doesn't, I will install it anyway, but I think it's already there), so I'd be glad to try compiling your ongoing projects with them to see if we at least get the extra, wanted language features. Might facilitate and speed up development and porting efforts in general, since we first get things working SOMEWHERE, then, if we choose to, do a "68k conversion" by moving things to CWPro6 and its known-but-somewhat-limited language features. Incidentally, since my mini had 7 partitions for years, 5 of which were almost unused, and certainly not required, I finally went and also took the opportunity to do a full reformat of it. Files are being copied as I type this, and should be ready "just like before" (but better) within 24 hours. (Some 1,000,000 files, I think?) Offtopic, but I thought I would mention, rather than using Drive Setup 2.1 (or OS X's Disk Utility), for the first time ever I used LaCie Silverlining Pro 6.5.8, which is a much newer tool, from as late as December 2006. Allows you to format and partition drives very comfortably from Mac OS 9, even big ones going into 1 TB and beyond, but what I really like about it is that I can choose a different block / cluster size than the default for HFS+. Can Disk Utility, or the CLI diskutil, do this? Drive Setup can't. I chose the maximum of 64kb, for fastest read/write. Works all fine so far. For the "purist" though, it can be "annoying" at first that we see a small "info text box" on the bottom-right corner when the Happy Mac icon shows during startup, AND the icon for the formatted partitions is some pre-Platinum, flat, LaCie-provided icon. You can replace it with a custom icon, but then the "original" icon will always reveal itself if you try deleting the custom one. Since I'm choosing function over aesthetic, I moved on. (But it took me some time, I will admit!)
|
wove
|
1024 MB Posts: 1363
Reply #36 on: February 17, 2025, 13:49
|
Quote from: Jatoba Does it create a backup of a file every single time the file is changed, or does it follow a schedule? Time Machine can be set to backup automatically hourly, daily or weekly. You do always have the option to select "Backup Now". Backups as you note are really about redundancy and one really does need to sort out methods to ensure you have a working strategy that will fit conveniently into your own workflow. I used NextCloud for a long time. It is not specifically for backup, but it could be setup so it would mirror files or folders on the local drive. Again it was something of a mystery in operation in that the user is not specifically informed as to when or how often the sync would happen. Both TimeMachine and NextCloud seem to run at a low priority on the network so if someone on the network is streaming a movie or downloading an iso, that activity will take priority over the NextCloud/Time Machine operation.
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #37 on: February 20, 2025, 04:38
|
Jatoba, I've uploaded my in-progress game build folders (with dates) to the s7t hotline, so any you want to try with CodeWarrior versions above 7, have at them...I'm on MacOS X right now, and it looks like a couple of the names got truncated, but they should all be clear which files are mine. I've included my current SDL and add on build folders also, as they were all built with CW7 and are what I'm using. (Newer than what is up at MG, but probably just joystick, audio, and m68k stuff). The GUSI that is there is needed for SDL_net, which is still unworking. That GUSI is probably broken or a hack I made specifically for Goliath/Jabbernaut, so don't use it other than to build SDL_net, or replace any other versions you might have. It's pretty likely if you want to try building any of the games with CW8/9/10 that you'll have to ALSO build/convert SDL and the needed add-ons to those versions too. Since I built them using CW7, they are using that version's MSL, and I expect will not mix well with newer CodeWarriors. So you'll be covering brave new ground there! (And likely run into problems, sorry!) Once I install CodeWarrior 8/9/10 I'll be able to help. FYI "hurrican" is really new and I've only just started looking at it. I haven't done any work other than setting up the project file, but am including it for completeness. "lbreakout" is on another machine than I'm currently using, so isn't there as I write this, but I'll get it up there in a bit, so should be there too when you look...also haven't done much of any work on it.
Last Edit: February 20, 2025, 04:52 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #38 on: February 25, 2025, 08:05
|
Quote from: lauland Jatoba, I've uploaded my in-progress game build folders (with dates) [...] @lauland I'm having a go with all your SDL-related work later today, although I just noticed SDL_image isn't there in the Hotline server. I assume it also went through changes like all the other libs ever since the latest MG upload, right? I will also try to sort out my Egoboo files so you can also take a peek or compile it if you'd like, and see what got me stuck there, too. I will also upload that later today, if the day proceeds "normally". Here's what I plan to do with your current work: - Make sure the CW projects for SDL 1.2.16+ (that's what I will call your enhanced SDL 1.2.16, I think it's fitting) can also compile a shared lib (at least for PPC), and make sure the Carbon targets at least will not reference wrong files which get in the way of all targets (by fixing paths etc.) - Make sure SDL 1.2.16+ is ready-to-go for MPW compilations, just like I did with SDL 1.2.16 - Fix version number from 1.2.13 to 1.2.16. CW and MPW look at different locations for that (it's actually the same file, but existing in 2 different locations) - Make sure MPW is a valid option for compiling all of your SDL add-ons - Diff your hacked GUSI 2.2.3 with the stock GUSI 2.2.3 and talk about it here (GUSI 2.2.3 is the latest version, incidentally) - Perhaps experiment your SDL_net with the stock GUSI and see if the test programs do any better than before - Try to compile your SDL games that were giving you array/struct initialization issues with CW Pro 8.3, CW DevStudio 9 and CW DevStudio 10, and report back on the findings (on that note, I suspect there will also be more Standard C Library functions implemented in those versions of CW, as well, which you previously had to deal with / circumvent for CWPro6, but let's see) Admittedly it will take more than 1 day to do all this, but it starts today. We are back! (Oh yes, aliases and other issues are essentially over and dealt with. Yay!) After all this is done, next up in line is: SDL Color vMac how-to publication to MG (text is ready), SDL 2 assistance, Retro68 + CMake + Docker on x86 GNU/Linux rig (an OS which I still have to at least install), Color QuickDraw vMac. Working on Bochs, Mac OS 9 Sheepshaver/Basilisk, my vMac helper tool and my own Mac+GB game can come after those.
Last Edit: February 25, 2025, 10:22 by Jatoba
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #39 on: February 25, 2025, 15:51
|
I knew you were up to good things from your comments on the codewarrior pages at MG! You hadn't posted here, but I knew you were working on a bunch of stuff! Dang, sorry I missed SDL_image! I had so many files, and must've overlooked it. I'm going to update all my addons on the MG page ASAP so you'll be able to get it there. Regardless, any changes/fixes I think were minor, and probably only m68k, so whatever you already have is probably good enough. (Off the top of my head: I found png decoding was crashing on m68k, so disable it for building for that cpu). My other work has been joysticks and audio, so updating the versions at MG would be good all around. And uploading new builds of the games that support joysticks (SDLRoids and Scavenger). I'll do that soon. It'll be a lot of fun for me to take a look at Egoboo. I haven't done much OpenGL lately, so taking a look at textures, etc will be really interesting. - I think SDL 1.2.16+ is a great name, and certainly better than "unstable", as it has proven itself to be pretty stable! Definitely need to pay more attention to the shared lib version. And I have been meaning to look at Carbon and make sure my changes didn't break it etc. - Yeah, I hate to admit I haven't touched MPW for a while, it'd be good to make sure it is all still working. - Yeah, 1.2.16! That's what it is, and that's what it should say. I'll need to get your changes into my versions. - I'm pretty sure at least one problem is I was using the GUSI for cw6 with cw7. There are different versions because they replace, override, or enhance some MSL functions, so it wouldn't be a surprise if the cw6 one just doesn't work with cw7. I built Goliath and Jabbernaut all on cw6, and the GUSI I've been using was the one I used for them. Just using the right version may make SDL_net work. - Yeah, each CodeWarrior version implemented more standard C things, had more standard include files, etc, and so newer versions have GOT to be better than older ones, at least in that way! Let me know what you find, and I can install cw8/9/10 also. Good to hear you have your system the way you want it now, all backed up and alaises singing and dancing! Take your time, and let me know what you might like me to look at in parallel. I need to return to SDL2, and at least reproduce what I had before. The bare minimum is cleaning it up and adding OpenGL stubs back in. I'll post here when/if I do that. Building Retro68 takes a pretty recent version of Linux, and so use the best hardware you have. You CAN do it all in a VM, which I did on both my Apple Silicon and Intel MBP's, but it is NOT fast. Let me know when/if you get around to this and I can help you with any Linux problems you run into. (Or even get you a copy of the VMs I already have). Those other projects sound pretty cool too: Bochs, MacOS 9 Basilisk and SheepShaver, and whatever Mac/GB game you're thinking of, etc etc. We might (probably) end up work together on all of those!
Last Edit: February 25, 2025, 15:54 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #40 on: February 26, 2025, 09:49
|
Hey @lauland, I just happened to come across and notice something relating to SDL 1.2 and audio support regarding 68k processors: http://revontulet.org/2025/02/26/8061322a20284c38ae02d3d0bcbdbfda.png Nevermind the fact the screenshot is showing a diff between stock 1.2.13 and stock 1.2.15: did you notice those two files before in the SDL source? Notice that this is the source for the core SDL 1.2 lib, not SDL_mixer, despite the confusing file names. 68k was never supported on Mac OS officially, yet these two "SDL_mixer_m68k" files are there, full with inline 68k assembly, perhaps for GNU/Linux 68k, BSD 68k, Atari ST 68k, and/or as some hangover from the removed Amiga 68k. I assume you probably noticed these two files before, but just in case if not, I thought I'd make a mention of them, if by any chance it helps with figuring out Mac SDL 68k woes, especially pertaining to audio. Not sure if it is relevant or not, but that 68k file went through only a single change, with a single added line, in the jump from 1.2.15 to the latest 1.2.16: https://github.com/libsdl-org/SDL-1.2/commit/f666cbbbafb12bcba21a7bbff11812534c299bd5 ---- As we discussed in Hotline previously, my Mac Egoboo source and the original Win Egoboo source (for reference) have been SIT-ed and put up on Hotline in a single archive file. Now I will see if I make some time for the SDL work I mentioned as soon as I can.
Last Edit: February 26, 2025, 10:16 by Jatoba
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #41 on: February 26, 2025, 15:17
|
No...I did NOT notice SDL_mixer_68k.*!!! Since my m68k version was based on the PPC version, it used a CW project file that doesn't include those files. Well dang! I, of course, will be looking at them with great interest ASAP! That one added instruction is a "sign extension", ie it takes a byte and extends it to a 16 bit "word". So probably fixed a bug. It will be interesting to take a look and see if the SDL that Amiga Devilutionx uses them... ---- As you've seen, SDL itself already has a "mixer" in it, and can load .WAV audio files. The SDL_mixer add-on greatly expands the mixer, and adds many other audio format, so it acts a little like a plugin, instead of completely separate from SDL itself. Those files probably add optimized m68k code to "mix" the audio channels, convert formats or something like that. I have basic m68k audio working, using the "non-RYAN" driver, but these will definitely add SOMETHING! (They may make the "new RYAN" driver work and not crash...) SDL_image does the same thing, as SDL itself out of the box can load .BMP files, etc. So SDL_image adds all the other formats with functions that work the same way as the built in support. ---- Taking a look at Egoboo now...finally...didn't get a chance last night.
Last Edit: February 26, 2025, 15:22 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #42 on: February 28, 2025, 10:17
|
@lauland I think I got the SDL CWp6 project setup to build its 3 Carbon targets correctly and in a portable manner, by using relative paths (instead of junk absolute paths found in the official SDL team's access paths configuration for these targets, clearly by mistake), and by also getting the sought-for "Carbon Support" folder, taken from the Carbon 1.6 SDK for Mac OS. Now I will have to trim that Carbon Support folder to only what is necessary, as the whole thing alone is 60-ish MB, which is I think a no-no, probably a lot of unneeded files are in the folder (but we will see). Also removed those wrong BeOS paths for all affected targets. PPC shared lib compiles fine in CWp5 and CWp6 now, and targets "Generic PPC" as it should instead of PPC 750 (G3)+ only like the original SDL CW codebase did, although they themselves distributed the runtimes based on the MPW version AFAIK, which, also AFAIK, produces the equivalent of "Generic PPC" binaries, so now we should also be consistent with that! All other targets already go for "Generic PPC". Like we discussed, we eventually can consider separate, G4-AltiVec-powered releases later, but without overdoing anything. Will replicate efforts for the CWp7 project. CWp5 can't compile SDLmain targets, though, because, just like how we dealt with InputSprockets yesterday, it comes out-of-the-box with older Apple headers that lack a few required type definitions and such. I duplicated the CWp5 project, called it "CWpro5to6" or similar, and auto-converted that to run with CWp6 instead, and SDLmain (as well as everything else) compiles perfectly fine over there, including the StdCLib one exclusive to the CWp5 project. Also, the Windows targets are all broken (as per the included documentation by the SDL team), and I wonder if we should remove them, or fix them. I'm leaning towards the former, since Windows is VERY well-covered by the SDL team anyway and, especially, because we are building for Mac OS. If Carbon was an OS-X-only thing, I'd conclude the same and consider getting rid of it, but it DOES run on Mac OS, even though maybe right now it only targets Mach-O? But if so that can be easily changed to PEF / CFM, no? ---- I have a question though about the CWp7 SDL project, and any other CWp7 projects being used for the add-ons, and the various SDL games that were ported and are being ported: is there a technical reason CWp7 was chosen over p6, or was it out of "convenience" in that it's what you had installed on some machines, or similar? In other words, if I make them all work with CWp6, are we losing something? Would some code fixes/tweaks be expected from the move from CWp7 to CWp6? I'm asking because, as we sort of touched upon yesterday, I was considering normalizing all SDL-related projects and targets to use just CWp6 (no CWp5, no CWp7), but without leaving anything behind (CWp5 exclusive targets, CWp7 benefits if any). I believe I should be able to have the PPC and 68k targets, Carbon targets, as well as those 2 CWp5-exclusive targets, all available from within the same, single CW project file. (Which I will make sure to be very careful about, and make NO mistakes with, and take no risks like that, and will definitely test the outcome of all targets properly.) That doesn't mean we can't have a separate CWp8/9/10 project file later, though, converted from said CWp6 project file, for optimization reasons, or for aligning whatever other later CW versions we use with game projects whose porting is facilitated by these versions (as we should compile the various SDL libs with the same CW version as is used for the game, to avoid problems). But the CWp6 project file could be their "reference point". ---- We also had the idea/thought of having a "master project", which would reference all the relevant SDL and SDL add-on projects (by adding the .mcp files as project files of the master project, or so we suspect?), but we can leave that for later, after I go through everything else I listed two posts ago. ---- Lemme know what you think about any of this, or even if I'm overstepping something here, or going a route you'd rather not go to. But so far things are going smoothly.
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #43 on: February 28, 2025, 18:05
|
Good deal on getting Carbon going again...I'm sure it'll be useful at some point! Even on MacOS 8.0 it adds some useful things (like nice file access funcs etc). I agree...prob no reason to leave Windows in there...only reason if, for some reason, somebody wanted to build the Windows version using a Mac CodeWarrior... We can probably get SDLMain building in cw5 by doing the same sort of trick we did for the Input Sprocket header... ---- You are correct in your guess about why I used cw7...solely because it is what I have on my ibook and g4, and it also seems slightly less "crashy" in SheepShaver. There are no TECHNICAL reasons to use it that I know of. It does have a few more "standard c" things than cw6, the MacOS X version of the IDE is much more "polished" (since cw6 was the first carbonized ide)...but not enough reasons to force anyone to use cw7. You'll notice for the add ons I have building for m68k, I, of course, had to use cw6 for that platform. I think I added ppc cw6 projects for those also. ---- I have mixed feelings about standardizing on one particular codewarrior version and cleaning up "extra" project files... On the one hand, yeah, cleaner is ALWAYS better...I get confused enough just having ppc AND m68k...but at the same time I want to preserve EVERYTHING that's there and only remove stuff if I have a good reason...and "clean" is not good enough for me personally...."hopelessly broken" is a different story... So I say you'd only be overstepping if you removed something I was actively using. I'd only be mildly annoyed if you removed something I wasn't, just because you wanted it "cleaner"...and maybe I'd keep it in "my version". Basically I'm saying, I want to support all versions of codewarrior possible, and, yeah, having so many project files is "ugly", but there isn't another way to do that. So, either drop support of things that work, which I wouldn't be happy about, or it will just have to be "a little ugly". As far as having a single "master" project...like I said there will be MAJOR problems with headers if you just try and do that. Having one project that includes OTHER projects as "dependencies" is the way to go like Goliath does. You "build" one project, and codewarrior sees the other projects are included in it, and it just goes ahead and builds them too. We'll definitely try that one day.
Last Edit: February 28, 2025, 18:07 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #44 on: February 28, 2025, 18:39
|
Alright, I will keep the CWp5 and p7 projects, and make sure they all are polished up nicely, too. Yes, I removed no files whatsover, I don't mind the "little ugly" approach of keeping things as they are. "Master project", yes, that's what I meant: a project to reference other projects. Let's see how that goes, once the time for it comes.
|
|
Pages: 1 2 [3] 4
|
| |||||||||||||||
|
© 2021 System7Today.com. |
