@beworld

Unfortunately I don't ownbthat game, but I would think the issue is the same due to our shared codebase?

What did you change to make it work?
Was it something I could add to the scummvm source?

Thank you

@kas1e

Im not home right now, but will give it a while once im able too.

Thank you very much for all the work

@SinanSam460

Hehe, too excited to read on

@Maijestro

Eventually, yes...
Someone needs to write the shaders first, though.

If you take a look in extras/shaders/ you can maybe grab a glimpse of how much work might be involved.

At least the problem is known to the devs...if and when, I cannot say...don't hold your breath just yet

@SinanSam460

Please read the readme, that's why I wrote it :-/

Quote:

@SinanSam460

What does "nothing happens" mean?
No crash, or no launcher?


Try
ScummVM -d 10
from a shell and catch the output

Or use snoopy

@Maijestro

Thank you.

No, that libvpx crash is something completely different.
It's a new dependancy, fairly recently added and not error prone at all, expect crashes there

Video driver will always be "os4", scummvm doesnt know better...the ogles2/OpenGL debug output is what distinguishes the driver used.

Don't bother with "scummvm -dxx" output, it won't show anything, since the crashes seem to happen on gfx driver/OS level

@Skateman

No way, you can reproduce it?
That is good news. (I can't cross check right now unfortunately, but maybe someone else can confirm it as well?)

So, SDL2 prefs defaults to the best/fastest target available (I guess someone who doesn't have the enhancer pack installed will probably default to MiniGL/OpenGL)

That is also great news, because it means we can work around the start crash (until it's root has been isolated and probably fixed)

Note: if you encapsulate your crashlog with
[ code ]
...
[ /code ]
without the spaces, your post won't grow as long

@capehill

Can you make out something obvious happening in the prefs settings, that could lead to this?

@kas1e

I don't want to question moderational decisions regarding individuals.

@orgin

Since most of the time the comments there are civilised and on-topic, sometimes they are not, which is fine too, I guess, though it starts to get annoying when *real* bug reports are lost in the noise.

Due to such aforementioned individuals I started to try to ignore *any* os4depot comments...I just don't want to waste any more time with such (but should individuals really get the power to degrade a superb software archive with their actions?)

Hence I'm requesting either a block or relay to this site (maybe with a new software sub-forum, that could automatically be linked to the respective os4depot crash logs?).

I know your time is sparse.
Moderating both sites can take it's toll, especially with the ever so growing bot army.
You could add a log-in to os4depot (maybe linked to the amigans server/member pool?), so no anon comments are possible (that would lock out those spam bots)?

Of course, I'll accept every decision you make and adapt my way of use.


Thank you very much

@Skateman

Hmm, interesting...can you check somehow which sdl2 5arget is used if you set it to default?

Maybe there's a glitch in the settings?

@Maijestro

You may have misunderstood.

-d10, which is the maximum btw, will always print everything that comes from scummvm, be it a debug or release build

The debug build is for use with a debugger as the debug flags within the source has been set to be compile in.
I.e. if you happen to get a crash, all information can be accessed and shown by GrimReaper, instead of only basic ones with the release builds

@orgin

Yes, I'm talking about comments on os4depot

@all

debug version at the usual place

@Maijestro

Nice to hear it at least partly not crashing.

Are you on emu or real hw?

@Capehill
@khayoz

arexx is ruled out as well, as ScummVM (not sure about SDL2) knows nothing about arexx.

just for the record, not that it will help much:
- starting crashes of scummvm will result in a dsi
- closing crashes aka scummvm already runs, will result in isi

i wish i knew more about debugging, so i could try and run it in a vm and debug it there

edit:
oh and if anyone wishes to try their luck...the release versions are built with debugging flags disabled...i can build a full debug release on demand (if time permits and i'm on my gear)

Just shout in such case (building one from latest sources right now)

Is there a way to block comments?
Or mark them as blocked, so they don't show up for only me?
Either inidividual ones or user name related?

Thank you

edit:
Or maybe completely block them and rather link to a supported forum in here?
And to go further with my request, could we have a ScummVM forum in the software support?
There are so many dead forums there, maybe even tidy the place up, too?

@Capehill

Unfortunately not, i still get

Quote:
using SDL2 set to "software" and ScummVM set to "SurfaceSDL".

And not even trying to switch modes, just setting the mode and apllying will end up in a crash

@khayoz

From v2.7.0 onwards ScummVM will create an .ini file, if not present, with default settings automatically.

So, that's not it, the bug stems from somewhere else, but since I can't debug, we'll never know (or at least as long as there won't be a working denugger)

Also, if you start ScummVM right after WB boot everything works as expected, run Odyssey beforehand and you'll likely crash.

I suspect memory, gcc bugs, sobjs bugs, you Name it...

@khayoz

https://www.amigans.net/modules/newbb/ ... d=144270&keywords=Scummvm

...and no, it's not that, there is something else crashing...I suspekt many things, memory, sobjs, gcc bugs, but I know nothing for sure

@khayoz

I get random crashes (seldomly) when i first start ScummVM myself, but i can't find the cause.
It seems to be related to if one has opened another program beforehand, e.g. Odyssey...then i can nearly always trigger an ISI.

If one starts ScummVM right after bootup, even without an .ini file, everything works.
I'd love to point to something, but alas, my coding skills are nigh zero

Don't ask me why, no usable debugger means i'm even more at loss (not that i could do anything about it anyway even if i' dknew the cause)

@khayoz