If problem is now that ScummVM is using the compositing driver for SDL_Renderer, then please open SDL2 prefs and select "software" as driver, or just set the variable on shell:
setenv SDL_RENDER_DRIVER "software"
Thanks for the help
I have set the SDL prefs to software and saved, but that just gives me a gray window output when I start ScummVm.
Could you run ScummVM with -d9 switch and post the log somewhere (will grow big), just to make sure we're not missing something obvious (or 3D is still picked up somewhere)
Could you run ScummVM with -d9 switch and post the log somewhere (will grow big), just to make sure we're not missing something obvious (or 3D is still picked up somewhere)
Can you please explain to me how exactly I have to proceed ? Do I have to start the "-d9 switch" from the ScummVM Gui or via the shell.
I probably shouldn't intrude on this post. But a few years ago I ran ScummVM in beta version. Kindly sent to me by "Raziel" whom I thank for his availability.
I honestly no longer remember how I did it. Using the emulation I clearly couldn't expect it to work like it did on real Amiga hardware.
However if you can get it to work. A strange "BUG" will occur in games like Blade Runner, Broken Sword etc.
The bar in game menus will not be visible. And you won't be able to access inventories. So you basically won't be able to play it.
The version I sent you while making use of "PatchCompositeTag" is able to support all these games instead.
But the later versions I always talk about the AmigaOS Emulation suffer from this "BUG".
I can also provide you with the whole log file, but it wouldn't do any good, I'm sure there is a SDL2 problem under AmigaOs4.1 especially in 16 bit compositing/software mode.
I have exactly the same problem with MilkyTracker SDL2, but it works with Warzp3d and Opengl, ScummVM does not.
Anyway you are doing a great job with ScummVM and I would like to use it too. The Qemu/Pegasos2 emulation is very fast and ScummVM would run fantastic on it even without 3d support.
Maybe you could compile it for me and provide it to me, I could test it then. I am not sure what would be the best way to use it for me.
There seems to be a SDL problem when switching to the software renderer under AmigaOs4.1, you must have read this already. As much as I would like to use ScummVM it makes no sense to test this software until SDL is fixed.
Still, please explain to me what "libz.so" is it an SDL affiliation?
It's a folder containing *infrequent* builds of ScummVM (and their tools) from my local toolchain.
I'll keep them updated, but it depends on whether i'm home or not, so expect big gaps in between updates.
It is *not* Amiga browser friendly i'm afraid (one of the many reasons it took me so long to set up), but it keeps the full build with all engines in main tree (except the frozen ones) including the tools (difference to the daily builds, is that it has all dependencies built in and the binary is highly optimized).
You can test new games/engines with this, but expect bugs, crashes and unpolished experience.
Not to the SDK, but to your toolchain. Get the dependencies on OS4Depot.net. libogles2 is only needed as library in libs:, scummvm has their own implementation without the need to be build against it (iirc)
Check the link one post above and keep your questions coming
NB: The build in there is (right now) a little outdated, but updates will follow
Back to the framerate drop in Grim Fandango, if i may?
I let glsnoop run and can pinpoint where it drops, the log even shows a one second gap where it drops. Not that i know what or why it's caused, but maybe you can read more out of it?
WARNING: OpenGLGraphicsManager::endGFXTransaction: Could not load any graphics mode!!
so it still uses OpenGL when it shouldn't
We should wait for the next SDL2 release candidate and then investigate the problem again.
Capehill has already been able to reproduce that the SDL output still always switches to Compositing/OpenGL, even when the settings in the SDL Prefs are set to Software.