|
|
|
|
| Welcome, Guest | Home | Search | Login | Register | |
| Author | SDL 1.2.x for M68k attempt... (Read 118264 times) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Jatoba
256 MB  Posts: 270 System 9 Newcomer! 
|
Reply #60 on: January 12, 2025, 16:25
Quote from: lauland 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 believe I figured out what is causing this: if the file you toss out is part of a different target, it will just "grow back" and "get rescued" once you close the project, then reopen it! In our case, this was happening with the CWP6 XML-based project with the BeOS "SDL_libso.c" file, because the Carbon targets were looking for it. Of course the Carbon targets will never need that, but when the file got originally "rescued", and we "OK"-ed it, the User Path included the file... for those targets, as well! And the configuration of those unwanted targets get in the way of OUR targets. Once you switch to the Carbon targets, toss them out from there again, then remove any reference to it in the Access Paths that might have been added by CW itself, you can go back to our real targets, and CW should not "bring it back from the dead" again. I assume the issue you had with the joystick file is likely related. --------- In case we or anyone else ever wants it, I also just added an unmodified 1.2.16 "runtime", "devel" and "source" downloads to the Garden page, just as had been done for 1.2.15 yesterday. Personally I will only ever care for your "SDL 1.2 unstable" download (plus all the add-ins), but thought I'd leave those other versions "sorted out" over there as well, for posterity, archival or whatever. Now I can also focus on the add-ins and your current work! I will try my best to see where I can do something while at the same time ensuring I don't get in the way of something you are already taking care of. --------- I will also give running SDL as a system-wide Extension a try (and not forget to reboot), it might just work as you say, rather than requiring the presence of SDL in each SDL app folder individually. I doubt the SDL team would overlook something this basic. I will confirm it in a bit. --------- About finding SDL app candidates for porting/testing... I guess it doesn't hurt to bring up, just because, a few examples that...... prooooobably are not so trivial, but I'll mention them just in case... ... what about Basilisk ][ and SheepShaver? They use SDL. Originally SDL 1.2, but eventually switched to SDL 2.0 (meaning they could also be used for testing your current SDL 2.0 development? Two birds in one stone?) IIRC "Adespoton" in the Garden told me that SheepShaver version 2.3 uses SDL 1.2, whereas 2.4 uses SDL 2.0. What I don't know, however, is if they have other dependencies that are in our way. But considering they are multi-platform projects, hopefully SDL is all it relies on...? I also don't know which, if any, of the SDL add-ons are used. But there's a chance they might be there. I will look. --------- Other potential SDL app porting/testing candidates might be: SDL Music Demo: Supposedly good to port/test SDL with, and supposedly comes with source? Problem is, it might be SDL 2.0 instead of 1.2. Also wonder which add-ons, if any, are being used. I will try downloading and checking it. C-Dogs SDL - Will also check this one for the same points mentioned above. Homeworld SDL - Same. Yabause - Same. Likely a tough project to port at all, though. Mednafen - Same. Also probably even tougher. It supports NetPlay, and, just maybe, it might use SDL_net for that? (Personally love this multi-system emulator, might be my favorite emulator overall for its accuracy and features. But that is not important right now.) I will keep looking and trying to see which ones have the characteristics we want to test for: SDL_image, SDL_mixer, SDL 1.2 etc.. --------- On a side note, it might be awesome, or just interesting, to toggle on compilation for AltiVec and G4 processors in the CW project settings. It's something I will keep in mind if we find some "heavy" SDL game, emulator or other software that is otherwise heavy even on a high-speed G4 like the ones in the Mac minis. But if we find a candidate like that, then it can be considered. Meaning not now. Let's see what we find. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #61 on: January 12, 2025, 16:43
|
The following should make use of SDL_image and SDL (not sure if 1.2): Freedroid Classic Freedroid RPG (looks fun) Free Pascal 2.0.4 - Probably not a good candidate for various reasons, but also because you already went through it.
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #62 on: January 12, 2025, 18:04
|
How people reading this that don't even know what SDL is can help If you guys know of any games/apps that use SDL (version 1 only) that you'd like to see ported to MacOS 7/8/9, we're looking for candidates to at least take a stab at. So far we've got two games working and up at MG (Breaker and SDL Scavenger), and we have a color version of MvM. Games that require OpenGL, or are moving around lots of pixels, will only run well (or at all) on PPC, but the M68k port is bearing fruit, as well. (In Basilisk, on fast hosts, quite usable). In the very least, we're revitalizing SDL on Classic MacOS, fixing bugs, and adding missing bits. One can imagine, maybe someday, a parallel effort to http://macintoshgarden.org/forum/custom-software-builds-os-x-leopard-32bit It's important to stress the difference between SDL 1.2 and SDL2. Many more modern games will be using SDL2 and there is no Classic Mac support for it, in any way. So don't get your hopes too high if you see something you'd like us to try porting. The SDL2 I've been working on is purely experimental, and it is unlikely I will be able to finish it by myself. (More in separate post). ---- Scummvm Ah! Some of my fondest memories are playing all those old LucasArts games. There's no "official" MacOS 9 version, and the ones we have are quite old. I took a quick look at the source, and at least the older branches still use SDL 1, but required add-ons like SDL_mixer and SDL_image. Now that I've made SOME progress on those, I'll take a fresh look. The source is surprisingly HUGE and quite confusing to read. ---- Port candidates I'm already looking at Freedroid Classic but it does the same thing "abbaye-des-morts" does with defining "const" structs like this, which CodeWarrior can't handle: influence_t Me = { .type = DRUID001, .status = TRANSFERMODE, .pos = {120, 48}, .health = 100, .energy = 100 }; (Going to try re-writing these if I can). FreeDroid RPG uses some of the same code, but is vastly larger. I saw some references to SDL2 in the Makefiles and comments and so didn't consider it, but taking a fresh look, it seems maybe it DOES use SDL1. Either way...will look into getting FreeDroid Classic working first... FreePascal in theory is already done... at least for an old version of the interfaces, not fully compatible with the official SDL support that comes with real FreePascal releases. It builds at least...but I haven't tested it. If I can find a simple SDL test in (Free)Pascal I could. "Rescued items" I think you're spot on with the explanation! That totally explains what I was seeing with libso and the joystick support. We might think about removing the Carbon targets, at least from our CW projects, to avoid not just this, but other complications (and goofy warnings). Tangentially related, at least as far as CodeWarrior "finding things": When working on SDL_mixer, et al, it turned out it was "finding" some "missing" include files (that CodeWarrior doesn't have) in some of the Amiga, Windows and/or OS2 build/support folders (and more). This was really throwing me for a loop. I tossed the folders, but zipping them will help the same way. "devel" and "unstable" I think the way to proceed is "unstable" should be bleeding edge 1.2.16, and includes all our crazy new work, and everything else at the MG page are "official" copies, at least as far close as they can be. So a 1.2.15 devel could be used by someone just wanting to use the latest official stable version. This is basically what we have now. add-ons What you can do, that will really help, is try the MPW builds, see how/if they work. I've been meaning to try, but some look broken...for example, SDL_ttf's MPW Makefile has the wrong version number for the freetype folder, so right off the bat it won't work. More candidates Won't hurt to take a look at SheepShaver and Basilisk, but will personally save for later...concentrating on MvM and others we know use SDL1. And it's a given they use the add-ons which are in very unstable progress. Also, they're much bigger and complex than games, etc etc etc. C-Dogs and the Music demo are both SDL2...willing to bet HomeWorld is too. Haven't looked at Yabause or Mednafen, but will... Been avoiding looking at emulators, as I said, they can be complex and pretty much all need the add-ons... I'll write an update about SDL2 in a separate post... G4 Altivec and other optimizations Definitely should try! I don't know how much Altivec will help...there might already be some support in the code for other platforms. And just turning on "optimization" period in CodeWarrior will be something to try...again. I think the problems I ran into before were just me getting confused. ---- SDL Scavenger and keysym unicode/sym It turned out the crashes on M68k were due to me doing a debug fprintf of an uninitialized string!!! Once I removed that, while fixing the "finding the data in a folder" thing, it started working fine! It pushes a LOT less pixels than Breaker (and doesn't do palette animation maybe?) and I think the M68k version will actually run well...going to test on real hardware and upload to MG. I'm getting close to figuring out the unicode vs sym thing. The reason that keys weren't working on M68k Scavenger was the bug was NOT happening...so the unicode field was always zero, but sym was valid! Anyway more as I figure that out...
Last Edit: January 12, 2025, 18:52 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #63 on: January 12, 2025, 19:02
|
Btw, I was going over the 68k "unstable" project (most recent version in the Garden), and noticed the pesky "BeOS" version of loadso in there. I got curious, and tried to compile it anyway: it compiles without errors! So I wonder if it went unnoticed? I wonder if this in any way caused you some of the issues you were having during runtime? Other than that, everything compiles in it for me: MPW, MPW optimized, CWP6 PPC, CWP6 68k etc.... I figure that if there are any new .c files, the MPW "make" file would have to be updated to compile and link them, as well. I haven't checked yet this source closely enough to see if there's any need for that or not, yet. Besides, our focus for now is via CW anyway, and on the static libs, rather than shared, and on actually getting things done (68k, 256 colors, drag'n'drop on window etc.... maybe Multiprocessing-Services-based multithreading, as well?) I will now go through the add-ins to get myself familiarized with them, as well. This is so much work done so quickly and well! Going through these is like surfing through a wealth of knowledge for me! Incredibly educational. Quote from: lauland add-ons What you can do, that will really help, is try the MPW builds, see how/if they work. I've been meaning to try, but some look broken...for example, SDL_ttf's MPW Makefile has the wrong version number for the freetype folder, so right off the bat it won't work. Got it, will gladly do that. Been poking at the SDL MPW makefile anyway, so this is perfect timing for me. I'll go hunt those add-ons from an MPW angle rather than a CW one.
|
cballero
|
1024 MB Posts: 1176 System 7, today and forever
Reply #64 on: January 13, 2025, 01:49
|
@lauland: what era and/or OSes would the SDL games, programs, emulators, etc. need to be from? this will give me and I’m sure others an idea of what to ask for  I assume you’re looking for Open Source apps, but maybe not? If not, would Windows 95 programs qualify, or am I completely off base? I just want to make sure I understand the ask before I make any suggestions  a newer or better MAME emulator would be fun to get (well, for 68k?)
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #65 on: January 13, 2025, 03:59
|
Absolutely excellent questions @cballero! SDL is basically similar to (but is definitely NOT) DirectX, in that it is a collection of libraries to make writing games and other multimedia apps easier. But unlike DirectX, it is cross platform, and there are versions for just about every system you can think of. (Of wildly varying quality). So if you write a program using SDL, you can (in theory at least) run on any system that has a version of SDL for it. It is extremely common to see it used so a game can run on both Windows, Linux and MacOS X, for example. Since we have SDL for Classic MacOS, there are potentially many games/apps that use SDL 1.2 that we can port, that nobody has bothered to do before. https://en.wikipedia.org/wiki/Simple_DirectMedia_Layer (modern browser required  )---- What we are talking about here is SDL version 1.2, so we are looking for apps/games that use that version. SDL2 is much more modern, but there is no Classic MacOS support for it. Unfortunately this rules out a LOT of games that I'm sure people would be interested in. It is not very easy at all to tell which version of SDL a program uses, unless they clearly state it. The only way then is to look at the source code itself, searching for the "SDL2" string.
Last Edit: January 13, 2025, 04:02 by lauland
|
cballero
|
1024 MB Posts: 1176 System 7, today and forever
Reply #66 on: January 13, 2025, 17:11
|
I see! It’s been used mostly for games; Android has an (outdated) SDL-run Basilisk II emulator that I use (thankfully I archived it at the Garden before it was pulled from the Play Store late last year) so that threw me off a bit Here’s an IA link to the list of SDL games I think? I don’t really know many of these I guess because a lot of them don’t appear to be mainstream titles (at least to me, lol)
Last Edit: January 13, 2025, 17:14 by cballero
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #67 on: January 13, 2025, 17:24
|
I think that link is a mirror/grab of the previous contents of the same page on the official SDL site...BUT...it is probably more useful because it is from 2010, before SDL2 came out! So everything listed there is probably using SDL 1.2, and so good for us to look at. Great find! Take a look and let us know if there's any of those you'd like us to take a look at. ---- Another note: Similar to SDL, OpenGL is used by games for 3D graphics on every platform other than Windows (where Direct3D dominates). SDL itself doesn't do any 3D, and is strictly 2D, but works alongside OpenGL. Apple had a very good implementation on Classic MacOS for PPC Macs, that was able to do acceleration if you had a video card (or built in chips) that supported it. There was no OpenGL for m68k macs, other than a port of Mesa, which is software rendering only (no acceleration), and thus very very slow, not good enough for games. (I'm still looking into it, see other post).
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #68 on: January 15, 2025, 01:06
|
Well, I'm a bit frustrated... So I believe I've got SDL for m68k working, but don't actually have anything practical to show for it... Breaker and MvM seem perfectly stable, but are so incredibly slow they're useless other than "proof of concept". But it's "SDL Scavenger" that is really chapping my hide...when it does run, it runs VERY well...and fast...until it crashes horribly...even on real hardware, and even in 256 colors on Basilisk! (On real hardware 256 color mode works, but is pink on yellow background). The problem being it seems to take a random amount of time to crash, and while running everything, as far as debug printfs, looks just fine. When it does crash, the stack and heap are trashed as if it wrote all over memory...yet it is perfectly stable on PPC! I'm going to think on it, but debugging random corrupting crashes on M68k is quite a challenge! I don't want to go too far down a rabbit hole in code I didn't write... ---- So not sure next step. The most logical is probably to find a game that has just as modest graphic needs to prove that SDL on m68k can run fast enough to actually be useful for anything. Which really is a question. I think it might be, but don't have definitive proof...for example, SDL Scavenger's memory issues may, in fact, be due to some problem in SDL itself...getting it basically working on m68k may have been...too easy? Since it was ever only designed to run on PPC it might be doing something goofy that just isn't legit on m68k? (But if it were an SDL problem why are Breaker and MvM not crashing?) Hmm...maybe research the speed of SDL on other m68k plaforms like atari and amiga and see how fast they've gotten it to run? Just to make sure this won't ultimately be too slow to use.. Anyway, may just need to table m68k for a bit, and concentrate on PPC ports.
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #69 on: January 16, 2025, 07:16
|
Coming soon... http://revontulet.org/2025/01/16/1112b211af3e483ab2646109a491bd90.png
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #70 on: January 16, 2025, 08:36
|
Nice! Another SDL port! And this time both PPC and 68k? Goes to show your 68k SDL port already bore a full fruit! By the way, I thought I might just mention this, I'm thinking of creating small, separate MG pages for the various SDL 1.2 add-ons (both 1st party and 3rd party, the former being AFAIK also officially documented in SDL manuals), and keeping links to them in the main SDL page. It should free up some space in the page while allowing for separate analysis/discussions/work/downloads for any of the given add-ons. If there are no objections, I'll go ahead with it? By the way, is SDL_rotozoom the one included in the overall 3rd party SDL_gfx project from here? (Note: SDL_gfx is SDL 1.2-only! Good to see 1.2 still getting love out there!)
|
cballero
|
1024 MB Posts: 1176 System 7, today and forever
Reply #71 on: January 16, 2025, 08:39
|
Wow! 
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #72 on: January 16, 2025, 15:35
|
Sub pages for SDL_image, SDL_mixer, etc: Sounds like probably a good idea. Might be too early though...they're still in such rough shape that I don't know if they merit their own pages...but at the same time...they are brand new projects and not part of SDL itself, so separate pages do make sense. SDL_rotozoom: Two of the games I'm working on ports for, but are stuck with CW issues, required it. I'll find the page where I grabbed it from...it looked separate to me at the time. I didn't know it might be part of SDL_gfx! Is that for SDL1 or SDL2? Maybe it was a separate thing, but got merged into SDL2's SDL_gfx? Anyway...I'll get you the original page and you can take a look. SDLRoids: I was looking for a game that'd run well on M68k, so I looked at YouTube videos of people playing SDL games on Atari and Amigas, knowing at least the cpu would be in a similar range. This one was simple graphically enough that it looked like a good candidate, and turned out that was the case. It plays perfectly on my Performa 630. The good news is it is rock solid, I left it running for several hours with no crashes. Making it more likely the problem with SDL Scavenger is in the game itself, and not SDL...maybe... I'm waiting to release it on MG because it still needs a little work. On a 640x480 screen the top of the window, where scores are shown, is cut off, so I want to fix that...since I can only run it in 640x480 mode on my Performa! (Since SDL still requires "Thousands of colors" at least). I also want to get sound going for the PPC version (sound is still crashing for M68k SDL). I think it is trying to play WAV files. I don't know, but believe, this is a limitation in SDL_mixer I haven't gotten working yet.
Last Edit: January 16, 2025, 15:37 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #73 on: January 19, 2025, 12:16
|
Yes, that SDL_gfx repo is exclusive to SDL 1.2! Also, quick update, I made a tiny miscalculation with major gallstone consequences, so I have been invalid 100% the past 3 days, not counting today. I didn't want to leave you or anyone else "left in the dark", so I'm saying this here. I will continue with SDL near the upcoming weekend, though, as I am on my way to a speedy recovery and will watch out better here on out, and IMHO no one needs to be concerned.
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #74 on: January 19, 2025, 17:41
|
From what I can tell, it looks like "rotozoom" came first, everyone loved it, and then it then grew into SDL_gfx. So I'll add SDL_gfx to the "list of add ons to work on", but haven't found any games that specifically need it. I'm going to get back on SDL_mixer and SDL_image and try getting more file formats working in them this weekend. Also going to take a fresh stab at SDL_ttf, ran into a lot of problems with "freetype", which is uses. Also take an SDL_net first look. ---- I heard through @Knezzen about the "fun" you've been having, so sorry to hear it! I've been there with same thing myself. If it ever comes down to it, get that sucker out if you can. I'm 10 years on with no gallbladder and have had zero problems. (They actually used a robot to get it out, or so they tell me, I was zonked in a pink cloud in the ER). Am sending good thoughts... ---- The MG SDL page is looking awesome, great work! You've turned a mess into something actually readable and usable, really. I was about to type "simply smashing", but am very much not British, although have realized my turns of phrase may give that impression. I work in Education with lots of international students and their patterns have rubbed off. ---- Was thinking we should split this thread into separate PPC and M68k. Just because the M68k work will never be as good or useful as the PPC stuff. For PPC we may improve experience in actual "semi-modern" 3d games, which people may be more interested in. The M68k stuff will always trail, be 2D, and be a personal passion project.
Last Edit: January 19, 2025, 17:54 by lauland
|
|
Pages: 1 ... 3 4 [5] 6 7 8
|
| |||||||||||||||
|
© 2021 System7Today.com. |
