Skip to content

GameCube/Wii port of SDL3 - #132

Open
mardy wants to merge 14 commits into
devkitPro:ogc-sdl-3.4.14from
mardy:ogc-sdl-3.4.14-mardy
Open

GameCube/Wii port of SDL3#132
mardy wants to merge 14 commits into
devkitPro:ogc-sdl-3.4.14from
mardy:ogc-sdl-3.4.14-mardy

Conversation

@mardy

@mardy mardy commented Aug 15, 2026

Copy link
Copy Markdown
Collaborator
  • I confirm that I am the author of this code and release it to the SDL project under the Zlib license. This contribution does not contain code from other sources, including code generated by a Large Language Model ("AI").

Description

An SDL3 port to the Wii and GameCube, derived from the SDL2 port. One commit fixes an issue that might affect the SDL2 version too, although I've never seen it happening there.

I've tested this both on Dolphin and on a real Wii using these programs from the test suite:

  • audio: testaudiostreamdynamicresample.elf
  • joysticks: testcontroller.elf
  • renderer: testdrawchessboard.elf, testdraw.elf, testrendercopyex.elf, testrendertarget.elf (all these programs were successfully tested with the GX, software and OpenGL renderers)
  • opengl: testgl.elf

The OpenGL-based renderer can be built and works fine with opengx, but it's currently excluded from the build since we probably prefer the GX backend, which avoids the opengx dependency.

Existing Issue(s)

  • Untested on the GameCube (will do it soon, but only with Dolphin).

mardy added 14 commits August 15, 2026 15:53
We should consider absolute even paths like sd:/ and usb:/
The draw_screen_rect() function was assuming that the GX vertex format
was left the same since the initialization, but that's not the case if
the mouse gets drawn (or if GL calls happen in between frames).

This issue appears only when directly drawing to the framebuffer, which
is something games rarely do; however, the "software" renderer in SDL
operates on the FB, therefore the problem can be currently seen until we
implement the render backend in SDL3.

The render backend in SDL2 directly draws using GX functions, so it's
not affected by this issue (but it might be worth fixing it there, too).
We are not enabling it since the GX backend is preferrable (it doesn't
depend on opengx), but it's good to know that this also works.
These only take up space in the program's code.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant