@Raziel Are you sure that stack cookie works at all in scummvm ? I tried now to run scummvm from a shell, and it always crashes, until i didn't do something like "stack 1000000", which mean, that by default there is no stack cookie seems so.
As i see in Raner, by default its 600.000 bytes in 2.1.0, not 2.000.000. And when i set "stack 1000000" , i can see that scummvm need for start in modern theme 732.932, so default 600.000 is too low.
From icon it works because you have set 1024000 stack size in, but that all mean that stack cookie didn't works, or have 600.000 only. At least in 2.1.0
I'm encountering more and more problems with stupids bugs showing up.
One of those is really the best. I did a new build and let it install,. After that i started the app and it showed up with an error message: No translations.dat found.
I had it installed and it was fine, ScummVM just refused to find it. I know these kind of glitches by now, so i simply created a new directory called themes (where the file resides in), copied over translation.dat, restarted ScummVM and, hell, i hate that shit, it worked!!!
Don't ask me why, but due to these problems i have to rebuild over and over again to find a suitable setup where it will work.
Another example...if i compile something from a "bad" directory structure, it will crash on start pointing to libstdc++.so (which it ALWAYS does). Of course, nothing can be done about THAT, AND i can't know beforehand that the structure is "bad", so i have to try again with a known "sane" directory structure and burn time and energy because of that, which is so stupid...if i'd to tell anyone....
Does anyone see right away what the problem could be?
Stack? Anything else obvious maybe?
Crash log for task "ScummVM"
Generated by GrimReaper 53.19
Crash occured in module libstdc++.so at address 0x7EA3B064
Type of crash: DSI (Data Storage Interrupt) exception
Alert number: 0x80000003
FPR (Floating Point Registers, NaN = Not a Number):
0: nan nan -4.4678e+307 nan
4: nan nan 146 104
8: 42 104 2550 4.5036e+15
12: 1 2.14748e+09 0 0
16: 0 0 0 0
20: 0 0 0 0
24: 0 -95.3894 1 -32536.7
28: -105.609 55 26 nan
FPSCR (Floating Point Status and Control Register): 0x82004000
@Raziel Tried to update ScummVM to the latest from os4depot, and find out that "Misc/Themes" does not work, and contains only an inbuild one. From the console output, I also see this kind of warning: "You are missing a valid 'translations.dat' file. GUI translation will not be available!". Not sure if it's related or not. Themes files are in place the same as translations.dat.
In 2.1.0 it surely works.
EDIT: Tried to use daily build (that pre 2.6.0), and issue with themes still there. It also says "GUI Could not find gui-icons.dat" and "could not find theme 'scummremastered' failing back to builtin", while it is here, in the theme directory.
@Raziel Beside that bug with themes, i was able to run fully those ones from dayly build:
Sanitarium Grim Fandango Nightlong
Will check now how works those 3:
The Longest Journey Myst 3: Exile game Escape from Monkey Island
But, what i can say, everything which runs : runs correctly. Nighlong were pleased surprise :) And Sanitarium - wow. But, what is more important there : OpenGL renderer works fine in Grim Fandango at least. On my setup with NovaBridge on RadeonRX, i have with this minigl renderer about 2000 FPS in the movie scenes, but just 15-20FPS in the game itself. There for sure will help GL4ES build of ScummVM too. Not separate build for opengles2 i mean (that can be also be done later), but exactly GL4ES one, which should be really easy to do.
Want me to help you to build GL4ES build ? Or alternatively i may try to build scummvm myself, then once done i can switch to GL4ES, check, if it much faster, then can bring instructions at you, and you can supply not only minigl based binaries, but GL4ES ones too. At least with those new games that will be 100% noticable.
Try this: Create a dir called theme next to themes, copy over everything from themes, delete themes and rename theme to themes. I know, tedious, but I get that a lot after recompiling the source.
It has to do with a broken md command which seems to f*** up newly created directories, so that they aren't accessible from within scummvm.
Strange though, I tested the archive before uploading...maybe your system suffers the same Ghost in the Machine as does mine?
@Raziel Tried, nope, didn't help. I assume there can be bugs in the code that just shows ups differently on different setups.
PS. Tried "The Longest Journey demo" on daily build -> it crashes in minigl. So GL4ES is must sure there. It also wrote me in console "WARNING: Stem darkening is not available with this version of FreeType!" In software mode this game works (with the same error) but awfully slow.
PS2. Tried also Escape From Monkey Island demo: this one works the same as Grim Fandango, but FPS a little bit worse: 10 FPS in-game. So, GL4ES must and there as well :)
PS3. MYST3 is able to run, though feels a bit buggy: in the menu, in window mode, no mouse cursor visibly. Between changes of scenes, i can see some little bit of visual distortion. But in general works.
Edited by kas1e on 2021/12/22 23:37:38 Edited by kas1e on 2021/12/23 0:35:41 Edited by kas1e on 2021/12/23 6:53:04
@Raziel Find out what is wrong with themes: by default (be it os4depot release, or daily build) the "default paths" have nothing in. So it probably for amigaos4 should be default like "PROGDIR:themes" for themes, and "PROGDIR:themes" for "GUI" as well (As there is placed that gui.dat file). And then all will be fine.
Btw, funny how slow MiniGL renderer is it : in Monkey Island it give just a 10 FPS, while in software rendering 5 FPS. Mean that not much of acceleration happens with MGL. But we will know for sure once can made GL4ES build.
The above sigh is not because of your answers, but because of your "drive". I wish i had the same means, determination and time you have and can invest in your hobby and especially into 3D stuff lately.
Of course, please do, test and compile to your heart's content. I'd love to get some help and pointers, but i also have to up front tell you that i will not be able to answer, test or give feedback to anything you do right away, so sorry. Work melts away my sparce free time enormously (and i'm often days away from my setup). But please, don't let me stop you
wrt themes yes, that is "intended" behaviour for the release version (as it doesn't hold a default .ini file). You can also simply set the paths to "themes/" and "extras/", if you left the installation intact. I refrained from adding a default .ini file in the package, as it would overwrite the users one and since everyone uses a different setup it will break many times, as the pathes would always be incorrect. I also didn't use PROGDIR: since that doesn't seem to work on my setup (at least not with ScummVM) If you used the provided installer, it will copy a default .ini file, called scummvm.ini_default (iirc)
wrt MiniGL The renderer never passed the 8-9 FPS barrier in-game on my setup in Grim Fandango (but the game itself runs fluid nonetheless, not sure what's going on, maybe the fps counter is buggy). You can try Wintermute games (Bickadoodle i.e.), they feature a FPS counter as well and those games had quite a nice speedup since 2.2.0 (i get around 40 FPS now in-game (compared to 8-9 FPS) and the games becomes "playable", though they are still perceptionally slower than Grim Fandango (that might be me all along though, since i never played Grim Fandango on another platform than through ScummVM/ResidualVM, so i might have adapted to the "speed")
wrt Myst3 Yes, the game is still pretty buggy and most of the bugs are known, i have already reported some of them. Unfortunately only one of the ScummVM devs is really working on 3D stuff, so development is slow.
Could you check right at the beginning of Myst3 after the intro ran and look up in the sky (where the eagle flies), do you also have what looks like a clamping bug at the edges? There is a black line visible which makes it looks you are standing in a cube.
Another error is in the save/load menu/book, i don't see the font, only the underline.
wrt GL4ES I already have a build of ScummVM (and i automated it, so it builds four different versions of ScummVM once i start my script - OpenGL/SDL2 release, OpenGL/SDL2 - debug, OpenGL/SDL1 - debug and GL4ES/SDL2 - debug), but it still suffers from the already reported (in the GL4ES thread) problems on running the app (white rectangle in the upper right corner, instead of the launcher and the following shader errors).
Two problems though 1) I had to hack around some lines in the code because of the still mandatory GLEW dependancy (don't ask me which) to make it build properly (and which will still error later on, see below) 2) I'm still waiting on a PR which *should* fix those errors (here's hoping) see here
LIBGL: Initialising gl4es
LIBGL: v1.1.5 built on Apr 17 2021 23:02:30
LIBGL: stacktrace will be printed on crash
LIBGL: Using GLES 2.0 backend
LIBGL: Using Warp3DNova.library v1 revision 86
LIBGL: Using OGLES2.library v3 revision 1
LIBGL: OGLES2 Library and Interface open successfuly
LIBGL: Overide version string with "2.1" (should be in the form of "1.x")
LIBGL: Targeting OpenGL 2.1
LIBGL: NPOT texture handled in hardware
LIBGL: Not trying to batch small subsequent glDrawXXXX
LIBGL: try to use VBO
LIBGL: Force texture for Attachment color0 on FBO
LIBGL: Hack to trigger a SwapBuffers when a Full Framebuffer Blit on default FBO is done
LIBGL: Log to the console Error compiling shaders
Log to the console all shaders before and after conversion: Before After Vertex Fragment
LIBGL: Current folder is:Tools:Games/ScummVM
LIBGL: Hardware test on current Context...
LIBGL: Hardware Full NPOT detected and used
LIBGL: Extension GL_EXT_blend_minmax detected and used
LIBGL: FBO are in core, and so used
LIBGL: PointSprite are in core, and so used
LIBGL: CubeMap are in core, and so used
LIBGL: BlendColor is in core, and so used
LIBGL: Blend Substract is in core, and so used
LIBGL: Blend Function and Equation Separation is in core, and so used
LIBGL: Texture Mirrored Repeat is in core, and so used
LIBGL: Extension GL_OES_mapbuffer detected
LIBGL: Extension GL_OES_element_index_uint detected and used
LIBGL: Extension GL_OES_packed_depth_stencil detected and used
LIBGL: Extension GL_EXT_texture_format_BGRA8888 detected and used
LIBGL: Extension GL_OES_texture_float detected and used
LIBGL: Extension GL_AOS4_texture_format_RGB332 detected
LIBGL: Extension GL_AOS4_texture_format_RGB332REV detected
LIBGL: Extension GL_AOS4_texture_format_RGBA1555REV detected and used
LIBGL: Extension GL_AOS4_texture_format_RGBA8888 detected and used
LIBGL: Extension GL_AOS4_texture_format_RGBA8888REV detected and used
LIBGL: high precision float in fragment shader available and used
LIBGL: Extension GL_EXT_frag_depth detected and used
LIBGL: Max vertex attrib: 16
LIBGL: Max texture size: 16384
LIBGL: Max Varying Vector: 32
LIBGL: Texture Units: 16/16 (hardware: 32), Max lights: 8, Max planes: 6
LIBGL: Extension GL_EXT_texture_filter_anisotropic detected and used
LIBGL: Max Anisotropic filtering: 16
LIBGL: Max Color Attachments: 1 / Draw buffers: 1
LIBGL: Hardware vendor is A-EON Technology Ltd. Written by Daniel 'Daytona675x' Müßener @ GoldenCode.eu
LIBGL: GLSL 300 es supported
LIBGL: GLSL 310 es supported and used
Shader source#version 110
#ifdef GL_ES
#if defined(GL_FRAGMENT_PRECISION_HIGH) && GL_FRAGMENT_PRECISION_HIGH == 1
precision highp float;
#else
precision mediump float;
#endif
#else
#define highp
#define mediump
#define lowp
#endif
attribute vec4 position;
attribute vec2 texCoordIn;
attribute vec4 blendColorIn;
@Raziel Wait, but you need GLEW and for MiniGL as well then, and you remove it for MiniGL build too right? Because if not, then you should not have GLEW and for GL4ES too.
Don't ask me, it's too complicated. Iirc GLEW is used for shaders and only The Longest Journey was absolutely relying on it. Grim Fandango (and the other 3D games) has wrappers around the shaders (I think) which uses fallback stuff (that's probably why it's slow on our MiniGL).
GLEW was only circumvented by me in my local source to get the binaries built but it never ran correctly.
@Raziel Ok so , i just go easy route : i build scummvm without any engines, just for sake of tests pure scumm vm inbuild ones and bulid it over gl4es. There have no needs to worry about GLEW, etc (but probably as i didn't build 3d engines it skips).
Now, all i want to see is the working launcher, but instead i have the same as you : white rectangle on the top/right side and shaders errors.
Will dig in now to see what cause of the issue.
Currently i not very well understand why t wasys that error come from backends/graphics/opengl/shader.cpp file, like, shader.cpp is used in any case once we use GL4ES. While for MiniGL it surely should't be used and skipped.
Maybe when we targen anythng that more than 2.0 scummvm then automatcally use some inbuild shaders and they fail by some reassons.
@Raziel Ok, progress a bit: in the scummvm/backends/graphics/opengl/shader.cpp they have inbuild shaders to scummvm (some basic ones). Now if i just use GL4ES headers and link against MiniGL : then shaders didn't executes and all works, launcher menu can be visibly.
Then if we link with gl4es libs, then we have that error in shaders, because shaders want to be executed this time.
Now, i think that probably they in code somewhere have call to check if shaders is supported, if not, then fallback to "no shaders", if yes, then they use some inbuild shaders. But that to be checked.
The failing inbuild shader are small one, this one:
A problem that when gl4es (probably?) tried to convert this shader, it just miss some ifdefs/endifs, and fail.
I manually rewrote this to set some values without IFS, and then, no errors, but, instead of a white box, i have only a black screen, no launcher visibly. So there is something else as well. It's no freeze as i can move by mouse on that black screen and choose some target. So things just didn't show because of the issue of the shader (on scummvm/gl4es side, not in ogles2/warp3dnova at this point)
I wrote a mail to ptitSeb, he always of good help, will see how it going further, and if things turn out to scummvm code, will ask them on their forum
@Raziel Not sure about GLEW, because it then should fail differently, i.e. on the linking stage for example, or on the running stage saying all kinds of fail errors like something not found, not supported, etc.
But in the case with GL4ES we "load/init" all the extensions and stuff manually already so all should work without glew as well. We have in gl4es aglGetProcAddress() which is used for those purposes for which GLEW is used, so we don't need that.
Quote:
GLEW and others are exactly to handle that - you're not linking with GL functions directly, but instead getting function pointers after initialization phase. It allows you to check at runtime which extensions are present and which functions may be used.
But maybe i wrong of course, and in ScummVM we just need to replace some GLEW call on aglGetProcAddress() .. Will try to debug a bit more and keep you informed :) It surely something trivial, i just really want to see if we will have any kind of speed up in Grim/Monkey/Mist3 when switching to gl4es.
ps. And yep, in minigl version, i also have those black dot lines when watching at sky at beginning.
@Raziel Basically, if GLEW was a problem, it shouldn't work for MiniGL too, but it works for MiniGL, and from the side of "how to code use library" GL4ES is the same as MiniGL.
Now, i checked how it all works, and all start to be more or less clear:
In the code, they have checks on what drivers can and what can't. If i run MGL and GL4ES versions with debug, then that is what i have for MiniGL:
1). GL4ES have much more extensions than MiniGL 2). GL4ES mean opengl 2.1 , while MiniGL opengl 1.3 3). GL4ES support NPOT textures, MiniGL are not. 4). GL4ES have Shader support, MiniGL are not. 5). GL4ES have FBO support, MiniGL are not.
So, when we run MiniGL version, it says that we have no shaders, not npot, no fbo, v1.3, and so didn't compile any shaders and even didn't try to do so of course, and fallback to something very trivial.
With GL4ES it can npot, can fbo, can shaders and so: it tries to handle all that new stuff inside of scummvm code => fail somewhere.
I do check one by one, and it wasn't NPOT, wasn't FBO, it's exactly enabling of shaders making it fail.
So what i will try to do now, is set to not use shaders at all like in MiniGL (those inbuild with scummvm ones), but still will use GL4ES, with all the other stuff, and we will see if there will be any changes or not in terms of speed (shaders there didn't play too much role in terms of speed, it mostly for a better look, but all the data transfers over Warp3Dnova instead of pure MiniGL, that should make some differences).
After it works, we can start digging into what is wrong with their inbuild shaders.. They compile with my fix, just black screen, so very possible it is just something trivial too, as shaders really small.
At the moment I will build 2 engines: myst3 and grim (for grim and escape from monkey island). And we will see how things going on.
Edited by kas1e on 2021/12/23 19:10:55 Edited by kas1e on 2021/12/23 19:11:39 Edited by kas1e on 2021/12/23 19:14:46
News feed
OS4 Feedback forum
OS4Depot Feedback forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
