SDL 1.2.x for M68k attempt...



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


Author	SDL 1.2.x for M68k attempt... (Read 118266 times)
lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #45 on: January 08, 2025, 22:02 Was able to build a good static lib using SDL-1.2-main, using the supplied SDL-cw6.mcp.xml project. Then used it to build new working PPC copies of Breaker, SDL-Scavenger and MvM SDL. Haven't tried shared yet. I had to do quite a few things, I believe these are all of them: Missing items: Copied empty macos_prefix.h from my previous SDL. Copied SDL_config.h from my previous SDL. (This would've been created by "configure" but we can't run it on MacOS 9). Rescued Items: Removed BeOS version of SDL_libso.c Moved Mac SDL_libso.c to proper place in project and enabled it. Moved DrawSproket to Universal in macos libs (It seemed like there are duplicate DrawSprockets, I deleted of them). These were just to avoid a couple warnings: Created empty support macos include folder. Removed compiler opengl from access path. Created empty src endian folder Added support macos opengl to system access path. ---- I'm going to build all the audio tests and add more debug printfs to the audio driver to see if I can figure out where the problem with the buffers trashing the stack is on m68k. I'm still thinking about fixing 256 color mode, but if it runs well in Thousands of colors on my m68k hardware, it won't be a priority. ---- I was under the completely wrong impression that you couldn't mix shared and static libs, so I was disabling DrawSprockets, InputSprockets (joystick) and OpenGL in my static builds. This is, of course, not true. (Obviously you've seen I don't know a lot about shared libs on MacOS, never dealt with them before building SDL). All I had to do was add the stubs for all those to Breaker and the other programs. So I've reenabled everything and just used the stock SDL_config_macos.h So I'll probably upload Breaker and SDL scavenger with joystick support (not that I know how or if it works) to MG. I'll fold my m68k and appleevent changes into my copy of SDL-1.2-main and update SDL-unstable at MG soon. ---- For SDL2 I fixed the byte swapping and added a gestalt call to get amount of memory, so testplatform now works fully. The next thing will be memory allocation which I believe is broken. Like I said before I think it is using dummy routines that always fail. Once I do that, the graphical tests should build and run, or at least I'll know if the rest of SDL2 is actually working. It should be handling and manipulating bitmaps and surfaces, but without a video driver, nothing will be visible. Just as long as there are no errors and the log files show everything is being done. Took another look at the "plumbing" and the video part is especially, completely different from SDL1, so the likelihood of being able to port the video driver is very not good. Writing a new one from basically scratch, maybe using the concepts and copy pasting some from SDL1 in new functions is a possibility. If I find out that SDL2 really IS working, just not able to display anything, I might just do that.

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #46 on: January 09, 2025, 06:01 FINALLY tested on real m68k hardware. After quite a bit of jumping through hoops, I got Breaker, the SDL tests, and MvM SDL to it. Performance was...not good. This was on my Performa 630, which has a 33mhz '040, so, as good as it gets for m68k Macs, without an accelerator of some sort. (I don't know if there WERE faster '040's in the real world, and I think '030's go up to 50mhz). The SDL animation tests were quite slow. Far slower than in SS, and Basilisk runs rings around it. Breaker was...playable, in that the paddle moved smoothly, but the ball was so slow it really wasn't fair! I'm still waiting for the MvM System 6 disk image to SLOWLY unstuff, and will test the SDL build, but expect it to be pretty horrible. Getting 256 color mode fixed should help...a lot?...with it having to move half as many bytes for the pixels. The fact that SDL's Blit is mostly just a wrapper around CopyBits() is something to think about too. CopyBits() is truly a wonder, but it is all singing all dancing. So some pixel conversion and palette mapping may be going on behind the scenes, unless you program carefully. The fact that 256 color mode is broken may signify that the Blit code isn't optimized, as far as QuickDraw goes, it may be having CopyBits do more than it needs to with converting on the fly. Also highly optimized custom blit routines can beat it, as long as the conditions are all just right. We KNOW an '040 can push pixels fast enough, so there's a hangup somewhere.

