|
|
|
|
| Welcome, Guest | Home | Search | Login | Register | |
| Author | DevilutionX secretly supports SDL 1.2! (Read 32278 times) | ||||||||||||||||||||||||||||||||||||||||||||||
|
Jatoba
256 MB  Posts: 270 System 9 Newcomer! 
|
on: February 15, 2025, 06:16
So! When we even just glance at the topmost files from https://github.com/diasurgical/devilutionX , we see right away mentions of "SDL2 2.32.0" or the like, and go like "oh damn, this cr4p is stuck with SDL2!", and then we look the other way... ... And then I accidentally stumbled upon something in THIS (HTTPS) page, while trying to figure out how or why the f@#! there's an Amiga 68k build of all God-forsaken things (built using Docker somehow... wut?): Check out that "CMake build options" part at the bottom, click to expand it: Quote -DUSE_SDL1=ON build for SDL v1 instead of v2, not all features are supported under SDL v1, notably upscaling. No upscaling? No problem! Gimme that SDL 1.2 code!  So, this is clearly like Mini vMac in that it's been implemented with more than one API and, while there are defaults, we can use compiler flags to choose between SDL 1.2 and SDL 2! What do you think, @lauland? 
|
||||||||||||||||||||||||||||||||||||||||||||||
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #1 on: February 15, 2025, 22:46
|
Ok, first, what would this get us, other than a modern Diablo client: "Summary of changes" (modern browser) Other than Hellfire, which doesn't seem to have a MacOS 9 version and would be hella fun, those are all nice, but none of them really compelling (at least to me)? But the primary reason I'm hesitant is the use of CMake for the build process...obviously we could create CodeWarrior project(s), but it has a LOT of 3rd party library dependencies, and every one of them would have to be handled also. Subprojects might be needed for a lot of them, and each one would need to be ported to MacOS 9 themselves. ---- I do find it a bit shocking there's an Amiga port (using SDL1), but I have seen the use of Docker with cross compilers for some similar things...I should try it and see if I can actually get it to work... Because the Amiga build is all command line, this might be something for which we could use Retro68, in a similar way...it already uses CMake for building. So I'm not saying we can't look into this, but I'm seriously doubting CodeWarrior is up to it...or worth the trouble of trying. And I need to get past building anything more complicated than "SillyBalls" for Retro68...
Last Edit: February 16, 2025, 05:08 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #2 on: February 16, 2025, 05:46
|
It's a big thing for big Diablo fans (like me), but you're right, generally Diablo already being there for Mac OS already reduces the "need" for it by quite a bit. It also doesn't help that I'm a purist, and would probably keep on playing the original Windows & Mac versions (whose save files are intercompatible) anyway. It does provide quite a whole lot of "quality of life" improvements when playing, though, and also fixes various bugs that are impactful enough to change the whole game experience (e.g. the classic item dupe glitch is patched out), so I know this would make a lot of people happy to play. Above all, it'd be like an "Awesome!" moment to have it at all playable on Mac OS... I saw the PPC OS X people really rejoicing and celebrating the 1-week-old, super fresh, official PPC Mac OS X 10.4 Tiger port of it over at MacRumors PPC (and 1 guy in the MG D1 page), and I think there would be similar reactions if there was a Mac OS port. But, you're right also about the various dependencies, somehow I completely forgot to consider that, as basic as that is... meaning, in other words, porting this might turn out to be a serious amount of work...
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #3 on: February 16, 2025, 18:27
|
Naw, I understand. I played the hell out of Diablo (and Diablo II) when they came out, on both Mac and Windows. Didn't mean to rain on your parade too much, but do want to point out cost/benefits. You should go ahead and download the source and take a close look yourself to see the scope of what a port would entail. The use of CMake is a big red flag, as we obviously don't have that on MacOS 9...but maybe Retro68 (remember it does PPC and Carbon also)...and the 3rdParty folder is just FULL of dependencies we'd have to take care of. ---- So, with that said, there are two very different approaches we could take...CodeWarrior, which we know works, but is limited, and will require a complex project file...or Retro68 where we might be able to leverage and use the existing CMake build process (having to modify it quite a bit tho). For CodeWarrior, I'd say, go ahead and start creating a project for it and see how far you can get. If I take a look I'd have to do that anyway. Retro68 is another can of worms, a quite large one. It has great potential, but is a bit of a "hack" with the cross compiler and "retro" lib trying to fill in what gcc doesn't provide for m68k and ppc. There's also CMake, which I'm not familiar with, but should learn just to expand my knowledge and resume anyway. So, I'm not saying I won't look into it, and definitely don't want to discourage your enthusiasm, but you can take a closer look at it, and other port candidates, and hey, start on it (and any others you find) and we can toss what you get back and forth between us and both work on them.
Last Edit: February 16, 2025, 23:25 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #4 on: February 17, 2025, 08:17
|
Not an issue over my enthusiasm, don't worry about that! I will put this one on my backlog. Current Mac OS software projects backlog, in order: Egoboo, SDL2 (yes, I want to contribute there where I can), Cave Story, Color QuickDraw Mini vMac II, and THEN DevilutionX. I might put my own personal projects before DevilutionX, even (Game Boy + Mac OS game, and Mini vMac build configuration helper tool).
Last Edit: February 17, 2025, 08:19 by Jatoba
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #5 on: February 17, 2025, 15:27
|
I decided to take a closer look, I have a "decent" ThinkPad laptop with Linux on it, that I don't use much, but would be perfect for this. Instead of trying to use the terribly slow virtual box VM's on my MBP's, not just for it, but for Retro68, Docker, CMake etc in general...to see how it builds where it is supposed to! But the distro I have on it is too old! Three of the apt-get packages DevilutionX needs aren't in its repo, and Retro68 complained about the CMake version...sigh. True it is an Ubuntu from 2016, but it has highly specialized tools for FPGA development (a kind of "soft-hardware"), that I never got around to learning, and I never needed to update it for anything else, its browsers are still relatively up to date... But anyway, I'm just moaning...I don't know if upgrading its Ubuntu will go well or is even possible, but will give it a go. If that doesn't work, I'll just have to reinstall a Linux from the actual 2020's. Don't worry, I have a full bootable backup that I've tested so I won't be losing anything...and obviously I haven't been using the machine for a bit. Oh well. ---- FPGA's are really cool and you are designing and building actual "chips", so can emulate at the hardware level. But it's been almost 10 years, so I might as well face it, if I haven't picked it up by now...
Last Edit: February 17, 2025, 15:30 by lauland
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #6 on: February 18, 2025, 16:42
|
It literally took all day, but eventually got my Ubuntu Linux from 2016 to 2020... That version has all the required dependencies for DevilutionX, so tried building it for Linux. It ran into errors, and because I'm not running the latest version of Linux, not sure if that is due to that, or something else I did. It does get a way into it tho. Will probably have to try again on an Ubuntu 2022 or 2024 release before I give up. [ 29%] Building CXX object test/CMakeFiles/parse_int_test.dir/parse_int_test.cpp.o /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/Scrt1.o: in function `_start': (.text+0x24): undefined reference to `main' NOTE: This may be just because the version of gcc I'm using (9) is too old. ---- The Docker Amiga build still runs into the same problem as before, unable to find libtomcrypt. Again, this may be because my Ubuntu is too old. Trying to install libtomcrypt just native, outside Docker gives a similar error, so pretty sure Ubuntu 2020's repo doesn't include it, and that's what's happening. E: Failed to fetch http://deb.debian.org/debian/pool/main/libt/libtomcrypt/libtomcrypt1_1.18.2%2bdfsg-7%2bb1_amd64.deb 404 Not Found [IP: 151.101.182.132 80] E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? ---- Rebuilding Retro68 from scratch...we'll see how far it gets. The complaint about cmake being too old comes towards the end so may take a while...
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #7 on: February 18, 2025, 18:59
|
Oh well...upgrading from 2020 to higher says it would take more than the 14g of disk space I have free. So starting over from scratch with a brand new fresh install of Lubuntu 24 LTS. Will try building Linux native Devilutionx, Devilutionx for Amiga via Docker, and Retro68 (by hand, but may try via Docker as well). These SHOULD work, as I will be using about the newest Linux you can get.
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #8 on: February 18, 2025, 23:12
|
So, on Lubuntu 2024, was able to build Retro68 and DevilutionX for Linux with no problem, as predicted... Will actually try and play it using the assets from my original Diablo cd's and let you know how it works... Still ran into the libtomcrypt1 being missing with the Amiga DevilutionX docker build...it is used for smpq, for the mpq video files...but just commented that part of the Dockerfile out and...I believe was able to build it otherwise. At least I do have an Amiga executable binary...I doubt I can run it on any of my actual Amigas (only '030's and not good enough video cards), but...during the build saw something VERY interesting... Go here: https://github.com/diasurgical/DevilutionX/tree/master/Source/utils (modern browser) And take a look at the sdl2_backports.h, sdl2_to_1_2_backports.h and sdl2_to_1_2_backports.cpp files...those are a teeny tiny compatibility lib that implements a little bit of missing sdl2 functionality for sdl 1.2! Hmm...
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #9 on: February 19, 2025, 07:06
|
Quote from: lauland And take a look at the sdl2_backports.h, sdl2_to_1_2_backports.h and sdl2_to_1_2_backports.cpp files...those are a teeny tiny compatibility lib that implements a little bit of missing sdl2 functionality for sdl 1.2! Hmm... *mindblown* I knew it! People DID bother to do at least SOMETHING of a "reverse SDL12-compat"! But WHY isn't this ALL over the place when searching for it?! Where did this effort originate from? Can't have been from DevilutionX itself... right? For this type of project, I would think a major WWW-wide annoucement with a huge megaphone is warranted! Anything to bridge SDL2 for SDL 1.2 at all, if done right, is hugely impactful! Perhaps, this is how "SDL 1.2" is a build option in CMake: rather than ACTUALLY coding the game with both SDL2 and SDL 1.2 like Mini vMac does, it is coded with ONLY SDL2, BUT will build and target for SDL 1.2 via this...? That might also explain the "missing features" they mentioned?
Last Edit: February 19, 2025, 07:08 by Jatoba
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #10 on: February 19, 2025, 16:25
|
I only just saw it and took a cursory glance at the functions it defined, but not enough to see what it actually does, or how extensive it is, it's pretty tiny. There are mentions of "devilutionx" in it, and it includes "attributes.h" and "console.h" from it, so it probably was done just for/by them. Well, you know how things are, communication in the open source world isn't always good, and other than on systems like the Amiga also stuck with SDL 1, the whole world had already moved to SDL2, so there probably wasn't much interest. So no megaphone. We...obviously...are VERY interested... You nailed it, those files probably provide JUST enough glue and missing pieces to get DevilutionX running, and are probably nowhere near a full solution. DevilutionX may not use a lot of the more advanced features of SDL2. ---- So, obviously, I'm going to try pulling those files out and building them on MacOS 9 against our SDL. One problem is they are C++, and use the "fmt" library in SDL_GetPrefPath(). But hey, better than nothing. Hard to say if they are enough to port anything other than DevilutionX, but we'll see... ---- Still need to try actually playing the Linux version I built...and see if the Amiga build will run in an emulator...
Last Edit: February 19, 2025, 16:31 by lauland
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #11 on: February 23, 2025, 20:48
|
Copied the .mpq file from my original Diablo disk and was able to play Linux DevilutionX that I'd built from source with no problems. Sure brings back memories! I didn't understand that the mpq file is ALL the game data, and not just for the videos. (I thought it could run, but skip the videos). So since the Amiga build isn't able to find libtomcrypt to build the "smpq" package, it can't work, as it can't read the data files in the mpq file. A hypothetical MacOS 9 build using Retro68 would have the same problem... The Amiga Docker build scripts try and build smpq from source by reading it from a Debian repo, which does not have it. This is strange because the Ubuntu repo that the host machine is running does. I think I could modify the Docker script to use pre-downloaded source for smpq (and/or just libtomcrypt) and thus build it that way. (Or use a different repo?!?) ---- The goal is to get the Amiga version to actually build (and run)...that'd be a "proof of concept" for a MacOS 9 version. Note that the Amiga version downloads and builds a cut down version of the source for SDL 1.2, which only includes Amiga support. If we used a shared lib SDL stub file for a Mac build, we'd skip building SDL, but still need its headers. As I said before, I think I understand how to get the compiling phase (with the above caveats) going, but the linking step I have no idea under Retro68, yet. So...get Amiga version building, by modifying docker script...change to use Retro68 and our SDL...figure out linking...  ?...PROFIT!!!!
Last Edit: February 23, 2025, 20:52 by lauland
|
|
Pages: [1]
|
| ||||||||||||
|
© 2021 System7Today.com. |
