|
|
|
|
| Welcome, Guest | Home | Search | Login | Register | |
| Author | SDL 1.2.x for M68k attempt... (Read 118264 times) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
lauland
512 MB  Posts: 674 Symtes 7 Mewconer! 
|
Reply #90 on: February 03, 2025, 05:33
Ok...I found Breaker can run in 256 color mode...it actually has three different modes "default" "scaledx2" and "scaledx2tv" (where I think it puts fake "scan lines" in to try and look a bit like a CRT). Anyway...at least ONE of those works in 256 colors. Can't tell if it is actually faster, but will try a 68k build on real hardware and see. I'm thinking it is STILL too slow. ---- Getting closer to figuring out the keysym->sym/unicode thing. If you build SDL with "Enums always int" turned off it shows up. But it ALSO shows up if you try and use a copy of SDL built using CW6 with a game you're compiling using CW7...a bit hard to explain and I'm trying to nail down how and when it is triggered. Still don't know exactly WHAT is going on WHERE in the first place...but it is likely NOT something as simple as the key values being defined weird...but then again it might... ---- Someone at MG downloaded my version of "Breaker" (the Arkanoid clone) for MacOS Classic and reported having trouble running it in MacOS 8.1 on an 8500, both the PPC and 68k versions, which was an unpleasant surprise. I think I set the memory requirements too high for the 68k version, but in testing found out a problen with the PPC version of SDL I've been building: Any app you build with it will require not only MacOS 8.6, but also Game Sprockets and OpenGL...which is unexpected and unfortunate. This has SOMETHING to do with the way shared libs are being linked. I know a lot about shared libs on other platforms, but aren't as familiar with them on Classic MacOS so I might be doing something silly. With many platforms/compilers you can do a "weak" or a "strong" link. Weak means the lib doesn't HAVE to be present on the user's system for the app to run...but your code has to check if it is there or not before trying to call any functions in the lib, or it will crash. I can't tell if the SDL code is smart enough and actually checks things, or just blindly assumes they are there. This didn't show up in the 68k version because it doesn't use shared libraries, and leaves support for Game Sprockets and OpenGL out completely. The first times I was building SDL for PPC I left them out also, so those early versions also didn't require them. I'm unclear how we could build SDL with support for them, but make them strictly optional...we may need to fix some assumptions in SDL in a few places. The other possibility is having a "MacOS 9" version with all the bells and whistles and a "System 7" version which leaves them out...but having two binary versions is a pain. And these requirements are inherited by the apps, so if I wanted a game to run on System 7 PPC, I'd have to build it with the limited version. Anyway...you get the idea. I need to figure out more about what exactly is going on. ---- Finally...found the problem with "Abbaye" was playing music somehow...so could be a bug in SDL_mixer...specifically with playing wav files asynchronously, I think in the callback when the particular sound is done playing...or could be an "Abbaye" bug? |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Last Edit: February 03, 2025, 05:35 by lauland
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #91 on: February 06, 2025, 15:31
|
Took a REALLY long hard look at SDL_romaudio.c, the Mac audio driver, in an attempt to get sound working on m68k and came to two conclusions... First, it uses a callback function, and on the 68k it isn't receiving its parameters correctly. What should be a "channel" and "command" pointers end up being nonsense. On PPC this is a "UniversalProcPointer", which is some "MixedMode" magic, but on 68k it is just a function pointer. I thought maybe it was getting created wrong with NewSndCallBackUPP...but by Apple Magic on 68k that only actually creates a UPP on PPC or CFM-68k, and is just a normal func pointer on plain m68k, as it should be...so don't know why when it actually gets called it isn't getting the right data... Second, I do NOT understand how the code actually works. I know how basic Sound Manager code is done on classic MacOS, with SndDoCommand and a callback when it's pretty simple...but it is doing something that throws me for a loop a bit...the callback actually calls SndDoCommand (and thus itself, after being called by a PREVIOUS SndDoCommand already) TWICE. I'm not following the logic of why it does it...in most cases the callback should play the sound and return, to tell its caller it is done, and needs its buffer refilled, which happens, and then it gets called again, repeat. So they may be doing something more clever than usual...or kludgey...or it just may be just beyond my level of understanding. ---- Since I don't understand why they're doing this, it doubly makes the fact that the callback is getting nonsense (even on its first call, let alone when it calls ITSELF) a mystery. So, the code might be doing things that are fine on PPC, and you just can't do on m68k...so we'd need new code to do sound on m68k...OR...the code is goofy in the first place and not entirely doing things correctly and/or in a "clever" way that isn't quite kosher. There's also a "USE_RYANS_SOUNDCODE" define in there making things even weirder...ie it looks like the SDL source we have was in flux, and the Mac sound code had previously been simpler, but new code had just been added, but not ENTIRELY replacing the older existing code. So looking at older versions, we may find code that's easier to understand, simpler, and maybe "less clever"? Anyway...because ALL sound handling goes through this driver, it may provide a clue why "Abbaye Des Morts" background music crashes: The driver is just plain weird and maybe buggy (or even "wrong") in the first place. So I'm going to read the Apple docs on how to use SndDoCommand and callbacks officially and/or find some of their example code using it...both will help me understand what the driver is trying to do, maybe allow me to "fix it" if it IS buggy, or write new code, etc etc etc.
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #92 on: February 07, 2025, 15:37
|
Ok...starting to understand the code. There's actually two different audio drivers in there, controlled by the "USE_RYANS_SOUNDCODE" define and/or if you are building Carbon. But there's a typo...it has this: #if defined(TARGET_API_MAC_CARBON) || defined(USE_RYANS_SOUNDCODE) when it should be this: #if TARGET_API_MAC_CARBON || defined(USE_RYANS_SOUNDCODE) I've made exactly this typo myself when Carbonating things. The problem is that if you are using Universal Headers with Carbon support then TARGET_API_MAC_CARBON is ALWAYS defined, but its VALUE will only be 1 if you are building Carbon...so what they have in SDL_romaudio.c means it will ALWAYS use the new driver, even if USE_RYANS_SOUNDCODE is undefined, ie even when you AREN'T building Carbon. With that change, then you can use USE_RYANS_SOUNDCODE the way it was supposed to work...ie not define it and you get the "old code". When they made this typo the Mac SDL coders just starting only using the new driver and didn't notice the typo. ---- Both drivers do double buffering, but the new code (RYAN), with the callback that (potentially) calls itself twice, handles the buffers itself, while the previous code just calls the Sound Manager's SndPlayDoubleBuffer and lets it handle the buffers. The new (RYAN) code's callback first SoundDoCommand queues up the buffer it isn't playing right then, while the second call actually plays it. It only does the second if sound is currently playing. So I now am starting to understand how that works. For "Abbaye"'s background music this clever "recursion" might be getting stuck and never returns. I need to fully understand it to fix this...if I'm right about what is happening, that is...but I'm getting a lot closer. I think this only happens if the sound it is playing is very long, or looped, which is why it didn't affect the other game ports. Meanwhile, I built SDL using the old (non-RYAN) sound driver, and the SDL_mixer demo "playwave" doesn't produce sound and just hangs. So the old driver might have problems too. But I'm going to look very closely at it, because it might work on m68k. So there's something wrong with it too. It has a different callback, which isn't "recursive", and in the demo it DOES return, but playwave still gets stuck someplace. Macsbug will help me figure that out. My first thought is it might just not work with something SDL_mixer needs, but I don't hear ANY sound. If that were the case, I'd expect to hear something. So...lots of fun learning about sound on classic Mac...which I only previously knew the basics of...
Last Edit: February 07, 2025, 15:41 by lauland
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #93 on: February 09, 2025, 18:29
|
Sound: So the "old" aka non-RYAN driver seems to work fine, even on m68k...and background music in "Abbaye" even works sometimes but still crashes on occasion... I believe it may not be locking things properly and possibly both drivers may be accidentally attempting to modify a buffer while it is playing and causing the crashes. ---- Joysticks: Actually work on PPC with Input Sprockets, even in "Classic" in MacOS X...but a bit limited. I tried 5 devices, including "Logictech 3d extreme" actual stick, others various gamepads. The only one that Input Sprockets actually detected was one whose USB device string was "USB Joystick", everything else it ignored. I believe this is Input Sprocket limitation and not SDL since SDL just makes VERY generic calls. Gravis Gamepad whose string was something like "Gravis Gampad" (duh) wasn't detected. Tried XBox controller and Input Sprockets said it needed to connect to internet to "download software" for it...ha! Up and down were reversed, but generic "USB Joystick" otherwise worked perfectly in SDL Scavenger and SDLRoids both which use SDL joystick support. Other games didn't have it, but I might be able to write new code, if it were worth the trouble... The up/down thing may be bug in SDL...the games read the joy "axis" and negative numbers are up and positive ones down, which makes sense. So they may have just gotten the sign wrong. I'm going to hack and just reverse it. ---- EDIT: Turns out "typo"/bug in SDL code... #if kISpDeviceClass_Gamepad kISpDeviceClass_Gamepad, #endif Removing the #if and almost all joysticks/pads now work. The only one that has up/down reversed is the generic "USB Joystick", where maybe it SHOULD be identifying itself as a "Gamepad" but is instead "Joystick"? Even able to play SDLRoids with this crazy thing I picked up at Goodwill: https://www.pcgamesn.com/logitech/extreme-3d-pro-joystick-review (modern browser)
Last Edit: February 09, 2025, 19:43 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #94 on: February 11, 2025, 18:51
|
@lauland By the way, I finally made a Garden thread to give a shoutout to all these porting efforts so far: link. I'm still dealing with backups of my Mac mini, but I found the opportunity to finally write this. Hopefully it puts some attention on this, more people join in on the fun and play all those ports you released, and perhaps, who knows, we even get others to one day also jump in on the porting efforts!
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #95 on: February 11, 2025, 19:48
|
Good deal! I was actually going to suggest it...I've gotten enough comments on the individual game pages that SOME more sort of explanation was probably needed about what they actually were and came from.
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #96 on: March 08, 2025, 06:58
|
@Jatoba, many apologies for the delay in testing your new "SDL 1.2.16+"!!! I got distracted with hacking mutant CodeWarriors, and SDL on Amiga and Linux, and CodeWarrior DevStudio 9 and 10! But...back to our main project...the all important SDL on classic MacOS! Ok...there are a couple issues we'll need to fix before your efforts can replace mine as the "cutting edge" aka "very latest" aka "unstable"...but I think they're pretty simple. I think they are all CodeWarrior quirks, and the code you wrote to get around "old headers" all looks perfect! So, first I'm testing with CW6, building my SDL game ports using your SDL for both M68k and PPC...I need to note that I'm only testing the "regular" static versions of your libs, since that's what my games use. (I can test the shared/Carbon/StdCLib ones later, they'll probably just show the same issues). ---- M68k: I'm getting link errors, but I think they may be simple to fix: "mini Ser 9 Flex:Desktop Folder:lauland's latest:SDL 1.2.16+:SDL-1.2-main:src:joystick:SDL_joystick.c..." then it lists four joystick functions as undefined. (I don't know why it's showing your full path.) I believe this may be because your cw6 m68k project has the Mac joystick file enabled, and NOT the dummy. Since joysticks require Input Sprocket, we can't support them on m68k and must use the dummy...or have joysticks completely disabled...I can't remember which, but will figure it out for you. ---- PPC: I'm getting a link error that "tolower" is not defined. I had this problem early on and created the "tolower_hack.c" file to get around it...BUT...I thought I'd fixed it on PPC, and it was only needed on M68k. I think the issue is actually due to a goofy header CW header thing, with it finding the wrong one. I never fully figured it out, hence the "hack" which, truthfully, was a brain dead way to fix it, but it worked and I never went back to figure it out. I think your access paths being different than mine (I think yours are now more correct, actually) made the bug show up again. We should probably figure out what is REALLY going on and fix it for real. I'm going to look into it and will let you know. ---- Ok...now CW7...again, only "regular" static lib... ---- PPC: Exact same "tolower" error as in CW6...so the fix will be the same. ---- So, these are actually VERY minor issues. I think if you look at the m68k project, fixing the (non-existent) joystick should be pretty easy. Take a look and you can probably just enable the correct file...if that doesn't work, then it's SDL_config_macos.h maybe? The "tolower" thing is a weirder one and I'll fix it and get back to you ASAP...I think a "quick fix" would be to just include "tolower_hack.c" in the PPC projects. I really don't fully understand what is going on...I have a theory that it might be related to the StdCLib folder and that might be why I stuff'ed it...but aren't actually sure.
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #97 on: March 08, 2025, 08:27
|
Oh, don't mind it, we do these things when we can, and if we want to, or if the time to work on them is right! ---- Quote from: lauland "mini Ser 9 Flex:Desktop Folder:lauland's latest:SDL 1.2.16+:SDL-1.2-main:src:joystick:SDL_joystick.c..." [...] (I don't know why it's showing your full path.) It's fascinating how CW is somehow still pulling out absolute paths from somewhere... I just checked again the "Access Paths" from my side in CWp6 for both PPC and 68k projects, and every target's access paths are set relatively, based on either {Project} or {Compiler}. It must be storing, and pulling, this from somewhere from the corresponding " Data" folder, full of proprietarily-formatted, pre-compiled object files. And it must be doing so in such a way it is completely disregarding the Access Paths. Could you try seeing if deleting the " Data" folders, CW reports your path correctly during the Link Error? (If the error won't then disappear.) At least with certain C#/VB.NET Visual Studio projects, it's customary among us more senior developers to be at least wary of the "bin" and "obj" folders, which sometimes are best deleted when a "Clean Build" command or restarting Visual Studio is insufficient. We might have a similar issue... And I underestimated it. Lesson learned. UPDATE: Oh wait, the link error you are seeing is not when building/linking SDL, but rather using the SDL static libs in the games, THEN the linking error occurs. Hm, weird how it's showing those absolute paths in such a case, like it becomes a part of the SDL binaries no matter what. Not sure what we can do about that... But I can still try out throwing away all the generated " Data" folders and, now that the paths are for sure relative in the Access Paths, try rebuilding and relinking them, and see if this quirk gets addressed. ---- About the 68k dummy vs. Mac joystick issue, on my end the "Debug" (static lib) target and SDLmain both compile in the CWp6 68k project, with no error message thrown regarding those 4 undefined joystick functions... But again, I think these errors are only occurring when building the games, not the libs themselves, right...? I will try to see if it will go away if the dummy vs. Mac file problem is corrected. ---- Sorry about my dirty laundry that still lingered behind! Thanks for looking into these... really looking forward to seeing how those mysteries will turn out.
Last Edit: March 08, 2025, 08:31 by Jatoba
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #98 on: March 08, 2025, 16:45
|
Hey, jump on HotLine if you can. I'll try and be on as early as possible both Sat and Sun so our timezones at least overlap a little. I remembered what the tolower() problem is and how to fix it...I'll write more in a bit...and answer the rest of your post, but wanted to let you know I'm on HotLine right now in case you read this....
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #99 on: March 08, 2025, 17:11
|
Yeah, it couldn't be part of the " Data" folder, because that was on MY drive! Ok, figured out why the "path" is still showing...it's actually CodeWarrior trying to be helpful! It records the location of all the source files in the built .LIB files. This is useful because it can tell you the exact file where the error PROBABLY is, so it's part of the "debug data". So, it's normal, a little irritating that it exposes the paths used to build a project, but at the same time, desirable, since it helps a lot with debugging! So absolutely nothing to do with access paths. BTW was amused by your super deep folder structure! I just dump EVERYTHING right there at the root of my hard drives...I'm not a very organized person... ---- The tolower() problem is because SDL doesn't have #include <ctype.h> in several places where it calls it. This would normally produce an error, but doesn't because we have "require function prototypes" unchecked in the SDL CW project settings. So...CodeWarrior just assumes tolower() is a function, and when you build the lib marks it as something that needs to be linked. BUT...in MSL tolower() ISN'T a function, but a macro in ctype.h... I even put a comment about this in tolower_hack.c that says this, but had forgotten! To fix it, we need to find ALL SDL files that reference tolower(), and add "#include <ctype.h>" to them. A bit of a pain that I just worked around with my goofy tolower_hack.c! Which works because it defines a tolower() FUNCTION that doesn't exist in MSL (because its a macro instead). I just never bothered to "fix it right". We might as well now...I'll do so, and let you know once I have. I think for PPC, but not M68k, I worked around it to avoid tolower_hack.c somehow...but when you fixed the access paths, whatever workaround I'd found broke. Doesn't matter, because your access paths are more correct than mine, and we'll fix it correctly now... ---- You're correct in that the m68k joystick errors only show when you USE the .LIB file, not when building it. I'm looking into the problem specifically right now, just to be sure it actually is what I'm guessing, ie the "dummy". I'll let you know what the fix ACTUALLY is. ---- Zero problem with bugs...there always are some you need to deal with when making changes, so not dirty laundry at all...and they're absolutely worth it for all the hard work you did!
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #100 on: March 08, 2025, 18:58
|
Confirmed: Your CW6 M68k SDL project is using the wrong SDL_sysjoystick.c...it just needs to be changed to the "dummy" version. ---- Ok...one more minor problem with m68k using the new SDL-main, involving audio. I think the copy I uploaded that you used was missing a TINY fix to force m68k to use the old "non-RYAN" driver: It needs THIS line in SDL_romaudio.h: #define USE_RYANS_SOUNDCODE Changed to this: #if powerc #define USE_RYANS_SOUNDCODE #endif This forces SDL to use the old "non-RYAN" driver for m68k, where it actually works! At the same time, the background music for Abbaye des Morts works, at least for a bit before crashing, using the "non-RYAN" driver on ppc...so I've been using builds of SDL ppc with the "RYAN" driver disabled ie: /*#define USE_RYANS_SOUNDCODE*/ Since I haven't solved the audio crash problem...and don't even know "how deep" it goes, I don't know...it's possible the "RYAN" driver was never fully finished. It looks like it was MOSTLY written for Carbon, but works on non-Carb PPC fine...other than for Abbaye's background music. ---- Anyway...after the fixes above, your m68k SDL works perfectly! Still working on the tolower() issue...I now remember I'd actually looked into it and just adding #include <ctype.h> should work, but is ugly...and it actually looks like it should ALREADY be included...I tried adding tolower_hack.c and that caused duplicate tolower errors do not understand why...regardless, I'm working on it...
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #101 on: March 08, 2025, 22:18
|
Good news! The tolower() thing PROBABLY isn't even a bug at all...I did a "Remove Object Code..." for SDL and rebuilt the lib from scratch and did the same for the game ports and the bug didn't show! Did the same thing for PPC cw6 and cw7 and neither showed the bug. I do NOT know what happened, maybe the .LIB file was built with cw7 and shows when using it with cw6? Or the other way around. When I switched to cw7 to test, I had ALREADY rebuilt the SDL .LIB using cw6... Whenever I switch between cw6 and cw7 I almost always do a rebuild of the static SDL lib, just out of habit and to make sure everything is up to date. (ie any changes I made using one compiler is propagated to the other). I hadn't done so at first because I wanted to test your .LIB files. So, it might still be something we need to fix slash look into...because otherwise the same .LIB file can't be used with both compilers...maybe? I'll have to try and reproduce the error AGAIN...
Last Edit: March 08, 2025, 22:21 by lauland
|
Knezzen
|
Administrator 512 MB  Posts: 608 Village idiot
Reply #102 on: March 09, 2025, 13:48
|
Wow! Great job, lauland! btw, are you upstreaming everything to the SDL project as well?
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #103 on: March 09, 2025, 19:23
|
So, yeah, I don't think there were any actual problems with PPC, only the joystick and audio on m68k! ---- We haven't upstreamed anything to the main SDL repos yet, because the state of Classic MacOS support was stalled for so long, pretty much abandoned. It's not clear how our changes will be accepted. We wanted to be EXTREMELY stable and solid before we reached out to make them "official". It's DEFINITELY something we want, as our code works very well, and should be part of the main stream for the benefit of everyone. One problem is I had to make changes outside just the Mac drivers, to many tiny root parts of SDL itself, so getting them accepted may not be simple. The SDL maintainers may want us to "prove ourselves", that we are serious, and our changes deserve including. But I think we are VERY CLOSE to being ready! Having Jatoba rebuild and do LOTS of fixes with SDL-1.2-main sources was key...very important that we both are now equal as far as "the cutting edge" (aka "unstable"), which will help show we're serious about the code. And THEN after we get the main SDL changes accepted...we'll want to get the changes to all the add-ons accepted too, so a lot of work ahead, if we really want this...unfortunately dealing with humans and not code! You can see why we haven't done so yet... ---- I've added README.mac.txt files to all my game ports, the working ones and the stalled ones. They have notes on the changes I had to make to get them working, issues, and any remaining problems building them. I'll be creating new .sit files for the working ones and putting them up on MG soon. ---- I'm now building them all on both Linux and Mac...this is really good for bug finding, and makes the code cleaner and look more "professional" and useful. So the MG uploads will build on both platforms. Most of the games build and run fine, although I had to put #ifdef's around some of my Mac specific changes. A few I can't quite get building, or don't run correctly. These are probably due to me not getting ALL of the Mac changes #ifdef'd, but could also be that the game source I used in all cases were very old, so may not work on modern Linux. ---- I'm going to be trying Amiga/AROS/Morphos builds soon. So use the same source code for as many platforms as possible. Because this is what SDL was designed for, it should go relatively well...although, of course, I expect to run into all sorts of little issues...but fixing THOSE helps the code in general so even benefits the Mac versions. If they build and run on Linux, Mac 7/8/9, and Amiga, little-endian/big-endian, 32-bit/64-bit, three different CPU architectures, then they'll probably build just about everywhere SDL 1.2 exists. (Atari, Knezzen?!?)
Last Edit: March 09, 2025, 19:52 by lauland
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #104 on: March 12, 2025, 15:17
|
The AROS (aka Amiga) builds went really well, several of the games built and ran with minor fixes, mostly adding libs to their Makefiles. A couple couldn't build because they used cmake, which I didn't have on AROS. Going to be trying actual m68k Amiga builds next...need to set up the compiler, etc. Will probably have trouble actually RUNNING them, as they will require a video card, (chunky pixels, 24 bits, etc.) ---- One interesting thing about the libs and Makefiles, which involved the SDL "add ons". We've already seen this with our classic Mac SDL_ttf, where I had to build FreeType as a separate step...it could be used without SDL_ttf, and we could distribute it separately. So the same thing for a BUNCH of other libs, such as libpng, libjpeg, ogg vorbis, etc etc...I built all of those "into" SDL_image and SDL_mixer inside their .LIB files...but we could pull them out and people could use them for whatever they liked...ie we already have classic macos ports as a side effect. We MIGHT consider pulling all the dependent libs out of the .LIB files anyway, since zlib is used by both SDL_image and SDL_ttf having it inside them both causes duplicate symbols. People using the add-ons would then have to include all the libs separately in their projects, but since this is how it would be done on other platforms like Amiga (and Atari, OS/2, etc) it might just be "more correct" anyway. On Linux this isn't needed because the dependent libs are all shared, so brought in automatically at runtime...I think the same thing would work on classic Mac if the add ons (and dependent libs) were all built shared. BTW the Amiga platform uses shared libs extensively, but they're hard to use, so usually developers just do things statically, which is how SDL and the add ons were done for AROS. ---- Got Abbaye des Morts running on Linux (and AROS) by doing an #ifdef __MWERKS__ to use datafiles with Unix linefeeds vs Mac ones. So now the source is fully portable. One VERY cool thing in building Abbaye on a 2024 Linux with modern gcc was it actually found a couple bugs in the code where sprintf was used on with strings that weren't large enough hold the result (the authors forgot to include room for the null terminator!). I don't think this'll help with the background music or the memory leak, as it would've just overwritten the stack by a byte in a couple places...but will check! More exciting is this might find the bug that's trashing the stack in SDL Scavenger! (So going to pour over the warnings when building it on Linux). I built the "stalled games" on Linux, and SDL-Ball and FreeDroidClassic both worked fine...but Berusky and Super Mario War both have problems with their data files...even on Linux! Not sure what is going on with Berusky, but it turns out the Super Mario War source I'm using is actually missing a bunch of music files. Going to hunt those down...they might've been removed for copyright reasons...
|
|
Pages: 1 ... 5 6 [7] 8
|
| |||||||||||||||
|
© 2021 System7Today.com. |