cballero 1024 MB Posts: 1176 System 7, today and forever	Reply #47 on: January 09, 2025, 14:33 Ooh, I know this one; you're so close! It's definitely the second fastest 68040 chip, which was also used inside the Quadra 950 the fastest '040 Mac that Apple released came with a 40MHz chip! This was the Quadra 840AV, which also came with a 66.7MHz 3210 DSP processor, designed by AT&T for multimedia processing, along with plenty of other A/V goodies under the hood! That was my second dream machine of the time (in my fantasy also coupled with the 14 AV display and ergo keyboard Apple brought out at the time) the first being the IIfx, although I pictured realistically having a IIci, then a Quadra 700, both very cool 68k Macs when they came out!

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #48 on: January 09, 2025, 15:49 Well dang, I'm not batting very well with my memory of old Macs! @cballero, Thank You again. Without you, I'd be misleading folks! So guys, please take what I say (everything?!?) with a grain of salt, or two...or three... You know what makes it even worse?!? I actually owned a Quadra 840av at one point, many many years ago!!! I should have remembered! I'd picked it up at Goodwill, and sadly it had something wrong with it...it CONSTANTLY played a weird sequence of sound, although the normal Mac audio would come out on top of it. My guess was maybe the DSP subsystem was broken and it was playing the ENTIRE contents of its ram, from start to end and then looping. I gave it away because I was afraid that if it had that problem, there were probably other problems on the motherboard. I also had an 800, and the extra Mhz didn't feel worth dealing with an unstable machine at the time. I've got a 50 mhz '030 accelerator in one of my Amigas, and that wonder if that'd beat a 33 mhz '040. Unfortunately I can't compare Apples (hehe) to oranges here, as it doesn't have a good enough video card to run MacOS in color. ---- I'm thinking I might try writing a custom blit for the Mac video driver, and also going to look into running in a fullscreen vs window. For m68k I might also limit the size to a 320x200 pixel part of the screen/window. The other thing, that a lot of games used to do back in the day, is skip every other row, leaving them black. This was because the Atari, Amiga, and PC platforms ran a lot of games in 320x200 video modes, to fill up the Mac's larger 640x480 display. I'll go more into this if it looks viable, there are a lot of tricks for speed I remember from way back when. (Although now I am hesitant to fully trust my poor aging memory...) ---- I'm going to start a new topic for SDL2...this one is getting FAR too long already. Believe it or not I've been making real progress.
Last Edit: January 09, 2025, 16:29 by lauland
Jatoba 256 MB Posts: 270 System 9 Newcomer!	Reply #49 on: January 09, 2025, 19:14 Quote from: lauland Well dang, I'm not batting very well with my memory of old Macs! @cballero, Thank You again. Without you, I'd be misleading folks! So guys, please take what I say (everything?!?) with a grain of salt, or two...or three... Far from misleading us, thank you for patiently sharing all your knowledge and thoughts, and for putting up with people like me making mistakes all the time, like me thinking that 1.2.16 was perhaps "vandalized" and that the copyright dates weren't updated, or me mixing up threads and tasks etc.. No fear of judgment! We share what we believe to know and figure things out bit by bit. If something or the other is wrong, we point it out to each other. I have learned and been learning so much from all this exercise, I have nothing but gratitude for all the tutoring you gave me and everyone else here. Never would I have thought I'd be compiling and playing with other people's existing projects on the Mac like this, and figuring bits and pieces out like that, in a language and programming environment I was completely untrained at! Although a novice, now I am a lot less untrained, but still with a lot to learn and catch up to. I will try to keep this up. Also, SDL2 thread, go for it! I will stay on the SDL1 camp as this is as far as I can focus on right now, but I will be eagerly reading the updates as I have been (silently) up until now. ---- So, speaking of knowledge sharing, since so much was given to me, now's my turn to share what I learned (and I plan to keep doing that). Might be especially useful for other people who also might want to get their feet wet with CodeWarrior and/or C/C++, especially if they are poking on someone else's multi-targeting project without full knowledge of the source. While working on / poking at SDL 1.2.15 via CodeWarrior Pro 6 with the XML-based CWPro6 project file that we import into a regular .MCP project file via the IDE itself through the "Import Project..." item from the "File" menu, which is what we have been doing all this while compiling SDL, I noticed that if I threw away my WHOLE SDL source code folders (not just the CW one: I meant the whole thing we unzip), then started everything from scratch and try to do the whole thing again from memory, then compiled SDL 1.2.15 again (Debug static lib, Release shared lib, SDLmain static lib, Resource .rsrc file, stub lib), then compared the file sizes (via e.g. md5classic), I noticed that what I compiled was... different. It's one thing for checksums not to match, because it seems part of the binary is the compilation timestamp (?), but not the file size. Since I hadn't changed any compiler settings, like increasing compiler optimization (which would make the resulting binary bigger), nor anything like that at all, I was scratching my head for hours wondering WTH was going on. Another issue was that some things I had succeeded in compiling before. like the Resource file, was no longer compiling, and saying things that, at first, were not making sense to me. Things like "can't find compiler 'RunTSScript'". It turns out... because we imported things via the XML project file instead of just using a straight up "proper" MCP file without any importing... Some files that might be found in certain software projects, and especially file/folder structures, can confuse CodeWarrior. Well-curated MCP file > Any XML CW project file any day. But that alone isn't the cause for the problems I saw: so, due to the whole issue described in the previous paragraph, some files were not found, or the wrong version of the files were found, like @lauland helped me figure out time and time again throughout this thread, and so you remove the "bad" files and "add back" the correct ones. Sometimes that's a C file, or a compiled shared lib, or whatever. But because SDL is a CodeWarrior project that has multiple targets, when you add/remove a file, you are not doing so for the whole project... You are doing it for the target. CodeWarrior prompts you for what targets you want to add it to. The confusing part is that you see ALL files for all targets combined when browsing the CW project window, and it's difficult to keep track what files you added to what target. Especially when you are not sure a certain target will need a certain file, so (and here's the mistake) you add those files to all target that you think could or might need them. The end result? Some targets would no longer compile, because not only is the file you added unrelated, it cannot be compiled because it depends on other files that don't belong to the selected target. Or it gets compiled, but cannot link, for similar reasons. Or, the worst of all, it compiles and you think nothing is wrong, but you just bloated your own compiled result with junk that has nothing to do with it. And THAT last highlighted point is why I got different binary results with CWPro6 each time I dumped everything, and did things from scratch: re-adding libs like DrawSprocketLib and OpenGLLibraryStub was bloating, for example, my SDLmain static lib compiled & linked binary result. One way to investigate if some of the files you re-added are in the way is to switch to the "Link Order" tab, and see if a few C files or whatever "you expect" is included in there, but not much else, certainly not libs when all other libs are excluded... but then you see a few of them at the end of the link order, and they are the ones you re-added. Or if you're compiling a resource, and suddenly you see a wild C file in the Link Order! And so on. And... that's it. This was a longwinded "knowledge share", probably obvious for the experienced, and because it's so long many might not read it in a way they will understand, but... I made sure not to regret not to leave any notes about this user experience. Hopefully this helps someday. --- Back to "normalcy", I went ahead and decided to do one more thing with SDL 1.2.15 before moving on: all this while we were using CWPro6 with the included XML project file... But what about the NON-XML, MCP-based project file that is just sitting there all along from the beginning, intended for CodeWarrior Pro 5. So I went and gave it a go. The summary? Everything Just Works(tm) out-of-the-box: you simply open it in CWPro5, click on the "Make" button, done. Period. That's all!!! What a contrast from the XML-based proj file experience! Then you switch to the next target, click on "Make" again. Then the next one. And the next one. And so on! Incidentally, I opened it up also in CWPro6, got the warning the project file was going to be modified/updated to work with it, clicked on "OK", but no difference in there: you click on "Make", change to the next target, click on "Make" again, etc. etc.... And it's all done! Oh, and no need for that pesky blank "macos_prefix.h" or changing ANY settings, either. Now what caught my eye here was not only how easy it was to build SDL this way, but also that the targets are different. In short, the Carbon and Windows targets are gone (not that we want or need them in any way), AND there's another 2 Mac OS targets! I don't know what they are for, but here's the breakdown: CWPro6 XML file: - SDL Classic Debug: SDL.PPC.LIB (static lib, unoptimized, debug) - SDL Classic Release: SDLClassic (shared lib, optimized, release) - SDLmain Classic: SDLmain.PPC.LIB (static lib, meant for SDL app devs) - SDL MacOS Resource: SDL.rsrc (resource file, meant for SDL app devs) - SDL Stub Library: SDL.STUB (stub lib, meant for SDL app devs) CWPro5 MCP file: - SDL MacOS Debug: Same as "SDL Classic Debug" in CWPro6 XML - SDL MacOS Release: Same as "SDL Classic Release" in CWPro6 XML - SDLmain MacOS: Same as "SDLmain Classic" in CWPro6 XML - SDL MacOS Resource: Same as CWPro6 XML - SDL Stub Library: Same as CWPro6 XML - SDL MacOS Release StdCLib: SDL (shared lib, considerably smaller (272k) than "SDLClassic" shared lib (324k). Closer in size to, and still bigger than, the "SDL" file compiled via MPW (244k)) - SDLmain MacOS StdCLib: SDLmain.StdCLib.PPC.LIB (static lib, purpose unknown to me, but seems to be to "SDL" above what "SDLmain.PPC.LIB" is to "SDLClassic"?) I have no idea what those extra 2 targets are really for and how they differ from the others, but... I thought they were noteworthy. AFAIK "StdCLib" is the object file that contains Apple's implementation of the C Standard Library, but I have no idea how this explains what these 2 exclusive CWPro5 targets are for. (Again, you can compile the project using CWPro6, as well.) --- I will move on to the SDL 1.2.16 codebase very shortly now. Clearly I didn't try things enough nor pay enough attention to things last time.
Last Edit: January 09, 2025, 19:27 by Jatoba
Jatoba 256 MB Posts: 270 System 9 Newcomer!	Reply #50 on: January 09, 2025, 21:24 Btw, some extra notes for others and myself: - When adding a file to a multi-target project in CWPro6 (even with the latest "6.3" updates), once CW prompts you to choose the targets to add the file to, it gets completely ignored and only actually adds it to whatever target was last active in your project window. So you have to add it again in case you need it in more than 1 target; - When building with MPW, if you build everything, then add the optimization flag to the two relevant rows in the Make file, then build again, unless you deleted the previously-built object files, they will not be overwritten, and your SDL lib will not be optimized. You have to delete those then build again. The reverse is also true: if you build optimized, then build normal, the "normal" SDL will be optimized (because there's no compilation, but only linking, since nothing gets recompiled); - No idea how or if the provided MPW Make file allows one to compile anything other than the shared "SDL" lib, and its accompanying "SDLmain.o". Not as many options as with the provided CodeWarrior projects.

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #51 on: January 09, 2025, 21:58 @jatoba Your CodeWarrior knowledge dumps are excellent! I've seen exactly the same things. When I first started building MvM CodeWarrior "helpfully" somehow found files with the same names in my Goliath build folders, and added those folders to the Access Paths, even though it should have in no way been looking in there! I tossed out my SDL-unstable, as I was folding my changes into SDL-1.2-main, and the problems with the BeOS SDL_libso.c file seemed to come back from time to time, even though I'd removed them. Similar issues with trying to disable joystick support for m68k...I'd remove the file, and it would "grow back" if I tossed the CW proj data folder and reopened the project sometimes! I love CodeWarrior, but it is a fickle beast sometimes. ---- I have a new SDL-unstable, based on 1.2.16, with all my changes and will upload it to MG. Similar to above CodeWarrior weirdness...after rebuilding SDL 1.2.16 from scratch, with my changes, SDL Scavenger for m68k now actually runs for at least several minutes with no crashes. But it ignores ALL keypresses! I have no idea how or why that is happening. But very very strange I am no longer seeing the instant crashes I did with SDL 1.2.15...maybe a bug somewhere in SDL was fixed? One note I wanted you to know about how I built Breaker and SDL Scavenger: I actually took the MvM project files, removed the MvM source, added the games source and changed the names. I did this to save time creating new projects from scratch since I knew MvM SDL was building well for both PPC and M68k. ---- The xml files and CW5: Oh jeez. I have to admit, I'd only used an import of the CW6 xml file in CW6. (I've also been using CW7, but that's a different story). I haven't even looked at the CW5 project file, so never saw the extra targets. Will take a look. My guess is they use Apple's std c lib, instead of CW's MSL? That might explain why they are smaller...MSL is way bigger, and implements more official C standard stuff than Apple's. ---- I'm looking at other games that might be good candidates...both to further test SDL1, and possibly to start testing SDL2. I have NOT found any good ones. Almost all the good candidates require more than just base SDL. A lot of them require SDL_image and SDL_mixer, which are separate libraries, at least. So we need to seriously look into MacOS 9 ports of them, if they don't already exist (which I highly doubt). Porting SDL_image and SDL_mixer might be "easy" (by some definitions of that term), as they may be platform agnostic. So we'd mostly be dealing with CodeWarrior issues. If nobody's ever ported them to MacOS 9 before, we'll need to create project files from scratch, etc etc etc.
Last Edit: January 09, 2025, 22:03 by lauland
Jatoba 256 MB Posts: 270 System 9 Newcomer!	Reply #52 on: January 10, 2025, 11:50 Quote from: lauland Porting SDL_image and SDL_mixer might be "easy" (by some definitions of that term), as they may be platform agnostic. So we'd mostly be dealing with CodeWarrior issues. If nobody's ever ported them to MacOS 9 before, we'll need to create project files from scratch, etc etc etc. I decided to look into and dig all that stuff up. I have good news for SDL_image and especially SDL_mixer, and for some of the other SDL stuff like that. Here are my findings, all hosted in the official libsdl GitHub and also in archives (and occasionally live versions) of the official libsdl website: SDL_mixer - There's a branch dedicated to SDL 1.2, and is also called "SDL_mixer 1.2" in README; - Contains file "CWProject.sea.bin" and "MPWmake.sea.bin" (likely good Mac support!); - Is also forked for SDL2 (SDL2_mixer AKA SDL_mixer 2.0), with main branch for SDL3 (SDL3_mixer AKA SDL_mixer 3.0); - Used to be hosted here for SDL 1.2 in its latest stage, and here for SDL 2.0 in its latest stage; - zlib license for all versions, like SDL2 and 3. SDL_image - There's a branch dedicated to SDL 1.2, and is also called "SDL_image 1.2" in README; - Contains file "MPWmake.sea.bin" (likely some Mac support!); - Is also forked for SDL2 (SDL2_image AKA SDL_image 2.0), with main branch for SDL3 (SDL3_image AKA SDL_image 3.0); - Used to be hosted here for SDL 1.2 in its latest stage, and here for SDL 2.0 in its latest stage; - zlib license for all versions, like SDL2 and 3. SDL_net - There's a branch dedicated to SDL 1.2, and is also called "SDL_net 1.2" in README; - Explicitly mentions "MacOS Classic" support in README; - Contains file "MPWmake.sea.bin"; - Is also forked for SDL2 (SDL2_net AKA SDL_net 2.0), with main branch for SDL3 (SDL3_net AKA SDL_net 3.0); - Used to be hosted here for SDL 1.2 in its latest stage, and here for SDL 2.0 in its latest stage; - zlib license for all versions, like SDL2 and 3. SDL_ttf - There's a branch dedicated to SDL 1.2. Although not called that way in the README, it might also be tentatively nicknamed as "SDL_ttf 1.2" since the README for other versions follow this pattern, however we have to be careful because the latest version compatible with SDL 1.2 is "SDL_ttf 2.0.11", which easily can make one incorrectly assume it would be for SDL2, but that was only the case starting with the next MINOR version number jump, "SDL_ttf 2.0.12". Weird!; - Contains file "MPWmake.sea.bin" (likely some Mac support!); - Is also forked for SDL2 (SDL2_ttf AKA SDL_ttf 2.0), with main branch for SDL3 (SDL3_ttf AKA SDL_ttf 3.0); - Used to be hosted here for SDL 1.2 in its latest stage, and here for SDL 2.0 in its latest stage; - zlib license for all versions, like SDL2 and 3. Has extra warning on many popular fonts having various "dangerous" licenses, though. GUIlib - There's a branch dedicated to SDL 1.2. Functional, but non-full GUI framework for SDL. Developed only for SDL 1.2, but had some "last minute, quick" updates to make it compatible with SDL2, as well, via a separated branch. Final version is 1.2.1; - Contains file "MPWmake.sea.hqx" (likely some Mac support!); - The main branch is for SDL2, but was frozen (as in, made read-only) soon after the branch was created. As mentioned above, the SDL2 port is "quick-and-dirty", and so is seemingly also version as "1.2.1" at latest, and the same as the SDL 1.2 version, but to be consumed directly in SDL2 projects instead. Can very well be nicknamed "GUIlib2" or similar to distinguish from the SDL 1.2 version; - Still hosted on the live libsdl.org website here, listing support only for SDL 1.2; - zlib license for all versions, like SDL2 and 3. SDL_rtf - There's a branch dedicated to SDL 1.2. Although not called that way in the README, it might also be nicknamed as "SDL_rtf 1.2" since the README for other official SDL-related projects follow this pattern, although it's not clear if there was any other version besides "0.1.0"; - No CodeWarrior nor MPW files are included, however the project is incredibly minuscule and tiny, so should be not much trouble to get a CW project file going; - Is also forked for SDL2 (SDL2_rtf, can also be nicknamed "SDL_rtf 2.0"), with main branch for SDL3 (SDL3_rtf, can also be nicknamed "SDL_rtf 3.0"); - Used to be hosted here in its latest stage, but it seems that page was never again updated on libsdl.org once it was created and put online. It only lists the source of version "0.1.0" for download, and says it require SDL 1.2, with no mention of SDL2 or later; - zlib license for all versions, like SDL2 and 3. SDL_Cbs - What the heck is this, even? It's only available on libsdl.org here, and only contains a single file, which is a ZIP file, for download here. No mention of this on GitHub nor anywhere else I can easily see. Inside the ZIP are only 2 source files, "SDL_cbs.h" and "SDL_cbs.c", with the description "A GLUT-style loop/callback system for SDL". A lot of this stuff was discovered from this official URL, which also contains SDL test projects and whatnot: http://www.libsdl.org/projects/ Of note is the test project "aliens", because it specifically tests SDL with SDL_image and SDL_mixer! So this is what we will want to give it a try when compiling them. Incidentally, there's quite a list of other "libraries" (as opposed to "applications") to use, or even test things with if if we want, here. --------- The following are only for SDL2 and/or 3 and perhaps would be better in the SDL2 thread, but for convenience I will also share them here, below, to have it all in a single place: sdl12-compat - Contains only the main branch, and allows software written for SDL 1.2 to work with SDL2 behind-the-scenes. This could be useful for testing SDL2 Mac OS 9 builds against games we used in SDL 1.2, such as Breaker, SDL Scavenger and even apps like Mini vMac SDL. This way we don't necessarily need a list of SDL2 games and other software to port to test Mac OS SDL2 with, although that would STILL be helpful to have to avoid any potential headache associated with the sdl12-compat overhead, but it's still something. sdl2-compat - Same as above, but for getting SDL2 software to run using SDL3 behind-the-scenes (can we use sdl12-compat + sdl2-compat to run SDL 1.2 software via SDL3, then? Hehe). This also is a confusing project name because the "l" in "sdl" looks like the number "1", and so "sdl2" looks like contains a "12", and is easy to mistake for the existing "sdl12" project, and vice-versa. SDL_gesture - SDL2-only API removed in SDL3. Available in its sole branch; - README says it does not contain "formal releases of code", and that "just grab the latest and drop it into your project!". SDL_shadercross - Very new SDL2/3 project, started in June 2024 based on commit history, all contained in this single branch. Intended for SDL's GPU API for translating shaders between various formats. SDL_shader_tools - Quoting the README from its sole branch: "THIS IS A WORK IN PROGRESS", "This is not yet ready for anything, let alone production use.", "It's not clear if this will continue to live in a separate project or become part of SDL itself. At the very least, it will definitely move to a different location on GitHub.", "This will--eventually, I hope--become tools used to generate shader bytecode for SDL's GPU API.". --------- Of note, throughout all this digging, I also discovered there was supposed to be an SDL 1.3, but that was never released, clearly based on an older release of SDL 1.2 than what was later released, and so naturally much later than SDL 1.2.16, so it is of limited, if any, use for us or anyone else. Source code still available, frozen (meaning "read-only"), here, and also used to be available on libsdl.org here. Clearly this was dumped in favor of rewriting SDL as a whole into what eventually became SDL2, I think is safe for us to assume. (I might still look at it out of curiosity, though.) EDIT: Fixed the broken BBcode tag usage. EDIT 2: Fixed hyperlink to sdl12-compat.
Last Edit: January 12, 2025, 20:08 by Jatoba
lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #53 on: January 10, 2025, 15:07 Great stuff! I'm taking a look at all the SDL_image/_mixer/etc 1.2 branches from their githubs and will see what's up with them.

