ScummVM and AmigaOS4.1 F.E.

@kas1e

The reason for not using cross-compiles is missing the needed hardware.
I won't place a second computer in here to just compile some stuff.

That's just my 3.5 Euros, but if i cannot compile something on my NG Amiga anymore it's time to move on.
It's still fun to use it, but i want to do more with it.

It's great that people like you bring new software through any means to our platform, but i'm a one computer guy and don't have the time/money/energy to deal with more than one.

Be my guest, send your binary and i'll test

@Raziel
Aha ok, give me a day or two (will try to deal with shaders compilation as well)

@kas1e

Please check PM

@kas1e

Maybe as you are here can you also compile the standard minigl binary as static ? :)
For some reason it preferable to the shared one

@kas1e

Nevermind the PM


Before you start to invest time into this again, let me ask you one of my brainfreeze questions (other peoples brain will freeze)

Your workaround is a very simple three line approach.
It doesn't even touch opengl/minigl stuff, because
a) our minigl/opengl can't do shaders, so they were disabled in the first place,
b) it will only affect potential shader "supporting" destinations, like OGLES2/gl4es and
c) it will only affect amigaos4

Correct?

So, why not simply open up a Pull Request over at github.com/scummvm/scummvm with your workaround and see if the devs can come up with an even better, more integrated solution for their code?

I'm pretty sure they'll instead want to fix our shader problem et al.
You don't need to do everything on your own, you know?

That way we would have your or their fix/workaround in main and i could start compiling working, non-crashing gl4es binaries, because i do have one, but without your fix, so...

@Raziel
That no go for commit because that is just a bug on our side which I tried to find now. And the bug is funny: gl4es shader converted on _our_ side just mess with ifdefs/elses but all fine on pandora/linux. Maybe some memory corruption somewhere or so. Once that will be found and fixed there will be no need for that additional line in code. So it is mostly about GL4ES and related and i am in interest to have all that 3D stuff be as good as possible

@kas1e

Sweet, i just read about your findings on pitseb's github.

Nice to know that it's something that can be fixed.
Does that mean a new gl4es version is coming as well?

@Raziel
if that will be gl4es then sure. But so far didn't look like this. Mostly like something on our side but what this "something" does not found for now :)

@kas1e

See here

Shaders has been moved, maybe that will fix the problems you had with them?

I won't be home for another week, so you might want to try?

I'll do a complete build and see if anything has changed once I'm back home.

@all

Just wanted to let you all know.

There is a FR in the queue which will let AmigaOS4 (and probably MorphOS) users (can't test that platform) choose which render target they'd like to use.

OpenGL 1.3 or OpenGL ES2.

It already works with a bleeding edge build (without juggling with gl4es), but *only* in launcher (launcher is devilish fast already compared to MiniGL 1.3, so this will be a treat once it completely works).

Unfortunately games will crash due to NOVA's missing "Boolean Uniforms" support (which is already part of Hans' to-do list).

Here's hoping they'll be part of the next update.

@Raziel
Quote:

Don't hold it will be fixed any time soon. It's very easy can be workarounds, so Hans surely will not spend time on it (at it in todo for a few years already).

Those "boolian problems" very easy to fix, and you may remember Daniel send you a whole ready archive with all fixed shaders.

But, as i understand at the moment, the SCUMMVM only has use of those shaders for a few games only (And those shaders come with the emulators for them), i.e. Myst and some others.

And maybe there is one single shader coming with ScummVM which needs easy fixing (Daniel do so in the archive he send you a year or two ago).

Quote:

For boolean fixes in Nova? IMHO no luck, if Hans does not say to you that he will do so. But as I say that no problems, those types of errors are very easy to fix and Daniel already send you fixed versions.

@kas1e

I changed all the "bool" affected shaders manually to the workaround daytona posted.

I still get a shader compile error in wintermute:
Quote:
and a completely messed up character in Grim Fandango (only top half visible and no lighting as it seems)

(only tested those two engines)



I am pretty sure i messed it up during the manual change, but i'm also pretty sure i folowed the (two) steps accordingly.

@Raziel
27 fps ?? isn't too low for ogles2? I hope today/tomorrow back to scummvm again, want to deal with those shader-compilation issues.

