Compiling ZDoom for PowerPC linux?

[TDRR]

I'm trying to compile ZDoom 2.7.1 for the Wii, using SRB2Wii, a port of Sonic Robo Blast 2 that utilizes Linux as the base, it runs SRB2 quite decently and with a bit of memory to spare. Besides choosing a binary to play with, i can also directly replace the SRB2
binary with the one i will be using. Pingus also has an example of this

Of course, ZDoom binaries compiled for x86 won't work and just bail out with an error (Incorrect target if i remember correctly) so i need to compile it for a PowerPC processor.

So what are the steps needed to build a PowerPC-targeted Linux binary of ZDoom 2.7.1? With dependencies and compilers included if possible.

Also, what happens when ZDoom runs out of memory? Does it unload things and reload them when needed? Or is it just a crash?
As far as i know, the amount of RAM free might be 80MB or a bit lower, maybe 70MB.

[Graf Zahl]

ZDoom does not purge memory if it runs out of RAM. The entire original zone heap was removed at a time when computers started having half a gigabyte or so. If you run low resource mods you may get lucky on such a memory constrained system - but my guess is that your biggest issue will be the sound. ZDoom up until its last version requires FModEx as its sound backend.
2.8.0 was the first one that could actually be build with an OpenAL backend.

Regarding toolchains on such a system, I'm sorry I cannot help you. In terms of libraries I believe that SDL and FluidSynth are the only hard dependencies on Linux - everything else comes packaged with the source so if you do not have it, it uses its local copy. On the other hand you may want to skip FluidSynth anyway and resort to OPL playback for MIDI because it consumes less resources than a full-blown wavetable synth.

Keep in mind that it was never attempted to compile ZDoom on such hardware, so even if you manage to get a toolchain set up, chances are high that something doesn't work.

[TDRR]

That sucks, is it possible to give ZDoom it's own system for when it runs out of memory? Or would it require a whole rewrite in that part of the code?

As for low resource mods, the only ones i got are maybe DUBG and XParkour, which are 5MB and 30KB each, maybe that should fit the bill.

And yeah, i surely expect problems. The most likely one is software renderer acting up and not drawing anything correctly, but that's the easy part, the hard part comes from not having a way to not die if i run out of memory (SRB2 crashed with 100MB WADS, but i doubt i will get that lucky with ZDoom)

And i was wondering, you know how ZDoomLE has support for OpenGL 1.2, right? Well it's a very nice coincidence that there's also a Mesa2GX driver around for the Wii, so perhaps i can get GL mode running on Wii for a nice performance boost?

EDIT: DUBG in OpenGL mode fits perfectly in the Wii's RAM, around 73MB at max. Unfortunately, software mode wasn't as nice and results were around 90MB which is 2MB past the Wii's theorethical maximum, without Linux to keep around.
So this more or less means i HAVE to get OpenGL running to reduce chances of crashing.

Alternatively i could just hardcode DUBG/XParkour into PrBoom Wii at the expense of ZDoom's great features as well as the expense of easy updating. Hope everything goes decently and i can get ZDoom at the very least running on the Wii.

[Graf Zahl]

And i was wondering, you know how ZDoomLE has support for OpenGL 1.2, right?

No. There is no ZDoom-compatible port supporting such an old OpenGL version. Even in 2005 GZDoom required 1.3 or a few extensions on top of 1.2 to work properly.

[TDRR]

And i was wondering, you know how ZDoomLE has support for OpenGL 1.2, right?

No. There is no ZDoom-compatible port supporting such an old OpenGL version. Even in 2005 GZDoom required 1.3 or a few extensions on top of 1.2 to work properly.

ZDoom LE supports OpenGL 1.2, it's a extremely trimmed down version of regular GL 1.4 that is simply meant to provide filtering or a performance boost over the regular Software renderer. It sucks a little bit and you normally get white textures depending on the GPU, but hopefully it's going to do well on the Wii.

