[Wii U] Broken render of some backgrounds in "Ib" game

[Wohlstand]

Some scenes of the Ib game (This, translated into Russian, hit the "Скачать игру (36 Mb)" salad-coloured button at the right side of page) gets rendered incorrectly: Seems texture wasn't properly loaded/converted, and as result, the buffer wasn't clered here:

There are several places with such glitch where I caught:

• The "Abyss of deepness" room at begin is glitchy after light goes off.
• The room with a large roze sculpture after light goes off.
• The red room that goes somewhere after guillotine.
• Violet room prior to the fences trap/mini-labirinth, where Mary gets met first time.
• Mary's universe that looks like childish drawings is also broken (because of that, game is almost unbeatable if not play in blind).

I tested two versions of the player: one is the latest at HB AppStore, and second I downloaded from the Jenkins that was built few days ago, and it's also broken.

[Wohlstand]

Just a fact: tested on desktop Linux, it works perfectly:

Tested again on Wii U, and the same room fails (the glitch comes after triggering the "Fake world" painting and returning to the reception room making light to go away).

[Wohlstand]

First in my mind that textures weren't properly converted to the supported hardware format during the load, and that might be a reason of the fail.

[Wohlstand]

Appending the piece of log file:

[2025-06-22 03:42:53] Debug: EasyRPG Player 0.8.1.1 (2025-01-04) started
[2025-06-22 20:09:21] Debug: ===========================================================
[2025-06-22 20:09:21] Debug: CLI: --project-path fs:/vol/external01 
[2025-06-22 20:09:21] Debug: Clock: StdSteady steady=true period=ns (1 / 1000000000)
[2025-06-22 20:09:21] Debug: Seeded the RNG with 1750622961.
[2025-06-22 20:09:22] Debug: SDL2: RendererInfo hw=true sw=false vsync=true
[2025-06-22 20:09:22] Debug: SDL2: Detected format (0) SDL_PIXELFORMAT_RGBA8888 : rank=(0)
[2025-06-22 20:09:22] Debug: SDL2: Detected format (10) SDL_PIXELFORMAT_ARGB8888 : rank=(1)
[2025-06-22 20:09:22] Debug: SDL2: Detected format (11) SDL_PIXELFORMAT_BGRA8888 : rank=(0)
[2025-06-22 20:09:22] Debug: SDL2: Detected format (13) SDL_PIXELFORMAT_ABGR8888 : rank=(2)
[2025-06-22 20:09:22] Debug: SDL2: Selected Pixel Format SDL_PIXELFORMAT_ABGR8888

That tells about the pixel format.

[Ghabry]

Can you check if it makes a difference when you go to the easyrpg settings (iirc is opened via "+" or "-") -> Video and change the scaling to "Integer" or "Nearest Neighbour"?

We actually use a different codepath when Bilinear is used due to a bug in the WiiU SDL2 code (wrong pixel format).

---

My guess is that there is some code in the SDL2 implementation on WiiU that skips copying of pixels when they are fully transparent.

When there is nothing on the bottom of the map we clear everything by writing 0-bytes. Otherwise you get this glitch you show in your screenshots. As you already noticed that works fine everywhere else 🤷. (0000 = black and transparent)

The default SDL2 blend mode is SDL_BLENDMODE_NONE so it should just ignore the transparency and consider them opaque (so is just opaque black).

Have to test on the Wii port if it has the same bug.

[Wohlstand]

Already done that (scaling type), it makes totally no difference. Speaking about SDL2 for Wii U, I have some contact with a developers who maintain it (but primarily to solve other issues like home menu problems and the render lag because of render target to texture assignment done every queue entry).

I could try to make a shot to debug it by myself, but could you hint me how to build it from the source including dependencies?

[Ghabry]

Implementing a workaround to this bug is no big deal. I can add one in a few days (drawing a black, opaque rectangle at the bottom of the screen), just a bit busy right now so not doing any dev...

But is maybe good to find the underlying issue in SDL2 as something is wrong here.

---

To build the WiiU Version:

1. Download the dependencies: Clone this repository: https://github.com/EasyRPG/buildscripts, enter wiiu and run 0_build_everything.sh.

This will only work on Linux. On other systems download the prebuilt from here https://ci.easyrpg.org/view/Toolchains/job/toolchain-wiiu/ and extract the include/lib folder into wiiu from the repo above.

2. Clone the Player repository https://github.com/easyrpg/player

3. Set an environment variable EASYRPG_BUILDSCRIPTS that points to the buildscripts folder (not the wiiu folder) OR put the path in builds/cmake/CMakePresetsUser.json at line 15 (see the vendor remark below that line)

4. cmake --preset wiiu-relwithdebinfo -DPLAYER_BUILD_LIBLCF=ON

5. cmake --build --preset wiiu-relwithdebinfo, the wuhb file is in build/wiiu-PRESETNAME

(or preset wiiu-debug for an unoptimized debug build)

[Wohlstand]

I'll be happy to test if you make something, and on my side, I'll try to build the debug thing to tweak SDL2 itself. Let me know if anything done and where to download the autobuild (the same Jenkins instance that referred at official site?).

---

No worries, at me is Linux everywhere. :)

