|
|
|
|
| Welcome, Guest | Home | Search | Login | Register | |
| Author | SDL 1.2.x for M68k attempt... (Read 118265 times) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
lauland
512 MB  Posts: 674 Symtes 7 Mewconer! 
|
Reply #75 on: January 21, 2025, 02:41
@Jatoba, added SDL_net build to the SDL page. It builds, but I don't understand fully how to build apps that use GUSI, so don't know what to include in project files to get them to link, ie it complains about not being able to find a couple GUSI functions. I'm working on SDL_ttf and expect SOMETHING ready for the world in the coming week(s). Because of this, if you wanted, you should feel free to move all the "add-ons" to a their own new MG page, to keep the SDL page itself manageable. I'm thinking a single new "SDL 1.2 add-ons" page for all of them together? If you're not feeling up to it and/or just want me to do it, let me know, but I figured I'd give you the honor! (Especially since you've done such an awesome job with the SDL page). ---- GUSI stands for "Grand Unified Sockets Interface". It is a library/project that provides a Classic Mac implementation of the standard "Berkley Sockets" API, which is extremely standard/useful/popular for writing software that uses the Internet or just networking in general. Unfortunately, it ALSO tries to "fill in the blanks" and provides many, sometimes not directly network related, headers and functions that either Classic MacOS or compiler standard libraries are missing. So it is a lot larger than you might expect. It can conflict with parts of the compiler libraries and so is also harder to use than you might expect...at least for me! I used it when I built the unreleased Jabbernaut 0.6 beta, so will be looking back at how I did that, which should help getting SDL_net done. http://macintoshgarden.org/apps/jabbernaut https://sourceforge.net/projects/gusi/ https://en.wikipedia.org/wiki/Berkeley_sockets (modern browser) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Last Edit: January 21, 2025, 16:23 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #76 on: January 21, 2025, 18:31
|
@lauland Yeah, I'd love to work on a page for the add-ons. I actually started it today (at 3% of my usual speed), but noticed that, while it'd be very convenient to have them all together in one place, I don't think it will scale very well: each add-on might have 5 or more downloads, and there's quite a number of "official" ones. If we count other popular, "3rd party" ones, then it gets even bigger. It might also work out better to have page comments addressing each add-on separately, as some of the "big" ones like SDL_mixer and SDL_image have some dependencies that may warrant lengthy discussions or Q&As by and for other readers. What do you think? Would that work out fine for you, or would you still prefer them all in a single space?
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #77 on: January 21, 2025, 19:43
|
Basically whatever you think best is fine with me. You're a good organizer. Your editing skills at 3% are probably superior to mine at 100%! I have no idea how many files each add-on will individually end up having...right now, until things are stable, just one each? Or maybe two...one of the original stock source version from the SDL site, and then my unstable version that has been patched and actually builds? Still that wouldn't be too many for all on a single page...like we have "4 add ons" at present, so that'd only be 8 total links if we had two for each, all on a single page, right? I do think a separate page for each add-on might be a bit much, as they could be very sparse, and if you want one, you usually want them all! (So easier for anybody who actually wanted them). And we'd want to either have links back to all others on each, or at very least SDL itself on each...I have no idea. Like I said, I think you've got the skills, and whatever you decide will be fine. But...VERY good points about comments discussions and q&a's...although that might be wishful thinking until anyone actually gives us feedback, eh? If you think each add on needs enough space to explain it well enough, what it is, how to use it, caveats, etc, then that makes sense. My only real concern is us having to maintain too many multiple pages. In the end, if it doesn't "look good" first try, you can just reorganize again, right? (Got a new version of SDL_net just now to upload!)
Last Edit: January 21, 2025, 19:56 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #78 on: January 26, 2025, 20:50
|
I finally put together the SDL 1.2 Add-On Libraries page. It's in a state to get things off the ground: I will polish it over the week (or next weekend). @lauland It does not yet contain your uploads found in the main SDL page, but I will migrate them over (with the version date string and everything) as soon as I can, also during this week. I believe every add-on is addressed in the page. To be more exact: - All 1st party ones (SDL_mixer, SDL_image, SDL_net, SDL_ttf, SDL_rtf, GUIlib) - All "2nd party" ones (SDL_Cbs - it is made by a 3rd party, but hosted in libsdl.org) - All 3rd party ones that seem to be popular/impactful/known out there (SDL_gfx, SDL_Collide) Anyway, I will work on the Color MvM page next.
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #79 on: January 27, 2025, 01:44
|
Yowza! Amazing amount of work for amazing results! I had no idea how thorough or complete it'd end up...but really should have guessed, from how clear and organized a job (and no mistake, this was a lot of work!) you did, with the the main SDL page! I now FULLY understand why you'd previously wanted to have a separate page for each. I had no idea there'd end so many links! Was cluelsss that there'd be more than just one or two for each add-on, and thought there'd only be about six (maybe total!) different add-ons, so envisioned a page with about half as much content. But when you include versions, and dev vs end user, actually explain things, etc, it REALLY adds up. Just adding my versions will take the number of links to 35 (at least and more coming!). So if you end up breaking this into a page per add0-on one day, I will not be surprised in the least. I have been working on SDL_ttf quite a bit, but stymied by a link error. it builds but has duplicate symbols, as they are doing tricks (slash slightly over the top goofy things IMHO) with "extern". And now there are even more add-ons I hadn't even heard of! Building alone is a bit of pain as there is a header conflict between zlib and freetype libs it uses, so they are built separately...definitely not ready for the public yet. And still having conflicts between GUSI and MSL in SDL_net...it builds, links and is safe, but I don't think it is actually "working". ---- Went back and worked on the several different game ports I have in the pipeline. By cheating, and commenting out some struct init's using a C language feature that CodeWarrior doesn't support, "abbaye-des-morts-master" and "FreedroidClassic" now would at least build, once I fix SDL_ttf...so those are looking likely. Got "Snoopy vs the Red Baron" (aka "Generic White Dog vs. the Red Baron" for copyright purposes) working on PPC and uploaded to MG. Found you MUST have the exact same (or at least extremely close) compiler language and processor settings for the app and the libs it uses...we'll discuss this later as we should note it on the MG pages. Anyway, I had the wrong struct align for Snoopy compared with SDL_image. http://macintoshgarden.org/games/snoopy-vs-the-red-baron-2001 There is some weird bug in TGA file loading for M68k in SDL_image that causes the moving objects in the game to be corrupted (split in two with left and right halves in wrong places?), but it otherwise builds and is quite playable...ie runs well on real hardware! This bodes very well for M68k SDL's future... Even stranger...while trying to fix this bug in SDL_image, I found a separate but different bug, again in TGA loading. Have been using "68k 4-byte" for "Struct Alignment", but "sizeof" a particular structure was ending up getting calc'd incorrectly, with extra padding compared to the PowerPC. Will probably switch to "PowerPC" struct align for m68k...but will also try "68k 2-byte" and see if the padding is correct then... Regardless, this points to places where things will end up building differently for the two architectures...with the PowerPC version being correct, and possibly causing all sorts of little hard to detect bugs on the m68k...so a head scratcher definitely. ---- When I went back to "SDL Scavenger" and made sure I had it's language and processor CodeWarrior settings exactly the same as SDL's, the m68k version now no longer crashes after a few minutes and now is fully playable...but only when run on PowerPC under emulation! On Basilisk and real hardware it crashes RIGHT at launch! So lots of food for thought and things I have to look into for the m68k world...I'm betting "Struct Alignment" is a key...
Last Edit: January 27, 2025, 01:48 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #80 on: January 27, 2025, 19:56
|
@lauland Those PPC vs. 68k issues are very educational to read about, it keeps me on the edge of my seat, in a strange way! I feel like you are uncovering some REALLY helpful ground there not just for SDL, but for general PPC vs. 68k C compilation! Am definitely taking notes here and curious to see where this will lead to. Incidentally, I just gave the add-ons page a nice, good polish and an extra oomph. One-liner descriptions per plug-in in italic, it seems like a tiny unimportant thing, but it is something that enhances the page by a lot. I used your texts to describe the add-ons you provided a description for in the main SDL page, and added others for the remaining add-ons. I also finally uploaded your 4 .SIT files of the add-ons. I assume you took the latest source from GitHub SDL 1.2 branch for SDL_mixer, SDL_image and SDL_net (and SDL_ttf), and the latest version 2.0.27 from somewhere (SourceForge?) for SDL_gfx, and so I placed your downloads accordingly directly under each "version subsection" in the page. I also found another 3rd party add-on along the way.... Not sure if any games or SDL software uses it, but it's called SDL_svg. I thought SDL_image could handle SVG, but I guess not. It has, or used to have, a dependency on SDL_gfx. And "libsvg", which I'm unable to locate, although I think it's included with the latest source, alongside with the "rendering engine from freetype", whatever that is. It seems like the project switched hands at some point, but the new versions were still made available on the older SourceForge place, if I understood things right, except for the very latest version, 1.2.0, only found here, except that version wasn't archived, so it seems sadly lost. SourceForge is stuck with only 1.1.9 at latest. The project seemed to have overall halted in 2005, but that 1.2.0 update was a sneaky 2008 upload apparently, and sadly wasn't mirrored... https://sourceforge.net/projects/sdlsvg/ https://sdlsvg.sourceforge.net/ http://web.archive.org/web/20190725032140/http://www.linuxmotors.com/SDL_svg/ Edit: Oh, nevermind! SDL_svg 1.2.0 is there! The website owner just updated the address with an additional "/linux" to the URL, so the following links work: http://www.linuxmotors.com/linux/SDL_svg/ http://www.linuxmotors.com/linux/SDL_svg/download/ http://www.linuxmotors.com/linux/SDL_svg/download/SDL_svg-1.2.0.tar.gz Also there's this GitHub repo, seems to have version 1.2.0 code. The README below is informative to read regarding the project. https://github.com/NakedMoleRatScientist/SDL_svg Not sure if the GitHub repo is by the then-new author himself (Dave Ashley), or someone else's. Edit 2: Added SDL_svg to the MG page and further improved the page overall.
Last Edit: January 27, 2025, 21:06 by Jatoba
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #81 on: January 27, 2025, 21:03
|
Awesome job! ("Simply smashing!") You're totally right ("spot on") about the italics. They jump out of the paragraphs, draw your eyes to them, and explain RIGHT there why you might or might not want each particular add-on. Really nice to have that page! I built my versions on github links you gave me way back, I assume they are the latest...I used the exact links you sent, whatever they were. At some point I'll make sure I WAS using the latest ones. There was a LOT of patching needed, and I'd need to redo it. I think viewing "Differences..." in BBEdit will show me exactly the changes, and if I'm lucky, they already were the latest versions. Positive that SDL_image doesn't include svg, as I didn't see it while hacking...so that is a separate add-on. Everyone thought that SVG would be THE image format everyone would go to, but it didn't end up killing off the others. Still VERY popular with web devs of course. It is vector based, not pixels, hence it needs SDL_gfx to draw things, and isn't in SDL_image which are all, as far as I can tell, pixel based and none of them vector...? If it needs freetype, SDL_ttf (obviously) also needs it so I'm already working on it. I figured out the problem, and will let you know more once I've fixed it. (They #include .c files!) ---- Yeah, we'll have to include a note about making sure "Language" and "Processor" settings are the same in SDL, all the add-ons you use, and whatever game/app you are building. If they are not, structs will have different sizes and things can break badly (like Snoopy did at first). Even something as simple as "enums always int" turns out to be VERY IMPORTANT.
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #82 on: January 27, 2025, 21:24
|
Quote from: lauland I built my versions on github links you gave me way back, I assume they are the latest... Perfect, then they are most likely the latest. Since the time you downloaded them, there might have been (or not, as it was around the same time you got them) a few "unimportant" (to us on the Mac side) patches the SDL guys made to SDL_mixer (here) and SDL_image (here), on the 9th and 10th of January 2025 respectively. And also one for SDL_rtf on the 7th of January 2025 (here). But none for the others (SDL_net, SDL_ttf, GUIlib nor any of the 3rd party ones). While looking around SourceForge to see if there's any other SDL add-on that could have been adopted out there, the only other one I found is SDL_draw. Seems like SDL_gfx, but for basic 2D drawing only? Seems to also be a very old add-on, from 2002-ish, last updated in 2008 with version 1.2.13. https://sdl-draw.sourceforge.net/ https://sourceforge.net/projects/sdl-draw/files/SDL_draw/ They mention some games and stuff that used it, in that 1st URL. Must be simple SDL games? I will get around to adding that one to the page, as well. After this, I don't think there's any other worthwhile add-ons out there (are there?), so I think I scraped off the bottom of the barrel with that one. At most I see SAgl which claims "can be used on top of SDL". Beyond that, I only see libs for OpenGL (1.1+), or for things completely unrelated... So I think I will go spend time with the SDL add-ons that we do have instead, and focus on them, plus porting SDL software that uses them.
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #83 on: January 28, 2025, 09:25
|
Quote from: Jatoba Perfect, then they are most likely the latest. Since the time you downloaded them, there might have been (or not, as it was around the same time you got them) a few "unimportant" (to us on the Mac side) patches the SDL guys made to SDL_mixer (here) and SDL_image (here), on the 9th and 10th of January 2025 respectively. And also one for SDL_rtf on the 7th of January 2025 (here). But none for the others (SDL_net, SDL_ttf, GUIlib nor any of the 3rd party ones). I forgot to mention SDL_gfx. I originally shared the official GitHub repo, as back then I knew no better, however the author explicitly says it might not be up-to-date compared to the latest release from his website (and the identical SourceForge-hosted one), or even the latest SourceForge-hosted codebase. To avoid future confusion, I wrote about it in the MG add-ons page. So, that one might be worth double-checking, at least more so than SDL_mixer/SDL_image/SDL_rtf. Edit: The main SDL page has been updated to point to the add-ons page for the add-on downloads and info. I confirmed the checksums for all 4 files match 100% on both pages, and so I finally "deleted" them from the main SDL page. (The files never truly get deleted in the Garden, rather it's more like the download URLs aren't immediately visible.) I also gave the add-ons page a little visual touch, it was looking "very lonely" without any pictures or screenshots while having 36 downloads separating the page title from the description. Now it looks nice. 
Last Edit: January 28, 2025, 10:10 by Jatoba
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #84 on: January 28, 2025, 15:24
|
You are correct! I did indeed use the github repo version for SDL_gfx! I haven't done an m68k port of it yet, so when I do that I'll move to the same "latest" kind of latest version as the other add-ons. The pages look amazing! Screenshot #5 on the main SDL page is actually of my SDL_gfx, so doesn't belong there anymore. You already have an extremely similar one on the add-ons page, so can just delete it if you want. Got SDL_ttf working. The build process is goofy because some header (or two) in zlib conflicts with FreeType, so they have the be built in separate projects (can't live in the same tree). I haven't hunted down which one, and aren't sure it's worth the trouble just to have the build process cleaner since it works. As a side effect, you can build, and use, FreeType completely separately from SDL_ttf, which might actually be a useful thing? Maybe it deserves its own page...I'd definitely not want to break it out on the add-ons page since that'd just make even more links. Maybe this points that SDL_ttf would be the first one to go on a page by itself? Similar thing in that zlib is duplicated in both SDL_ttf and...erm...can't remember either SDL_image or SDL_mixer...or both?!? Either way, if you link a game that uses both, you get duplicate symbol warnings....not errors, and it works, it just only uses one copy for both? (I think?) So maybe break zlib out too?!? But that's a little nuts. ---- So with SDL_ttf now working I took another stab at "L'Abbaye des Morts" and made a lot of progress. Actually adding some alt code for a couple bits CW just can't understand. Screenshot #5 on its page is actually a tease of my MacOS 9 port. Unfortunately it crashes right when the game starts, but does show the title and "intro" and plays music and you can switch graphic sets (between "classic Spectrum" and "16 bit look"). So it proves SDL_mixer, SDL_image and SDL_ttf are all working well! http://macintoshgarden.org/games/labbaye-des-morts Was hopeful the "struct alignment" confusion was the problem with getting audio not to crash in SDL (itself, not SDL_mixer) for m68k, but no dice...tried with all three settings and still crashes. Oh well...more sleuthing soon. I think I figured out the keysym.sym vs unicode thing! Pretty sure it depends on if you have "enums always int" turned on or not. I'm still figuring out which is the correct one, and will let you know and make a note someplace about it. I'll explain more once I'm totally clear on what is going on.
Last Edit: January 28, 2025, 15:27 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #85 on: January 28, 2025, 17:04
|
@lauland I like your SDL_gfx screenshot, because it reveals that it is working on Mac OS! I moved it to the add-ons page, it complements the other SDL_gfx screenshot IMO, so I'm keeping both. ---- I gotta admit, I might be "overdoing it" with the add-ons page: while I personally don't mind it that way, it got big. Especially since I just couldn't leave the less-important 3rd party add-ons behind... I might do something about it, such as make another page just for the "3rd party add-ons", if you think that would work out. You also made a very good point about SDL_ttf + FreeType. And zlib + SDL_mixer/image/ttf. Although I think SDL_ttf should come bundled with it (even if it has to be built separately), it might be best to also give FreeType its own individual page. I was planning to do just that for GUSI, as well: it's used in SDL_net, but it's also used in MacPython and even in something like the MPW version of Crypto Ancienne, and in lots of other Mac projects. In that sense, a separate zlib page might not be so bad? Also, like you mentioned, SDL_svg can apparently use SDL_ttf's FreeType. Well, regardless of how we will sort it out, we can also worry about it later, and just move forward in whatever way we feel comfortable. We can always "clean the house" at any later point in time. ---- I somehow am quite looking forward to seeing ""L'Abbaye des Morts" on Mac OS 9, it looks quite fun! Would love to try it! A 2010 Mac OS game running with SDL, SDL_mixer, SDL_image and SDL_ttf?! Wow! I hope you are able to figure out the cause for that crash! I'm also with my jaw dropped at the "keysym.sym vs. unicode" thing we saw since way back, and your guess explains why sometimes a game/app needed one or the other. Wow. To think you cam this far! And I'm glad to have stuck around long enough to see the answer to that! So educational. The longer all this goes on, the more confident I feel about coding Mac things and beyond. The journey of sorting out all this stuff that we are is, too, in and of itself the reward. Worth the walk! I will be glad to listen to further explanations about it anytime.
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #86 on: January 28, 2025, 21:12
|
Just added my SDL_ttf build to the add-ons page. I just put it at the bottom of the uploads as didn't want to step on your toes in case you were working on page at same time. Feel free to move it to where you think it best belongs. The description can be anything like: ""@lauland's Mac port with source and binaries. NOTE: Must build FreeType (included) separately, first." (or whatever words to that effect) I put a readme in it that says the same thing with a little more explanation about the conflicting headers. Also, tiny correction for SDL_net...when you get a chance, change the text that says: "Provides a simple interface for doing TCP/IP. Uses and includes GUSI." to "Provides a simple interface for doing TCP/IP. Use with Classic MacOS requires the GUSI library." (Or anything like that, feel free to use your own words) ie you must include GUSI in your projects if you use SDL_net on Classic MacOS (but not other platforms, even MacOS X). GUSI is not otherwise included or a part of SDL_net in any way. My .sit file DOES include a built copy of GUSI, so you can change the text that says: "@lauland's Mac port with source and binaries." to "@lauland's Mac port with source and binaries, includes built copy of GUSI." (or again, whatever in your own words) FYI The GUSI I included was the same one I built for Jabbernaut, so I know it works. The trick is getting it to not conflict with MSL, and I think certain versions of CodeWarrior get along better than others. Jabbernaut didn't use much of MSL's "standard io" functions, but our SDL does, which I think is the problem. (GUSI overrides or somehow supplements some of them).
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #87 on: January 28, 2025, 21:45
|
@lauland Done! SDL_net description fixed, and entry added for your SDL_ttf. Awesome to finally have it in there! It seems SDL_ttf is really important for a lot of SDL software. From what I was seeing, before it took off, SDL adopters used something called BFont, or more rarely SFont. I can't find the original BFont, but someone "continued" it and made a page for said continuation here (dubbed "BFont v.MN"). It could be something we see being referenced for some older SDL games. Also, I went completely ham on the 3rd party libraries and added the briefest-possible entries in the add-ons page for SDL_draw, SDL_Resize, SDL_stretch, SAgl, SDL_Config, aedGUI, SDL Console and SDL_Terminal. Among these, only SDL_draw and SDL_stretch seem popular, based on recent SourceForge download count, and open tickets. We may never need them, but in case we do... we won't need to look for/research/locate them anymore, as that work is now done. EDIT: Found BFont, in an old version of the source included with a game with a title as generic as "asteroids". Had to do some Italian archive.org digging with the URL that was provided until I reached the BFont page (in English as a bonus) above. It's an informative page to read about! Seems useful if wanting to avoid TrueType fonts.
Last Edit: January 28, 2025, 22:01 by Jatoba
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #88 on: February 02, 2025, 04:54
|
So I decided to revisit the whole "not working in 256 color mode" thing and found...it DOES work in 256 colors...with the caveat being the game must be designed to run in 256 colors... It turns out that SDL Scavenger asks for an 8 bit (256 color) screen with the SDL_SetVideoMode() call, and runs perfectly on a 256 color screen. ---- What is going on is that on some platforms (Windows, Linux, MacOS X?), the SDL_SetVideoMode call will actually CHANGE the video mode of the screen to match what is being asked for...if possible. The Classic MacOS version of SDL doesn't even try...it lies and accepts anything you ask for, but keeps whatever more your screen is already set to. (So it lets you ask for a 16/24 bit screen even if you are in 256 color mode and just "tries" to run anyway). So, what ISN'T working is converting 16/24/32 bit pixels on the fly to display on your Mac if it is in 8 bit color mode. This is tricky to do by hand, so I can see why the SDL authors just didn't bother...but CopyBits() is supposed to be able to do this. So this is still a "bug" in Classic SDL and I'll still look into it a bit, as much as it is worth doing so. But I'll also look at the other games I've ported, and see if they can be made to ask for an 8 bit screen from the start, and therefore run in 256 colors...which'd speed up the 68k version of SDL by quite a lot as it'd be moving half as many bytes per blit. The problem being that SDL 1.x barely does any actual drawing by itself (but just blits rectangles), so the game code must be written for specific pixel sizes. If it isn't already 8 bits, it wouldn't be easy to change...all the drawing code needs to know about the pixel size, etc etc. It's a bit complex to go into, but this is one of the limitations SDL2 was written to solve, with it's "Renderer" and including much more actual drawing code, so game authors didn't need to write as much. (Another reason it was so popular, and you can't just "backport" SDL2 games to SDL 1). Anyway...looking into this...
Last Edit: February 02, 2025, 04:57 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #89 on: February 02, 2025, 07:12
|
@lauland Looking very much forward to that! I find it such a shame that they cut corners here and there with Mac SDL... and find it awesome whenever you identify those issues. And even more awesome when you actually try to address them! I was always displeased at how SDL 2.0 got embraced so quickly... I suspected at first people switched over to it "because it's the current one", and not because of technical merit... But I should not underestimate the SDL devs in terms of API design and capabilities... On a side-note, I'm done with the SDL 1.2 add-ons page... Now we all can let go a sigh of relief that I won't flood it with 100 downloads! Just in case, though, I left links and extra info in a comment in that page, IF we ever do come across some add-on not found in the Garden page, but that we will need...Now my mind is "seated" at trying to port "Egoboo", AND to poke at the 1st party SDL add-ons and see what's up or required for MPW to work with them, as we originally planned. I really think SDL_mixer and SDL_image are by far the most important add-ons, followed closely by SDL_ttf, and then finally by SDL_net. The other 2 1st party add-ons seem very straightforward to get "ready for the Mac" if we ever need to, as well, namely SDL_rtf and GUIlib, but chances are we won't need either of those. And, among the 3rd party ones, SDL_gfx (and earlier SDL_rotozoom) seems to be just about THE most important one, which you also already got covered. (Awesome!) Beyond that, maybe we see something requiring BFont and/or SDL_draw, but hopefully these will not give us that much trouble if we ever need to deal with them. (Btw, Egoboo seems to just use plain SDL and OpenGL, no SDL_mixer nor SDL_image, nor even SDL_net despite it having networking code that is broken for all platforms.)
|
|
Pages: 1 ... 4 5 [6] 7 8
|
| |||||||||||||||
|
© 2021 System7Today.com. |
