@Maijestro

Worked for me. Without .ini file it started in OpenGL mode (gfx_mode=opengl), as I have RadeonRX, this means OpenGLES 2. Also gfx_mode=surfacesdl works here.

Do you get .ini file? Can you try to modify it?

-d9 shows that even in surfacesdl mode ScummVM create an OpenGLES2 context, not sure why, or is it related to the problem.

@Raziel

Yes, when acceleration can be used. On WinUAE or QEMU you need to install a patch and then it's back to SW rendering instead of being accelerated.

It probably should be done so that when user hasn't set this SDL_FRAMEBUFFER_ACCELERATION variable to override something, *then* it could be disabled to avoid patches.

Framebuffer is created for the window created when "software" renderer is used. Using "compositing" implicitly is extremely confusing. User could just choose "compositing" or "opengles2" renderer directly if acceleration is wanted.

@Raziel

Quote:

To clarify, what happened before, was that if framebuffer creation failed due to missing oddball pixel format when using "software" driver in 16-bit mode, SDL2 picked the first accelerated renderer from the list which happens to be "compositing" one. (Nothing to do with any OpenGL so far)

@Maijestro

AFAIK ScummVM uses dynamic linking so it can be tested already by using the new SDL2 RC2 shared objects.

@Raziel

I don't know when I have time to investigate Grim Fandango. Are you sure it's caused by OpenGL renderer? Does it happen with MiniGL? Does it happen with SW renderer (if there is one)?

Have you checked with Snoopy that there isn't something odd triggering?

2.26.5 RC2 is available: https://github.com/AmigaPorts/SDL-2.0/ ... /tag/v2.26.5-rc2-amigaos4

Changes:
- Disable SDL_FRAMEBUFFER_ACCELERATION.
- Use 32-bit ARGB bitmap for framebuffers.

@Maijestro

Thanks for testing. I have uploaded new MilkyTracker archive to OS4Depot and Github: https://github.com/capehill/MilkyTrack ... g/v1.03-amigaos4-release2

@Maijestro

I have updated this archive: http://capehill.kapsi.fi/mt/MilkyTracker-SDL2.lha

Debug binary has serial prints which should be visible with sashimi or dumpdebugbuffer command.

It turned out that SDL2 doesn't actually have all required pixel formats so framebuffer code now uses always 32-bit ARGB bitmap and lets the OS do possible conversions to the desktop format.

Side effect might be that even LiteXL starts to work better on 16-bit screen but it's just because it gets lucky. It should still verify the destination format.

I will update SDL2 archive later if this works OK on QEMU.

@walkero

It seems to me that LiteXL renderer is still buggy and cannot work on anything else than 32-bit surface due to way it's writing the data (it assumes 1 pixel is 32-bits).

https://github.com/lite-xl/lite-xl/blo ... bd660/src/renderer.c#L424

@Maijestro

Found the issue. https://github.com/AmigaPorts/SDL-2.0/ ... /SDL_os4framebuffer.c#L47 R5G6B5PC mode is missing in this switch-case which leads to unknown pixel format, which leads to NULL SW surface, which finally leads to SDL creating another renderer which happens to be the "compositing" because it's first on the list.

I expect this can be fixed for the next SDL2 RC, plus I will rebuild MilkyTracker again, too.

Probably SDL_FRAMEBUFFER_ACCELERATION should be disabled by default, so that use of PatchCompositeTags can be avoided on WinUAE when choosing "software" driver.

@AmigaOldskooler

Thank you very much!

Here are some screenshots, feel free to use if you like:

http://capehill.kapsi.fi/shaderjoy/shaderjoy.png
http://capehill.kapsi.fi/top/tequila.png

@Maijestro

My plan is to provide you a debug binary with serial or console prints because I don't have QEMU yet. Do serial logs work with QEMU (sashimi etc)?

But I will first try to fix the issue with 16-bit mode where "software" renderer is swapped to "compositing" because I can reproduce it myself when SDL_FRAMEBUFFER_ACCELERATION is 0.

I will try to debug these (next week hopefully): https://github.com/AmigaPorts/SDL-2.0/ ... rc/video/SDL_video.c#L225 and https://github.com/AmigaPorts/SDL-2.0/ ... c/video/SDL_video.c#L2696

@Maijestro

By the way, your MilkyTracker images and videos show different colors than usually. Is that some theme or a color channel issue?

@Maijestro

It seems that even if you ask for software renderer, SDL tries to accelerate the framebuffer and create compositing renderer behind the curtains. You could try to disable it by "setenv SDL_FRAMEBUFFER_ACCELERATION 0" and see what happens with "software" driver.

I got mixed results on WinUAE. "software" works OK on a 32-bit screen but for some reason driver is swapped from "software" to "compositing" on a 16-bit screen. No idea why, need to debug more.

OpenGL mode I didn't try but I saw something similar using PatchCompositeTags. Actually whole window content breaks on resize which doesn't happen on native system. When you resize a Wazp3D window, does it break completely?

If you are using "overscan" as logical size mode, then it could have problems. In such a scenario please switch to default/letterbox mode.

EDIT: rebuilt MilkyTracker with the latest SDL2 library: http://capehill.kapsi.fi/mt/MilkyTracker-SDL2.lha

Overscan (with compositing driver) should work now, too.

I noticed someone is reporting a black screen issue on OS4Depot.

Which system (hardware)? For example under WinUAE you need to use PatchCompositeTags or switch to "software" renderer. As normally SDL2 apps use the "compositing" renderer.

SDL 2.26.5 RC1 is available: https://github.com/AmigaPorts/SDL-2.0/ ... /tag/v2.26.5-rc1-amigaos4

- SDL2 prefs is now translated. Original work and Spanish catalog by jabirulo. Italian catalog by samo79. Finnish catalog and adaptations by me.

FYI: descriptor file here https://github.com/AmigaPorts/SDL-2.0/ ... /amiga-extra/sdl2prefs.cd

Sam and Ryan gave a presentation about SDL at Game Developer Conference 2023. Video, slides and other material here: https://www.libsdl.org/gdc2023/

@LiveForIt

OT: Please double-check your _memset function, looks like it's setting the same address size times.

@LiveForIt

https://en.wikipedia.org/wiki/Name_mangling

If I understand your problem correctly, I might try a solution that uses gcc to compile the required Amiga parts (C API) and g++ to compile the normal C++ code. And link using g++.

But you need to provide extern "C" glue to call C++ from C. It's normal.