Jatoba 256 MB Posts: 270 System 9 Newcomer!	Reply #54 on: January 10, 2025, 17:43 Just a heads up, I fixed my broken BBcode use around SDL_ttf and GUIlib up there. Thankfully S7T still let me edit it. I hope it serves better as consultation material for us this way, or knowledge hub.

Jatoba 256 MB Posts: 270 System 9 Newcomer!	Reply #55 on: January 10, 2025, 19:36 Quote from: Jatoba - SDL MacOS Release StdCLib: SDL (shared lib, considerably smaller (272k) than "SDLClassic" shared lib (324k). Closer in size to, and still bigger than, the "SDL" file compiled via MPW (244k)) - SDLmain MacOS StdCLib: SDLmain.StdCLib.PPC.LIB (static lib, purpose unknown to me, but seems to be to "SDL" above what "SDLmain.PPC.LIB" is to "SDLClassic"?) Quote from: lauland My guess is they use Apple's std c lib, instead of CW's MSL? That might explain why they are smaller...MSL is way bigger, and implements more official C standard stuff than Apple's. I just realize that, oddly, the included CWprojects.txt file describes them, as it does for the Carbon and Windows targets, even though these 2 Mac targets aren't in the CWPro6 XML proj file. To quote: Quote from: SDL Docs SDL MacOS Release StdCLib - preferred for shipping/distributing for Classic - uses Standard C Library ("StdCLib") in System SDLmain MacOS StdCLib - use in conjunction with above library. In other words, it seems likely we probably will prefer these, assuming these are speedier (they certainly are lighter in size), although maybe it doesn't make a difference in practice? Also, I feel that most likely this is the "SDL" that MPW also builds, but with a different compiler. I will keep that in mind as I try them against different SDL software on the Mac. Speaking of MPW, I forgot to mention that, aside from the official build instructions and Matej's additional instructions, it is also needed that we take the file "SDL.x" in "{sdlRoot}:src:main:macos:exports:" and change its TYPE code to "TEXT" (easy via Get Info if Snitch is installed). If we don't, MPW will not be able to build SDL, and will tell you to do exactly that (but its error message is easy to miss, so I'm also spelling it out here). Also, minor curious tidbit, if we build "SDLClassic" using the CWPro5 MCP file vs. the CWPro6 XML file, their icon looks different: it's the "generic" for the former (and for MPW), and this neat "SDL logo shared lib" icon for the latter: http://revontulet.org/2025/01/10/e5781060e219423b894795b6c0e1a15f.jpg Building with the CWPro5 MCP file using CWPro6 will still yield the same "generic" shared lib icon, though, so there's some additional resource data that is being pulled from somewhere in the CWPro6 project file?

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #56 on: January 10, 2025, 20:41 I was able to build SDL_mixer (static only) with the included CW project file, using CW 5.3 as they specified. I tried CW6 first, but had trouble. I still ran into a bunch of tiny problems even using CW5. The project referred to a couple non-existent files, one file's name had changed, and I had to tweak the language settings. And, of course, the access paths were messed up. It also used a function "strtok_r" that CW's MSL doesn't have. There were #ifdef's for other compilers that would use plain "strtok" so I got it work by adding " \|\| defined(__MWERKS__)" FYI It came with it's own copy of SDL itself, but I couldn't get it to build using that. Those include files were missing some defs the source used. Tossed the include folder and used the one from SDL 1.2.16. I'm going to try building SDL_image and the others using MPW next. I might also try creating CW project files for them from scratch since CW is so much easier to use (at least from a gui standpoint). I'll upload my built SDL_mixer to to SDL MG page, so at least save others the effort of trying to build it. I don't think any of the candidate games I'm looking at JUST want SDL_mixer...they also all seem to want SDL_image... ---- Hmm...yeah, originally there was no Apple supplied Standard C Library, and every app carried along it's own copy built in statically from whatever compiler was used to build them. At some point Apple made one (I think it is part of the System file), so I think that is what those StdCLib targets are talking about. It would definitely make the executables smaller (because they won't include a copy of at least part of MSL?), but I doubt it'd make them any faster. Then again...Apple's StdCLib MIGHT be faster than MSL just because it doesn't try to do as much? ---- That icon: I noticed something similar with MvM when I converted the CW5 projects into CW6. I think the Creator type gets lost. So the MvM apps started just looking like generic "applications" and not the cute little mac icon. ---- I think mostly the problem is the sources are newer than the CW project files (which never got updated). Us just supplying ones we have already "fixed" with the 1.2.16+ "distros" will help quite a bit.
Last Edit: January 10, 2025, 20:48 by lauland
Jatoba 256 MB Posts: 270 System 9 Newcomer!	Reply #57 on: January 11, 2025, 19:11 It's really awesome you got so much done for SDL_mixer already! Really great to see it added to the Garden, as well. Incidentally, I just did a complete overhaul of the SDL Garden page. I hope you will find it a lot clearer, cleaner, more organized and more concise now. I did my absolute best with it. I trimmed it massively without removing any information or hyperlink, as well. Short of fixing the version string, I also finally added a completely unmodified 1.2.15 "devel" (and runtime and source), although it might serve very little purpose now that we have taken over 1.2.16. Quote from: lauland At some point Apple made one (I think it is part of the System file), so I think that is what those StdCLib targets are talking about. It would definitely make the executables smaller (because they won't include a copy of at least part of MSL?), but I doubt it'd make them any faster. Then again...Apple's StdCLib MIGHT be faster than MSL just because it doesn't try to do as much? Ah ha, that certainly explains everything. I also ran many of the test apps against both "SDL" and "SDLClassic" shared libs for some basic "benchmarking" multiple times over and over again. My conclusion is that my expectation was wrong: there's no real speed difference between them. The one that was also compiled with the "-opt speed" flag in MPW also was much of the same. Of course, we can still swap them around with whichever SDL apps we have on our hands to see if there are any differences in the "real world" or not. Probably not. Incidentally, all apps I tested so far, including Mini vMac, will not run if either "SDL" or "SDLClassic" is not there: it doesn't seem like it tries to search for them elsewhere at all. And if I put a faulty SDL shared lib in the folder instead, there are app errors, so it seems to only be looking for it in the same directory of the running app. One other thing, it seems you were right before about SDL apps looking for some "internal name" rather than the file name of the shared lib, hence why both "SDL" and "SDLClassic" works. Renaming either to just "Banana Computer Inc." also works! I remember when compiling SDL in CodeWarrior, I saw "SDL" being used as a keyword somewhere in project settings regardless if we compile "SDLClassic" or "SDL". In short, I think we are good using either of the two! --- Now I will try to replicate what was done for 1.2.15 for 1.2.16, as well. I hope that by the time I'm done, I'm not too late to help with the actual code parts in "SDL-unstable" or the various SDL extra libs! If I can be of any help, that is. (I will certainly try, I should be capable of helping somewhere.)
Last Edit: January 11, 2025, 19:13 by Jatoba
lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #58 on: January 12, 2025, 01:36 The reorg of the SDL page looks really good! Way easier to read and your explanations are very clear! ---- I've made a lot of progress with SDL_image too! I can build the "aliens" demo which uses them both. Will upload my SDL_image to MG. At the same time, while building them, it looks like you have to enable what formats they support. So the SDL_mixer I have up there probably doesn't actually work! (But having SOMETHING there is better than nothing). Once I enabled WAV and MOD support I am running into a lot of bizarre compile errors...it is telling me some symbols are undefined when linking, when I can see they obviously should be. Anyway I'm working on it, but will probably replace the one at MG with one at works, but doesn't support the formats we want. I had more luck with SDL_image, I copied SDL_mixer's CW project and replaced everything (it didn't come with a CW project, has MPW makefile, but I haven't tried it yet). It is building static and supporting basic formats like gif and several others. I'm having some trouble with the more common jpeg and/or png. Also some trouble with tiff, so left it out. It basically works without them, so will upload to MG at least as a placeholder. ---- I think you could put the SDL shared lib (with whatever name?) in the Extensions folder in your System Folder and it will find it there. I'm pretty sure that is the case, but haven't tested it. Quite a few standard/common "Extensions" really are just shared libs. That way you'd only need a single copy of SDL. ---- Since I now had an SDL_mixer and SDL_image that at least build and link (even if not supporting all the file formats needed), I decided to start looking at further games to try porting and tried several. It looks like I had actually run into amazingly good luck with the process for Breaker and SDL Scavenger going so smoothly...I am batting very close to zero percent with these new games... http://macintoshgarden.org/games/labbaye-des-morts This one needs SDL_ttf, so I'll be looking at it to get any further... http://macintoshgarden.org/games/freedroid-classic Clone of one of my fav old c64 games...TONS of compile errors, working through them, but running into this odd C syntax: SDL_Color lift_bg_color = {.r = 0,.g = 0, .b = 0}; /* black... */ CodeWarrior doesn't understand that, and I never knew you could init structs like that...not sure what to replace them with...it's FULL of stuff like that. http://macintoshgarden.org/games/lbreakout-2 Deceptively complex design, with networking and front and back end split. I'm having trouble figuring out which files to even include in the project for a version that doesn't support networking (and thus doesn't require SDL_net, yet ANOTHER project). http://macintoshgarden.org/games/berusky Grabbed the github, but found it mostly was only a readme telling you to go elsewhere to get it...will try once I actually find the source. http://macintoshgarden.org/games/sdl-ball Uses OpenGL, and threw me for a loop, but I think we have it working so will take another look... http://macintoshgarden.org/games/snoopy-vs-the-red-baron-2001 Also deceptively complicated design-wise, using sophisticated C++ exceptions and more. This is the only one I've actually got fully building. It prints some stuff and then SDL_image throws a weird JPEG error about mismatching struct sizes. Makes me think I may not be as far with SDL_image as I thought I was. How the heck can a struct be different sizes if the compile settings are the same for the lib and app?!? ---- A bunch of the stuff I'm dealing with for these "ports" are limitations or missing things in CodeWarrior. Putting workarounds, simpler replacements, or outright disabling bits. I think MPW would probably be even worse, as it is older and they didn't make as much of an effort to keep up with industry language standards. I know two of the above are "Breakout" style games...and Breaker is of course the same idea. I thought they'd probably be easy to port. Let me know if you find another SDL game you'd like me to look at.
Last Edit: January 12, 2025, 01:59 by lauland
Bolkonskij Administrator 1024 MB Posts: 2023	Reply #59 on: January 12, 2025, 12:31 Amazing job, guys! I've been plowing through your posts and at times was like "wheh,what are they talking about?" and made notes of stuff I need to look up ;-) Didn't ScummVM (modern browser needed) use SDL 1.2 for quite some time before moving on to SDL 2.x? Might be a good candidate for porting since it's well documented and maintained but it's a little more complex than your average breakout game.

	Pages: 1 2 3 [4] 5 6 ... 8

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