Thanks for build scripts hinting!

[Ghabry]

sure I'll ping you when the build is ready for testing (I also have a WiiU btw so can also test stuff).

---

Considering you are in contact about the WiiU SDL2 port maybe you also want to check this bug here:

https://github.com/EasyRPG/Player/blob/2fa4e2296aa1f2a80ed7000b1e4c16db495949a3/src/platform/sdl/sdl2_ui.cpp#L591-L606

For the bilinear filter we use an extra render target (set later via SDL_SetRenderTarget) and when we use a render target on the WiiU the colours are wrong (it seems the pixel format is ignored). My workaround is to manually call SDL_ConvertPixels but this shouldn't be necessary (and it works without this trickery on all other platforms) as shown by the #ifdef.

[Ghabry]

Just tested: The bug does not happen on the Wii, so is not Big Endian related, just a SDL2 rendering bug.

@Wohlstand can you check with this wuhb file? https://ci.easyrpg.org/job/player-wiiu-pr/592/

[Wohlstand]

Ye, going to test that as soon as possible. And then I'll try to debug the SDL2 itself and when I'll send the fix to DevkitPro, the workaround can be reverted after they release an update at packages.

[Wohlstand]

Nope, it still fails, fresh screenshots, begining with engine version and build hash:

[Wohlstand]

Just in a case, my gamesave for the Ib game (use that Russian version I shown above to debug): Save01.zip You just need to go to the dotted floor and enter the small room, then go down by ladders (before, push the headless statue), and then glitch will start.

[Wohlstand]

Anyway, the glitch happens at the begin too, just starting new game from the scratch.

[Ghabry]

Okay so the problem seems to be more complex than expected... Will check on my WiiU tomorrow :/

[Wohlstand]

I have some other idea that some textures actually failed to loaded (or thet didn't converted to the hardware compatible format), and instead of textures, the nothing is drawn. I guess the "Abyss of deepnes" during lights off has some different textures that fails to load.

[Ghabry]

Hm yeah now I see it on real hardware: Somehow the background graphic fails to render and displays nothing. 🤔

(so thats a different bug than we had on other devices before where it only happened when the map had no background graphic)

[Wohlstand]

Ye, and these textures of course supposed to be converted into valid format to be accepted. Or, did they failed to load before they reached graphical engine? But I saw no errors in the log 👀

[Ghabry]

yeah it was kinda a bug while converting the image format to the targets pixel format in a pre-processing step.

Full explanation here: https://github.com/EasyRPG/Player/pull/3445

This also means: Not a WiiU SDL2 bug (I was able to reproduce it on my PC by hardcoding the pixel format to the one used on the WiiU, which made debugging soooooo much easier)

[Wohlstand]

Ye, that I had right guessing then, so, where I can take CI build to test?

[Wohlstand]

This? https://ci.easyrpg.org/job/player-wiiu-pr/595/ I took it from GitHub's list of tasks

[Ghabry]

yes, this one (which you already found in the "checks" pane.)

Feel free to do some testing to ensure my fix doesn't break anything else ;).

[Wohlstand]

Tested just now, and, the glitch has been completely gone! No more glitches!!! Thank you very much!

Here are fresh screenshots to confirm the fix:

And bonus (glad to this fix, I finally finished the game that I already replayed several times):

[Wohlstand]

By the way, initially I learned about this game first time from my female-friend, and she was totally right that this game is awesome! Even more it helped us to make EasyRPG better. :)

[Wohlstand]

(P.S. I would like make another issue if not made alaready for another thing which is out of scope, but, this game has one short video that gets shown when opening an album at bookshelf, video itself is encoded by XVid MP4, and FFMPEG is able to decode that. What a problem to add the support for ffmpeg? On my end, I managed to build ffmpeg for my project to Wii and Wii U, and it worked to decode audio such as WMA and M4A, but I didn't tested with videos yet).

[Ghabry]

Video playback is in general unsupported: https://github.com/EasyRPG/Player/issues/1036 . (9 year old issue xD, just nobody was interested in implementing this yet)

[Wohlstand]

Video playback is in general unsupported: #1036 . (9 year old issue xD, just nobody was interested in implementing this yet)

(damn my laggy laptop that caused junk reply was sent. I love desktops, and I use laptop for temporary until I will get cured after illness. This one has two-core AMD A4 CPU, however, 16 GB RAM that I added to reduce the pain after 4 GB RAM combined with "modern and progressive" software).

Maybe I'll make a shot? I actually want to implement a kind of video playing at my projects for cutscenes and other thingies, and I would like to take some of such experience. Even more, by my primary job I developed a lot of software related to CCTV and I understand how these freaking videos working, etc. One of thingies I implemented is the video player that draws frames via OpenGL and shaders to convert YUV to RGB with minimal effort. And I am curious, how that will work if draw by software. However, I suspect these videos will have small frame size, otherwise videos that I played at my workplace are HD and Full-HD, and software colour conversion takes a lot of resources.

[Ghabry]

When you have experience with video processing already: Go for it. A contribution is welcome! I just never had the motivation to figure out the libavcodec API...

The typical videos are 320x240, some are 640x480 so software rendering should be feasible.

(please continue this discussion in #1036 )