[humbertodias]

Replace the old PSL1GHT SDL snapshots and shift later library scripts so the SDL stack occupies 013-029.

013-SDL-1.2.15.sh
014-SDL_mixer-1.2.11.sh
015-SDL_image-1.2.10.sh
016-SDL_gfx-2.0.27.sh
017-SDL_net-1.2.7.sh
018-SDL_ttf-2.0.10.sh
019-SDL2-2.31.0.sh
020-SDL2_mixer-2.8.0.sh
021-SDL2_image-2.8.2.sh
022-SDL2_ttf-2.22.0.sh
023-SDL2_gfx-1.0.4.sh
024-SDL3-3.5.0.sh
025-SDL3_mixer-3.2.4.sh
026-SDL3_image-3.4.6.sh
027-SDL3_net-3.2.0.sh
028-SDL3_ttf-3.2.2.sh
029-SDL3_gfx-1.0.1.sh

[bucanero]

thanks for the PR @humbertodias 👍 I'll run the CI checks first

on a side note, another dev opened a PR #89 about SDL3 .

[onesixromcom]

@humbertodias took my branch from SDL repo and create a patch so it's ok to use it here while it's not merged in main.
my pr have additional cmake files for projects which could be useful. I can create new one with those files only no problem.

[Fancy2209]

Could the SDL3 Stuff be removed? I'd rather we use upstream once @onesixromcom's PR is merged.

[humbertodias]

Could the SDL3 Stuff be removed? I'd rather we use upstream once @onesixromcom's PR is merged.

Hello @Fancy2209, sure! We can remove all the sdl3*.patch files once @onesixromcom's PR is merged.

Alternatively, @onesixromcom, could you move these scripts to your PR?

024-SDL3-3.5.0.sh
025-SDL3_mixer-3.2.4.sh
026-SDL3_image-3.4.6.sh
027-SDL3_net-3.2.0.sh
028-SDL3_ttf-3.2.2.sh
029-SDL3_gfx-1.0.1.sh

That way, I can keep the SDL1 and SDL2 stuff and your PR can handle SDL3. What do you think?

[Fancy2209]

We define __lv2ppu__ in GCC

[humbertodias]

humbertodias@71db3ab

[bucanero]

btw, the __PPC__ is also available and I have used it for #ifdefs when needed.

[bucanero]

@humbertodias , one side question, I saw you added a test Github action, that runs on a Docker image, but I'm not sure if there's anything special about it? do we really need it? the current CI already builds all the libraries on 3 archs (linux, mac-intel, mac-arm)

so I'm wondering if we really need the additional test CI, that it seems to do the same thing, but on a docker that we do not control or manage. I think for now it should be disabled or set to manual dispatch, then once we have a proper Docker image published by ps3dev we could come back and use the CI.

[humbertodias]

@humbertodias , one side question, I saw you added a test Github action, that runs on a Docker image, but I'm not sure if there's anything special about it? do we really need it? the current CI already builds all the libraries on 3 archs (linux, mac-intel, mac-arm)

so I'm wondering if we really need the additional test CI, that it seems to do the same thing, but on a docker that we do not control or manage. I think for now it should be disabled or set to manual dispatch, then once we have a proper Docker image published by ps3dev we could come back and use the CI.

makes sense. 8c8f791