@kas1e

Maybe SDL_Renderer should be skipped in that kind of scenario. Perhaps (8-bit?) source surface can be blitted to window directly:

https://wiki.libsdl.org/SDL_GetWindowSurface

Not sure about how palette will behave. I'm guessing application is setting up the palette itself?

@jabirulo

Please take a look at testnative example. You need to open a native window yourself and pass window pointer to SDL2.

@Raziel

Ok, tried you test case and then hit issue trgswe mentioned. Modified example so that it copies the given path and removes the trailing slash. Tested with BASS and seemed to work.

If you use this, please change log levels back to something reasonable (debug?). I used warning just in case.

@walkero Quote:

Application allocates 32-bit surface https://git.walkero.gr/walkero/lite-xl ... h/os4/src/renwindow.c#L49 . That's why 32-bit rendering logic works.

Operating system has to convert data from 32-bit to 16-bit. When testing SDL2 (testsprite2 program) on a 16-bit screen mode, I noticed slowdown seems to depend on the used render driver (compositing vs. opengles2 vs software).

Quote:

SDL2 currently adapts to screen depth. https://github.com/AmigaPorts/SDL-2.0/ ... /SDL_os4framebuffer.c#L35

Application has to know the surface/bitmap format before writing to it. If application could only render in 16-bit, then it would work wrongly if SDL2 uses a 32-bit framebuffer.

So, if you would like to support different bitmap formats in framebuffer mode, you should branch the renderer logic.

@samo79

Try using device.audio to work around issue where some application (supposedly MPlayer) uses the low-level API for exclusive audio access.

Or change MPlayer to use the device API.

@Raziel

Ok it took a while to get my ScummVM repo updated. Do you know how to test directory creation?

I left a comment to PR, too.

@walkero

But is SDL_Renderer used or not? Define seems to be commented out in makefile. https://git.walkero.gr/walkero/lite-xl ... anch/os4/Makefile.os4#L19 which indicates window framebuffer is used.

If window framebuffer is used instead of SDL_Renderer, it depends on screen depth of the window. But this cannot work if application assumes 32-bit bitmap. Application must inspect the surface and adapt. Pitch, colour mapping and so on.

If the same (window framebuffer using) code works on MorphOS, it probably means MorphOS uses 32-bit bitmap for framebuffers so application expectations are fulfilled.

@walkero

Ok so I started to get a crash when trying 16-bit mode (please see the Lite thread).

Assuming application is using the SDL_Renderer subsystem, is there any difference between software-opengles2-compositing?

@walkero

I tried to test this program on a 16-bit WB screenmode and then it crashed similarly than TearsOfMe reported. Looks like some nullptr issue.

Do you know what this is:

module lite at 0x7E2C51C8 (section 0 @ 0x51A4)

@kas1e

Line number seems incorrect. If you look where the error message comes from, it should be in a different place. It should also be possible to debug the failing lua call, at least using printf.

Is this lua library code also compiled using the same C library?

@walkero

I need to test it myself. Is the drawing logic still 32-bit in general?

@jabirulo

Please check return values of all functions. For example, if SDL_Surface doesn't have a palette (==NULL palette), setting palette colours would fail:

https://github.com/libsdl-org/SDL/blob ... c/video/SDL_pixels.c#L713

I also wonder whether it would be better to call SDL_SetSurfacePalette instead of poking into surface directly.

I haven't tried any of these palette things so cannot say much without experimenting.

@kas1e

testnative example is using SDL_Renderer so it should be able to cope with scaling. But I expect there will be some issues, it's not tested much, after all.

Event handling could be problematic. If you check testnative, you can see it gets the shared WA_UserPort message port from SDL. This must be given for the window so that SDL can get events. Not sure if it can changed after window creation (should be checked from Autodocs). But maybe it's enough for you to handle only application events, not SDL ones.

@samo79

Ticket about which issue? Directory creation by ScummVM is not related to SDL.

@Raziel

Yes, probably code should examine node type to work properly. I think backend code already had some example how to do that? I can maybe take a look on weekend.

@kas1e

testnative is the example. I noticed it crashes at the moment on exit. I changed the quit function https://github.com/AmigaPorts/SDL-2.0/ ... ain/test/testnative.c#L51 to something like:



What are you planning to do with a native window?

@kas1e

SDL2 at least supports https://wiki.libsdl.org/SDL_CreateWindowFrom

testnative example used to work earlier but I haven't been testing it lately.

@LiveForIt

IIRC version strings for "lite" (not libraries). It seems to be because version string is defined in header https://git.walkero.gr/walkero/lite-xl ... c/platform/amigaos4.h#L11

@Walkero

Please consider moving $VER and $STACK into C file.

@walkero

I have tried the latest version on my system: seems to work nicely.

Based on strings query, binary has 3 version ($VER) strings: is this intented?

There seems to be requirement of SDL2: however, current binary appears to be statically linked. So no SDL2 external lib should be needed.

I really like to read Daniel's detailed release notes, compared to those that ship with PlayStation 4 firmware updates "This system software update improves system performance" :)