ScummVM OS4 3.0.0git

ScummVM 3.0.0beta is ready for testing (Test Version against
Paypal donation to tirionareonwe@gmail.com). Currently only
Software renderer though I hope soon also the GL (MiniGL and
GLES) renderer will work.

So looks like no public version really works, your mileage may vary: the newlib ScummVM on OS4Depot has a dependency problem except I suppose if you did not update SDL 2. The amigasoft dot net build has some problem, hard to tell because there is no error message or anything else.

@Thematic

What kind of dependency problem?

You can get old SDL2 shared objects from Github and install it to ScummVM:SOBJS/, or maybe you could create a link from ScummVM:SOBJS/ to the current libSDL2 so.

@Thematic

Have you already tried the 3.0.0git version from Steffen?

As far as I know, this version is statically linked and comes with everything you need. GLES2 support has also already been added without shaders. It works really well for me.

ScummVM 3.0.0 supports a wide range of really modern games, and I'm particularly fond of the Wintermute games.

Here are a few examples of games I use with ScummVM 3.0.0.

https://www.youtube.com/watch?v=vxA4ivsPRD8&t=71s

@Capehill This is useful information.

@Maijestro No, I have not tried 3.0.0git.

edit: I downloaded the Buildbot daily build "stable" from
https://buildbot.scummvm.org/#/dailybuilds
and while it does eat a lot of RAM, I got it running at least a SCUMM game.

Hello everybody, I hope this is the right thread.

I've recently downloaded ScummVM 2026 2.0 from OS4 Depot, followed the instructions but when I launch it the Window content remain black and nothing happens.

My environment is the following:
* QEMU 11/Pegasos2 + BBoot + 2 GB RAM + SiliconMotion 502
* AmigaOS 4.1 FE Update 3

I remember that an older version of ScummVM worked on AmigaOS 4.1 FE on Classic Amiga emulated by WinUAE or FS-UAE...

@Kirirur
The current qemu may have new flaws, as wasn't tested that much as older Raziel's versions in all conditions, so just in case take the older one from https://www.scummvm.org/downloads/ :

https://downloads.scummvm.org/frs/scum ... cummvm-2.9.0-amigaos4.lha

@Kirirur

Please set your SDL preferences to "Software"—you can find them in `sys:prefs`—and also delete the `scummvm.ini` file.

@kas1e I've tried I don't know why it blame for missing SOBJS that are actually present...

@Maijestro both SDL2 and SLD3 are set to default (that I think it Software) and there are any traces of scummvm.ini file in ScummVM folder.

@Kirirur

Compositing is the default. Emulation users can install PatchCompositeTags or use software rendering, as mentioned.

Not sure what is the problem with your SOBJS, can you be more specific?

@Capehill Hello, I'm currently using QEMU to emulate a Pegasos2, if I understood correctly PatchCompositeTags' readme, it is for WinUAE only.

However, setting Prefs - SDL2 - Software, ScummVM 2026 2.0 now starts and display its contents (although is terribly slow), while instead ScummVM old claims:
- libSDL2-2.30.so missing (I have libSDL2.so and libSDL2-2.32.so in SOBJS:)
- ScummVM_old/sobjs/libSDL2_net-2.0.so.200 missing (while instead is present)
- libSDL2_net-2.0.so.200 missing (I currently having no libSDL2_net in SOBJS:)

EDIT: I confess that I'm currently having some troubles in trying to understand the difference between clib4 and newly SOBJS and which one should be installed in SOBJS: folder. Of the packages available on OS4Depot the only one that installs itself in system drive are SDL2 itself and SDL2_mixer.

@Kirirur

clib4 can't use .so file in SOBJS: because they are compiled with newlib and they will not work with clib4.
That's why you need to use PROGDIR:SOBJS/#?.so files so the elf.library will load that one
In any case I don't understand why people continue to use .so files. They are a mess and didn't give use any benefit because all .so files are however loaded at runtime. So having a static exe or a dinamyc exe makes no difference except having a mess with libraries..
The only benefit is when an exe try to load them via dlopen(). Nothing else

@afxgroup
If i remember right, at least Raziel before go .sobjs routes because full static binary with all engines enabled was too big (i do not remember, 200 , 300 or something megabytes) and it was issues for him..

But +1 to static builds. Sobjs on amigaos4 is only problems, because of uncontrolled use where they shouldn't be used.

I _never_ use .sobjs since years, it's only problems for all the users. We have amiga libraries and that more than enough, with very rare exceptions (if at all).

If it was me, i ditch .so support all together form os4 and it's SDK.

@Kirirur

If you use the old ScummVM which was built by Raziel and used newlib, then:

1) You can get older SDL2 shared objects from GitHub, like: https://github.com/AmigaPorts/SDL/releases/tag/v2.30.9-amigaos4

Or,

2) You can make a link (typing this from memory but you get the idea)

Makelink SOFT FROM=libSDL2-2.30.so TO=libSDL2-2.32.so

@kas1e

Quote:

Trust me.. you know what I'm doing and a 500MB exe (not stripped) is not a problem. The problem is somewhere else but not in the static builds.
I think our .so at moment adds only complexity and no benefits

@afxgroup

Quote:

If shared object uses LGPL, then maybe some developers want to avoid static linking.

Also using shared objects allows fixing the library without relinking the app.

@Capehill

Quote:
In AmigaOS4-land no one care about license. We know that very well..

Quote:

Yes, correct but usually a developer will release the entire application with new shared object. So it is the same to release the static linked application.

you have to put the two weights on the scale and compare the pros and cons