Yes, it seems. But ScummVM should be easy to get running with shaders, well the loader at least. I don't have games installed at the moment, really.
Quote:
Because with "compositing" renderer in place fps in some games (where fps display is supported) went up by 0.5-1 fps, which is not worth it. That may be because those engines/scummvm dosn't make use of certain drawing routines (and as thus nothing is optimized) or the fact that composite is not as fast in comparision as i thought it might be.
Hmm, ScummVM doesn't have a generic FPS display does it? I think you should be able to see the difference if you allow ScummVM to scale the display up. Scaling effect is virtually "free" with compositing when compared to pure SW rendering.
@Daytona675x
Quote:
texture2D is deprecated since GLSL 1.30 and its replacement is the overloaded GLSL function texture()
Thanks for the info, I have been reading an older OpenGL ES 2.0 book and didn't know that.
But ScummVM should be easy to get running with shaders, well the loader at least. I don't have games installed at the moment, really.
If you ever have some spare time and are willing to do some tests, build ScummVM with the wintermute engine. Get the freely available game Bickadoodle and set the fps counter to true (all of the wintermute games feature an fps display)
This game will not only showcase the extreme slowdowns in some scenes (due to missing dirty rect and thus updating the whole screen all the time) and the fact that the drawing speed is pretty much the same in OpenGL, ogles2 and composite, but also a rather enerving issue with fullscreen display, as it seems that ScummVM scales to a non-complete resolution to what it gets from the game (say, the gamedisplay, especially the fonts/texts and the fps counter are readable in fullscreen, window has the perfect resolution, though, all is crisp).
We might be able to tackle two things at once? Or at least i could create a new SDL bug item
I don't understand that whole #version tag thing. Shaders are not .c, .cpp if i'm not mistaken?
Could i probably add an ifdef __amigaos4__ to add that tag (to not interfere with other plattforms)? As i said, i don't like local workarounds, i'd rather have them in the original code, so that they don't bite me later on.
What does that tag do? Tell the program to compile the shader with a version below 1.30 (i.e.) on runtime? And if so, what would happen if there are functions inside the shader that are 1.31 and above? Would it still work or refuse to or even crash or send all the butterflies to jupiter?
Sorry, but i'm a noob when it comes to coding but with shaders i know exactly as much as i know about brain surgery...
#version directive sets the shader version. My OpenGL ES 2.0 programmin guide tells to use "100" (1.00). 110 seems to work. Daniel suggested to use value < 130.
If there are some newer stuff in shader code, then you should get a compilation error.
You can use #ifdef __amigaos4__ to wrap the string if you want.
@Capehill About resizing issue, did "quad_mystery.lha" on Daniel's ftp are yours ? I just can reproduce that overflow of window borders just with that example, which seems do not use anything else but only ogles2 , so it can be very well bug in the os. See what i mean:
Regarding the image/png error when building scummvm/residualvm with SDL1/2.
Answer from one of the maintainers: Quote:
Whoever is in charge of this part of the AmigaOS SDK needs to be notified it's not a good idea to name their things Image and such as it's bound to conflict with application code...
There's no point in opening a bug report for the SDK. That struct Image predates SDL by many years, and there's plenty of code that would break if it were changed.
IIRC, for C++ there is an option to enclose system headers in a C++ namespace. Can't remember how, though, so hopefully someone else can help out.
for C++ there is an option to enclose system headers in a C++ namespace
For C++: If you define __USE_AMIGAOS_NAMESPACE__ then everything Amiga-SDK-related will be put into the AmigaOS namespace, so e.g. Image becomes AmigaOS::Image. Note however that the SDK's idltool had a bug until end of 2016 which caused it to create slightly wrong header-files which didn't fully respect this define. One ogles2.lib header suffered from this too, it had been noticed and fixed just recently in v2.1. Some other lib's headers may of course still suffer from this issue and you'll probably have to manually correct them.
Yes, I sent quad_mystery.lha to Daniel. Did you do any modification for the source? I can't reproduce the border overdraw issue.
No, i just use binaries coming in archive. But i not on default amigaos4 theme, but on one which come with aos4 : silvergreen. Maybe that can have some impact on..
Quote:
Ps. did you try particles.lha?
Seems working , through slow when resize window to big :) But with that one i can't reproduce overflow of borders
I can reproduce the window border overdraw issue now, if I just click the minimize gadget. I think it's caused because window box can change before intuition event is handled, something like this:
1) minimize window 2) blit (oops) 3) handle IDCMP_NEWSIZE, read w & h
It's possible to workaround this in test app by refreshing the w & h values before blitting.
It seems to also happen when OGLES2 is let to manage bitmap so maybe it should be checked whether OGLES2 can blit the backbuffer to window with older w & h values?
Ok so this is again a wrong thread, but Daniel, do you copy? -)
Ok so this is again a wrong thread, but Daniel, do you copy?
Yes... I will look into it!
But yeah, this (off)thread-mess is pretty annoying. The MiniGL-thread already turned into a ResidualVM-bug-thread, the others are a wild mix too. Sure, the stuff sometimes overlaps but to be honest, looking at e.g. the sheer amount of mixed stuff in e.g. the GL4ES thread I certainly overread a huge amount of maybe interesting info.
Maybe we need a "mixed 3d issues" thread where people who are unsure where it belongs can put there stuff first, dunno.
@Capehill Is there anything worth of looking in SDL2, which can cause that to fail:
int dblbuf = 0;
if ((SDL_GL_GetAttribute(SDL_GL_DOUBLEBUFFER, &dblbuf) == -1) || (!dblbuf)) {
fprintf(stderr, "Failed to get a double-buffered context.\n");
SDL_Quit();
return false;
}
? I just have for SDL2/minigl build of Lugaru game "failed to get a double-buffered context".
I just checking the old Lugaru sources from os4depot (minigl build), and MickJt there also commenting out this part to make it works.
At time when he port it it was SDL1, but now i build SDL2 version, and it have the same issue with SDL2 too (or with minigl, dunno).
gl4es build works with the same code fine, through, so it maybe minigl and not sdls..
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga 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
I will look into it!
