About software vs. OpenGL setting. As far as I know, "software" refers SDL_Renderer use here (SDL2) while OpenGL is then using OpenGL context directly.
SDL_Renderer itself can be SW, compositing or OpenGL or OpenGLES2.
But as there is only one RenderCopy ( https://github.com/scummvm/scummvm/blo ... acesdl-graphics.cpp#L2657 ) in the code, it indicates the drawing the contents of "screen texture" is done by CPU only and using compositing or OpenGL only speeds up scaling or such. Of course one can experiment with different SDL_RENDER_DRIVER parameters and perhaps use debug version of SDL2 to confirm the renderer backend in use.
and then for each run scummvm and check few games which show fps: no visual difference.
But as you say "in the code, it indicates the drawing the contents of "screen texture" is done by CPU only and using compositing or OpenGL only speeds upscaling or such." Do you think it is possible to add amigaos4 ifdefs so as to have drawn not by CPU but by compositing ?
It doesn't seem to easy because data is copied around many times using the CPU before it gets to the screen. One more issue was that 16-bit texture format is used which means SDL2 has to make an extra conversion to 32-bit format before final blitting - but this is common for all HW-accelerated platforms I guess.
It would be best to measure where time is really spent before any optimization attempt, as ScummVM is pretty complicated application.
@Raziel i see you upload a new version of scummvm : wouldn't you mind building the GL4ES version too as reupload archive with 2 binaries ? it's just currently building a bit flaky (with a little hack in the code which shouldn't go into the main svn trunk)
If you share your changes i can upload just the binary for people to try.
Once (any) changes are merged into the main tree we can think about adding the extra binary to the release builds.
What i mean by gl4es binary: not uploading it separately (that i can do myself). But exactly add the binary inside of the archive to avoid us having scummvm.lha and scummvm_gl4es.lha.
Quote:
...and GLAD support has been merged
i not sure that GLAD will be of any difference for us or of any help. More of it i fear it can even broke things for GL4ES. in gl4ES i modify SDL1/SDL2 code so it loaded up all necessary functions. But how that GLADE stuff works and how it will load amiga-specific stuff is unclear for me..
Quote:
Once that is in you can take a more serious look as GL4ES (and not lose all the work you previously done due to some major code changes)
You overcomplicated what was done for making gl4es works in scummvm :) All i had to do it disable shaders in the code (1 string in one file) and that was all.
And there is no need for "serious look as GL4ES" as that: already work. Just need 1 string n the code or probably that just needs instead one more flag passed to the completion process or something of that sort ..
There are no problems with how functions were loaded before. GLAD now will only add (for me) more complication layer about which i know nothing. GLAD if not make things more complicated change nothing for us: SDL1/SDL2/GL4ES already load all necessary functions fine and there weren't any problems with it.
We can't discuss away GLAD, it's in the code, so we have to deal with it.
Yeah for the future yeah but just for now to have ppls all working fast IMHO worth adding gl4es binary to prev GLAD commit and adding it to your 2.5.1 archive.
Just add to the prev GLAD commit (for example 5 days ago one fine) to the backends/graphics/opengl/context.cpp at the line 210 (right before "// Log features supported by GL context." words) this: g_context.shadersSupported = false; so it will be:
Let me know plz if you will have some other issues when building (maybe some include somewhere may need to be fixed but so far this is the one real change needs to avoid usage of shaders, so just pure opengl2.x will be used which is bug-free and faster much than mgl build).
Maybe binaries should be called now ScummVM_MnGL and ScummVM_GL4ES (because if mgl one will be pure scummvm t can make an opinion that this s "man one which needs to use" while better, of course, to use gl4es one if hardware support t).
Building a gl4es shared version of the binary now, will report any issues.
Quote:
Just add to the prev GLAD commit (for example 5 days ago one fine) to the backends/graphics/opengl/context.cpp at the line 210 (right before "// Log features supported by GL context." words) this: g_context.shadersSupported = false;
Err...isn't shader support the reason we're using gl4es in the first place? I mean, granted, hitting the gfx hardware more directly (than with our limited OpenGL) will give us more speed at least, but shouldn't shaders make them fly? (Maybe i don't understand the concept)
Quote:
Maybe binaries should be called now ScummVM_MnGL and ScummVM_GL4ES (because if mgl one will be pure scummvm t can make an opinion that this s "man one which needs to use" while better, of course, to use gl4es one if hardware support t).
Nope, main binary will always be the OpenGL one (for now). I can add it to the *local* (os4depot) package as an add-on binary, but it will not be added to the main release on the scummvm servers (yet).
Err...isn't shader support the reason we're using gl4es in the first place? I mean, granted, hitting the gfx hardware more directly (than with our limited OpenGL) will give us more speed at least, but shouldn't shaders make them fly? (Maybe i don't understand the concept)
No, shaders not reasson to use gl4es. Reasson to use gl4es that it directly use ogles2.library and warp3dnova which written right , and not as minigl, and that mean faster speed.
If saying truth, quite offten shaders make apps be even SLOWER than without shaders (that on all oses). Yes, in ideal world it should "fly", but in end, all the apps written everywhere most of time do the same as before, just use shaders for some additional effects, and not everytime code which handle those shaders are writte right. On win32 that not important, everything fast, but when it come to slower machines, then there i even see sometime that games without shaders works faster than with shaders. And visually not of that big difference.
Also gl4es is very well tested and bug free in terms of opengl support. The shaders still used (internal ones), but that does not matter.
You a bit mess it with the shaders which come together with application - that another bonus, but in terms of scummvm they speed up nothing. The "fly" (i.e. faster in 3-4 times speed in compare wth minigl) hapeens because with gl4es we use ogles2.library+warp3dnova + gl4es with its own (internal) auto-generated shaders.
Quote:
Nope, main binary will always be the OpenGL one (for now).
You mean MiniGL one. GL4ES aslo OpenGL (just better one) :)
Quote:
I can add it to the *local* (os4depot) package as an add-on binary, but it will not be added to the main release on the scummvm servers (yet).
Yeah, that what i mean. Just add it to os4depot archive and i will have no needs to worry about creating scummvm_gl4es.lha because that binary need to be released, as it really faster and better , and users with RadeonHD and RadeonRX will be happy to use faster one.
@Raziel The easy way to be 100% sure that you not mess with gl4es build/sdk/libs/etc, is to grab the version before GLADE from repo (my one from 12.26.2021).
Then, build MiniGL version. Test that all works.
Next, build the GL4ES version. If it will bring ANY new errors/crashes/problems which you didn't have with the MiniGL version it means you mess the GL4ES compilation only, or some old version of libraries in use, etc. No other bugs should arise when you simply swap mgl with gl4es.
Quote:
I assume it hit me with that stupid "can't access subdirectories" bs again and is crashing because ti needs mandatory plugins on loading the games.
If minigl build of the same code works, then surely not.
LIBGL: Initialising gl4es
LIBGL: v1.1.5 built on Apr 17 2021 23:02:30
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: 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
WARNING: Could not find theme 'scummremastered' falling back to builtin!
User picked target 'puttputt-win' (engine ID 'scumm', game ID 'puttputt')...
Looking for a plugin supporting this target... SCUMM [all games]
It's not a problem of anything in the code or configuring or linking or whatnot. It's a problem in the path handling from either inside ScummVM or, what i believe, in our SDK.
See, i get this all the time. It's as easy as building another binary from a different directory with the exact same codebase (like in this case with 2.5.1), copying the resulting binary to my (perfectly fine and working) install dir and starting it...boom, pathes set in scummvm.ini are not accessable from that "foreign" binary, while perfectly working from the other binary. Explain that
Here's the crashlog, not that it points to anything obvious
Crash log for task "gl4es-sdl2_2.5.1"
Generated by GrimReaper 53.19
Crash occured in module gl4es-sdl2_2.5.1 at address 0x4CC85D20
Type of crash: ISI (Instruction Storage Interrupt) exception
Alert number: 0x80000003
and like i said, i know the reason. It tries to access the plugins directory to be able to start the engine, but fails, because the binary refuses to access the subdirectories.
@Raziel Wait that needs to be understating tell death :)
Quote:
It's a problem in the path handling from either inside ScummVM or, what i believe, in our SDK.
See, i get this all the time.
But then you don't get it with mingl correct?
Quote:
It's as easy as building another binary from a different directory with the exact same codebase (like in this case with 2.5.1), copying the resulting binary to my (perfectly fine and working) install dir, and starting it...boom, paths set in scummvm.ini are not accessible from that "foreign" binary, while perfectly working from the other binary. Explain that
Some strange mess. That happens everywhere or just with scummvm ? And what if you build mgl version but from another place and name binary different? Also, crashes?
I have never ever seen such kinds of issues before. Maybe some component of SDk fucked up? But i also don't use shared objects as well.
Quote:
and like i said, i know the reason. It tries to access the plugins directory to be able to start the engine, but fails, because the binary refuses to access the subdirectories.
By plugin directory, you mean what those subjs? If so then you mean we have issues with the shared build of scummvm only? With static build all fine? (i made of course static build only)
Quote:
but fails, because the binary refuses to access the subdirectories.
But it didn't refuse to start when you made mgl build?
So to summorze questons :
1). if you build mgl build from another directories/place it has the same issue?
2). that happens only with shared builds? (try to build a static version of gl4es_scummvm just for tests).
3). happens only with scummvm ?
And step by step we can found from where problem come.
1) It's NOT a problem of minigl vs gl4es 2) It's NOT a problem of static vs shared 3) It's NOT a problem of system components, BUT SDK components (md and cp most of all)
Setup: I have two directories called "minigl_1" and "minigl_2" which both hold the *exact* same scummvm source files.
I build BOTH with only one engine and static (to make it finish faster)
I build _1 and install it to it's own install dir, set up scummvm.ini in there, start it and all is fine. I build _2 and ONLY copy over the binary to the install directory of _1.
I start _2 and this is where it goes haywire. It won't access the perfectly fine themes directory, giving me error message about not finding the theme and not finding translation.dat.
This is NOT everytime, mind you, if i f.e. create ALL the subdirectories manually beforehand with makedir from OS4, all will be fine, IF the binary is nice to me. But it will ALWAYS fail if i keep the installation automated and "cp" and "md" are used, which leads me to believe there is something broken in those programs, what, is beyond me though. Oh, and on another build, like right now with this 2.5.1 gl4es test build, it will fuck up.
I already reported this to the adtools github, but no one seems to care.
I *can* workaround it most of the time, but i don't have the energy to deal with it right now.
I already reported this to the adtools github, but no one seems to care.
It's not that no one care just no one cares when almost everyone for any semi-serious work use cross-compilers and there are a lot more important issues which need to be dealt with when they have time. It is known for years that all those Coreutils on os4 have a bunch of issues. I know you are against cross-compilers for some reason but really you need to use them for scummvm and at least you will not have all those very-weird-strange issues.
Quote:
I *can* workaround it most of the time, but i don't have the energy to deal with it right now.
IMHO you already spend a lot of energy on all thIs so to just to deal with this issue to have a binary working 3 times faster on opengl kind of worth of it :)
At the end of all, i can just build a binary and send it to you and that will be easy for everyone.
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