If you don't know what ZDoom LE is, it's a port meant for super low-end computers, running Windows 98 and Pentium 2s and naturally it also supports OpenGL 1.2, which i think is the only OGL Windows 98 supports (i'm likely wrong though)

Changes/features since 2.8.1a R2.1
-Included old OpenGL renderer from GZDoom 1.8.4 with later fixes (off by default). Requires GL 1.2 support.

EDIT: Actually read what you said this time, yeah it's likely it requires GL 1.3 but it's close enough

[Graf Zahl]

it also supports OpenGL 1.2, which i think is the only OGL Windows 98 supports (i'm likely wrong though)

Like on later Windows versions it entirely depends on the graphics driver.

[drfrag]

I cannot even assure that ZDoom LE will compile on mac power pc, it should tough. I've only compiled it on linux and windows both VS and MinGW.
There's no strange alchemy there, 1.8.4 ran on GL 1.2 hardware. Graf could not test back in the day but seems the renderer runs fine on certain 1.2 cards, read nvidia (i tested on a tnt2). On crappy hardware there are certain graphics problems, but that's not due to GL 1.2. It runs even with GL Direct (poorly of course), you get missing textures only with some cards when filtering is enabled (it's disabled by default). Soon after came the 1.3 requirement (else 1.8.5 would abort).
Also 1.0.18 ran on GL 1.1 hardware (not all cards but i tried on an intel 810 and it works).

[Graf Zahl]

I cannot even assure that ZDoom LE will compile on mac power pc, it should tough. I've only compiled it on linux and windows both VS and MinGW.
There's no strange alchemy there, 1.8.4 ran on GL 1.2 hardware. Graf could not test back in the day but seems the renderer runs fine on certain 1.2 cards, read nvidia (i tested on a tnt2).

I don't think it ran on plain unextended 1.2 without feature regression, if at all. AFAIR the stencil extension only became core in GL 1.3, so 1.2 without it wouldn't work.

[TDRR]

If anyone is still interested, i'm going to try to compile ZDoom Classic (based on ZDoom 2.1.4) so we can at least get stuff like OMG Weapons! (and monsters) and those old maps and TCs running nicely on the Wii.

I might also backport newer features because the memory footprint is absolutely microscopical (15MB!) I doubt i will be able to backport much, but i would love to make it on par DECORATE-wise with ZDoom 2.7.1 (or at least 2.6.1) so we can get slightly more modern mods, or maybe even with ZDoom 2.8.1! That would be awesome.

On another note: Does anyone have a universal USB gamepad driver? Of course with source code and all. Most drivers appear to work out of the box (after recompiling for PPC obviously) with WiiLinux (or WiiGentoo or whatever the heck is SRB2Wii running)

EDIT: Is FMOD absolutely required or will ZDoom compile and run normally without it?

EDIT2: Apparently WiiLinux already has one driver found here but i don't know if it's included in the SRB2Wii distribution. (I know i keep mentioning the SRB2Wii distribution, but it's because i REALLY don't want to compile my own WiiLinux because i know it's going to be a pain)

EDIT3: OH GOD I'M SO STUPID: SRB2Wii has a 128MB swap file, so it's likely ZDoom 2.8.1 would run okay (with some stuttering, but okay)

[drfrag]

I never compiled ZDoom CL on linux (i think), only with Code::Blocks and MinGW. It should work tough. ZDoom 2.1.7 crashed but may be was another MinGW specific thing, not sure but no one complained about linux back then. Did those versions run under power pc? Yes, FMod was required. About upgrading decorate that doesn't really make much sense.
There's a no GL version of ZDoom LE for windows 95, it's in the zdoomle branch. But memory footprint is the same if i remember right as long as you don't use the GL renderer. ZDoom LE can use OpenAL for sound (like 2.8.1). Memory requirements were very low as well but big mods will require tons of ram. Also later ZDoom versions were slower but i don't know what version made a big difference on ancient hardware. I don't know how powerful is the wii either.

[TDRR]

I never compiled ZDoom CL on linux (i think), only with Code::Blocks and MinGW. It should work tough. ZDoom 2.1.7 crashed but may be was another MinGW specific thing, not sure but no one complained about linux back then. Did those versions run under power pc? Yes, FMod was required. About upgrading decorate that doesn't really make much sense.
There's a no GL version of ZDoom LE for windows 95, it's in the zdoomle branch. But memory footprint is the same if i remember right as long as you don't use the GL renderer. ZDoom LE can use OpenAL for sound (like 2.8.1). Memory requirements were very low as well but big mods will require tons of ram. Also later ZDoom versions were slower but i don't know what version made a big difference on ancient hardware. I don't know how powerful is the wii either.

Not very powerful: around 750MHz CPU, 250MHz GPU and like 88MB of RAM. It ran SRB2 which is already more intensive render-wise than Vanilla Doom in ZDoom 2.8.1 so that's why my hopes are high.

I have decided on ZDoom Classic though, just to be sure. Also i would love to experiment with the limited decorate and see what wacky mods i can come up with! Maybe even a improved version of ZBlood and a Shadow Warrior TC. Who knows?
'
EDIT: I got an idea, you know Kobo Deluxe Wii? Well, as it turns out, many games work out of the box in the same way Kobo Deluxe did as long as you do the following:
1- Install WiiLinux
2- Throw in the source code of your game and it's dependencies
3- Compile like you always would, except on the Wii
4- Load up the game and hope it works
5- If it doesn't work, enable logging and try again to read what happened

There's a small problem though,i got no USB keyboard

[drfrag]

what are ZDoom Classic's dependencies? are they more or less than the last ZDoom?

They are not the same, besides after the merge with GZDoom (recreated 1.0.18) the Devil library is required. Also i remember that it didn't compile with gcc and i had to fix that before the manual merge (there was no repo). Better forget about it.
There is a version without the GL renderer as well. AFAIR the depencencies are fmod, flac and zlib (same as ZDoom 2.1.4?). But i created the repo from scratch and then i had to merge with ZDoom 2.1.4 in the zdoomcl branch (gzdoom repo) and i got conflicts in all the files, i think i chose "resolve conflicts using mine". It was a mess. https://github.com/drfrag666/ZDoom-CL
All in all you'd better try with LE.

[TDRR]

what are ZDoom Classic's dependencies? are they more or less than the last ZDoom?

They are not the same, besides after the merge with GZDoom (recreated 1.0.18) the Devil library is required. Also i remember that it didn't compile with gcc and i had to fix that before the manual merge (there was no repo). Better forget about it.
There is a version without the GL renderer as well. AFAIR the depencencies are fmod, flac and zlib (same as ZDoom 2.1.4?). But i created the repo from scratch and then i had to merge with ZDoom 2.1.4 in the zdoomcl branch (gzdoom repo) and i got conflicts in all the files, i think i chose "resolve conflicts using mine". It was a mess. https://github.com/drfrag666/ZDoom-CL
All in all you'd better try with LE.

Ok, i'm going to give LE a shot, but i really would prefer to pack ZDoom-Wii as it's own app instead of having to plug in the binary into SRB2Wii. It would be stupidly hard to make it it's own app with ZDoom LE due to the high memory requirements (don't want to do a extreme strip-down of the Linux system)

If that fails, i'm going with Classic, and if that fails too then i'm going to look for some other ZDoom version with low memory requirements (which i doubt i'm going to find) hopefully USB HID support works correctly, that would be a real seller.

[drfrag]

due to the high memory requirements

How do you know? AFAIR LE ran with only 16 mb of ram with the software renderer, compiled with MinGW that is (i checked memory usage on win 7 i actually tested on a 32 mb pentium). But your real problem is to compile first.