@kas1e

Take your time...
I'll be off to work today, so can't do any testing anyways.
You could add to the conversation here, as lephilousophe tries to automate it in main.

27 fps is nearly 3.5x times faster than OpenGL with 8 fps...optimization will come later, i assume, also it depends on the hardware used.
Your gfx card and cpu power is probably way higher than mine, so...good enough for me for now.

@Raziel
Now once we deal with that "status" bug about gl4es, i now concetrate fully on the issue we have with scummvm shaders/etc.

Firstly i take today's Github version, and build it over gl4es like this:

Quote:

+ changes in config.mk so it links properly.


Now, once i run scummvm, for first i have that the same problem with themes, by default dunno why it just didn't works as expected, and i forced to be in that ugly inbuild look of menu, need to find out how to fix it ..


Next, i tried to run GRIM with just Graphics mode: software, but game3d renderer : OpenGL (without shaders, so first we test OpenGL only). Once i run it, i have issues about booleans, that ok.

Now, scummvm says, that bug coming from "box.vertex" shader. But, i can't find in the whole scummvm a file named "box.vertex". But find out it in the backends/graphics3d/opengl/surfacerenderer.cpp inside. So that inbuild shaders coming with scummvm and not related to any game at all , just if we build scummvm with opengl, and it says that we can use OpenGL with shaders, then, we automatically have "(USE_OPENGL_SHADERS)" enabled.

And now , even if you choose "pure" OpenGL in 3D engine render of scummvm, or "OpenGL with shaders", it anyway from point of scummvm think its opengl with shaders, and tried to build inbuild shaders.

So will fix firstly that "box.vertex" inside of scummvm.


EDIT: fixed that inbuild "box.vertex" and GRIM runs when i just have "opengl" for 3d renderer. But there no person visibly at all.

Will try now to fix shaders coming with game, so can use "OpenGL with Shaders", will see how it will behave.


EDIT: can't understand where those shaders should be placed ? It seems like they should be "compiled in" when you build scummvm ? I mean ones from engines/grim/shaders/ for example. I only find in graphics/opengl/shader.cpp, this part:



But tried all those dirs inside of scummvm and still have "could not open shader grim_background.vertex!"

@kas1e

Quote:
Just for the sake of completeness, could you add your changes to config.mk too, please?

Quote:
Good luck with that, i already pulled some hairs over that problem (not mine)...i'm pretty sure it's something in the SDK binaries creating broken pathes/dirs etc., but i have no way to prove it.

Quote:
This was worked around by the good people of ScummVM, but not merged yet.
Take a look here:
https://github.com/scummvm/scummvm/pull/3679

Since you have far more insight, feel free to ask questions there too

@Raziel
Quote:

I just use this line:



Quote:

You mean they replaced booleans on ints as Daniel show us some time ago ?

Another question which worry me, why we have for pure OpenGL (i.e. opengl _without_ shaders) , no rendering of main person in Grim.

Will throw questions on them in that topic then

@kas1e

Thank you, was just checking, i have the same locally, but i switch sdl-config on-the-fly (which holds the correct libraries) when building for gl4es, no need to tinker with config.mk every time.

They added macros to not affect other platforms.
It works (to an extent, can't test because i need updated gl4es libraries for it), but fails because normal OpenGL builds will still error.

@Raziel
At least currently we can build it as we wish, that enough for our tests.

I flood them a bit with wall of text in the ticket you point out, so will see what they say.

Also i found that they indeed fixed all the bools seems so, via adding some workaround inside, but dunno why it need it, better to fix imho shaders and be done with.

And their workaround seems to mean that all game's shaders are inbuild into the main scummvm binary, and not coming separately with scummvm ? (see, then change bool on macro BOOL, which they replace on int/etc via amigaos4 ifdefs, mean that this is only when shaders inbuild inside of binary)

@Raziel
And i curious about that "AMIGAOS: Let user select the OpenGL implementation" , how you do select it ? On the fly ? In config files ? Because as far as i see, there "if GL , then MGL", or OGLES, while we also have GL4ES, and it's not 1.3, but 2.1 (and someday maybe 3.x)