search

AmigaPorts / SDL_old

Automated mirror of https://hg.libsdl.org/SDL/
Other
9 stars 5 forks source link

OpenGL renderer mangles mouse pointers #34

Closed raziel- closed 5 years ago

raziel- commented 5 years ago

SDL2.0.8 AmigaOS4 - PPC - BE

I have found another glitch with ScummVM using the OpenGL renderer and it's pretty easy to showcase.

Steps to reproduce: 1) Start ScummVM 2) Add the Demo of "Putt Putt travels through time" from here: https://www.scummvm.org/frs/demos/scumm/he/putttime-win-demo-us.zip 3) Go to "Options" and change the renderer to "OpenGL" 4) Start the game (it will come up in a window, but that doesn't matter) Skip (ESC) the intro up to the point where Putt Putt is floating in time with four "time windows" open

This is where the pointer graphics come up and they will be strechted width-wise (it looks as if they have been doubled in width) and cut in half (probably because the apps pointer size is limited).

To workaround this problem, just type "CTRL+LALT+(- or +)" (This key combination will try to change the size of the window, but that doesn't work (for obvious reasons) when using OpenGL mode, it will simply display "Screenmode changed to 640x480" without doing anything APART from curing/fixing the mouse pointer problem.

I'm not sure what is causing this, but it's annoying and looks like a bug. I already set off a bug item for ScummVM a few months back until it went away again (probably because i was testing other renderers, but i never found the real reason until today). Here is the bug tracker item, if someone needs more information: https://bugs.scummvm.org/ticket/10582 The tracker item mentions another game as culprit and yes, there are quite a few games affected, so it's not a problem of a specific game implementation or it's pointer code, but of SDL2's OpenGL renderer (or so i believe).

If someone needs a copy of the ScummVM app (61 MB) for AmigaOS4 just tell me, i have yet to find a way to upload it somewhere where it stays (and the OS4Depot version wasn't built with SDL2)

capehill commented 5 years ago

If you zip the binary and attach here temporarily, would it work? It would save some time from my side.

What engine PP uses? I have configured ScummVM build to minimum.

raziel- commented 5 years ago

I'll try but Odyssey refuses to do more by the day, so i'm not sure if it lets me attach something here.

You'll only need the scumm engine in place (Putt Putt series is HE and that in turn is based on scumm)

I can always send it to you privately? Or maybe better to send you a link to the file?

raziel- commented 5 years ago

Nope, no attachments with Odyssey

raziel- commented 5 years ago

Sent a link privately

raziel- commented 5 years ago

I need to clear up something from my OP

To workaround this problem, just type "CTRL+LALT+(- or +)" (This key combination will try to change the size of the window, but that doesn't work (for obvious reasons) when using OpenGL mode, it will simply display "Screenmode changed to 640x480"

That is not correct. Rather, if you have set the gfx mode to anything else than "OpenGL" the key combination should simply switch through the available gfx filters (2x, 3x etc.) which doesn't seem to work (yet for unknown reasons, this might aswell be a SDL2 problem, as the SDL1 build works as expected, but i'd refrain from blaming SDL2 as of yet).

If you however set the gfx mode to "OpenGL" then you should be able to switch through available screenmodes with said key combination.

Sorry for the mixup

capehill commented 5 years ago

It happens also with SDL1/OpenGL. I don't know what causes it but ScummVM draws all the graphics, including cursor, SDL provides merely the OpenGL context.

It doesn't happen on Linux though, tried both shaders and fixed function.

As a workaround also F5 can be pressed, bring up the menu and then resume: now cursor is OK.

Possible theories which would need some testing:

raziel- commented 5 years ago

I fthere is anything you need me to test, just shout

kas1e commented 5 years ago

For sake of tests, we may try to build GL4ES version of ScummVM, so to see if it issue with minigl, or with SDL itself.

raziel- commented 5 years ago

I tried, remember the thread on amigans about a shader function not supported? Yeah, well, it's not supported in the gfx driver yet, so no, sorry

kas1e commented 5 years ago

Its not what i mean. You tried openGLES version of scumvm. But i told about gl4es, which is another version of opengl (which works ovet ogles2.library, but dont mix 2 different things).

Gl4es compile mean you compile 1:1 the same code as you do for minigl. No opengles code or any new code used. When Gl4es works over ogles2.library it use its own internal shaders which well tested already, but that is hide from coder. You use the same exactly code as you do for minigl. You just link it with libsdl.a which has gl4es compiled in instead of minigl

raziel- commented 5 years ago

I see, mix these things up already, sorry

Where can i get this gl4es/SDL version? I'm keen to try it.

kas1e commented 5 years ago

@raziel There is archive for you: http://kas1e.mikendezign.com/temp/gl4es_dev.zip

Inside you will find 2 link libraries : libgl4es.a and libSDL2.a (which has compiled in gl4es support instead of minigl). So, when you will put those libraries to your SDK, do not forget to rename previous libSDL2.a to something else like libSDL2.a_minigl, so you will not loose minigl version.

Then, in archive there is also GL directory, it is opengl includes. So, you need in your SDK, find out where you have minig GL includes (for me they are in the SDK/local/common/include/GL), and rename that directory to something like GL_minigl_save. And instead, put from my archive new GL includes to the new GL directory.

Now, any opengl programm you will try to build, will have no needs to be changed at all, just on the linking stage, you do not -lSDL2 -lgl -lpthread anymore, but -lSDL2 -lgl4es -lpthread, i.e. just replace gl on gl4es.

Also don't see the big sizes of link libraryes, they are debug ones, and at least gl4es one in real only 1mb of size, but for tests probabaly will be better to have it debugged.

So, try to rebuild scumvm opengl version with that, and see, if we will have the same kind of issues or not.

capehill commented 5 years ago

Issue seems to be somehow related to texture size change. When debugging Puttputt, cursor size seems to be either 16 x 16 or 32 x 32. However, at some point size is changed to 16 x 32 which is a bit odd: maybe Raziel can say more: do you ever see "half-width" cursor in ScummVM?

By hacking away this particular size change, cursor seemed OK. I am not still able to say whether issue is in ScummVM or MiniGL. Have to debug more but it takes time. (MiniGL glTexImage code seemed OK at quick look.)

raziel- commented 5 years ago

@kas1e

Should it be faster too with gl4es?

I'll try when i get some time

raziel- commented 5 years ago

@capehill

You mean like "squeezed" to half of their size? Nope, never.

They only get "cut" after they have been "stretched". Maybe that is what you are seeing while debugging? It's set to 16x32 (stretched) internally, but afterwards displayed in it's normal form (16x16), albeit still "stretched" and thus "cut"?

kas1e commented 5 years ago

@Raziel Not necessary it will be faster. Depend on how all done. But at least it will be not slower, that need to be checked in that particular case. But for us there main point to see if we can rule out minigl from your bug report. If you will have no bug with gl4es version, then its minigl guilty

capehill commented 5 years ago

@raziel- I think the potential rootcause is this: MiniGL ignores texture size change unless both width and height changed. I didn't build debug library (yet) but the code looks like that. Too bad sources are not GH so I cannot easily link it but open http://www.hyperion-entertainment.biz/svn/MiniGL/branches/updates-kc/src/texture.c and search for "square" (2 hits). Here is the code:

        w = context->w3dTextures[current].texObj->texwidth;
        h = context->w3dTextures[current].texObj->texheight;

        if (w != (width<<level) && h != (height<<level)) {

//          dprintf("texture size change detected (%ldx%ld -> %ldx%ld)\n",
//              w, h, width<<level, height<<level);

It can be worked around in ScummVM by making sure that both width and height differ or by disabling MiniGL mipmapping by some means. But it would be ideal to get the correction for MiniGL - if it's confirmed that problem is there.

raziel- commented 5 years ago

@capehill

Awesome, thank you for finding the issue. I'll wait for the MiniGL fix then.

Just glad it's yet another bug ironed out

kas1e commented 5 years ago

@raziel,capehill To be 100% sure, it needs to be build with gl4es. If no bug will be visibly, then its minigl for sure.

raziel- commented 5 years ago

@kas1e

So, well, even if it's a different shader problem, it's still a shader problem, sorry

LIBGL: Initialising gl4es LIBGL: v1.1.1 built on Nov 16 2018 20:01:56 LIBGL: Using GLES 2.0 backend LIBGL: OGLES2 Library and Interface open successfuly LIBGL: Targeting OpenGL 2.0 LIBGL: Forcing NPOT support by disabling MIPMAP support for NPOT textures LIBGL: glX Will try to recycle EGL Surface LIBGL: Current folder is:Development:Coding/Ports/Bleeding Edge/scummvm-opengl-sdl2 LIBGL: Hardware test on current Context... LIBGL: Hardware Limited NPOT 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_element_index_uint detected and used LIBGL: Extension GL_EXT_texture_format_BGRA8888 detected and used LIBGL: Extension GL_OES_texture_float 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: 8(8), Max lights: 8, Max planes: 6 LIBGL: Extension GL_EXT_texture_filter_anisotropic detected and used LIBGL: Max Anisotropic filtering: 16 LIBGL: Hardware vendor is A-EON Technology Ltd. Written by Daniel 'Daytonta675x' Müßener @> GoldenCode.eu WARNING: GL ERROR: GL_INVALID_ENUM on glGetProgramiv(_program, 0x8B82, &result) (backends/graphics/opengl/shader.cpp:171)! WARNING: GL ERROR: GL_INVALID_OPERATION on glGetUniformLocation(_program, name) > (backends/graphics/opengl/shader.cpp:225)! WARNING: GL ERROR: GL_INVALID_OPERATION on glGetAttribLocation(_program, name) (backends/graphics/opengl/shader.cpp:219)! WARNING: GL ERROR: GL_INVALID_OPERATION on glGetAttribLocation(_program, name) (backends/graphics/opengl/shader.cpp:219)! WARNING: GL ERROR: GL_INVALID_OPERATION on glGetAttribLocation(_program, name) (backends/graphics/opengl/shader.cpp:219)! WARNING: GL ERROR: GL_INVALID_OPERATION on glUseProgram(_program) (backends/graphics/opengl/shader.cpp:203)! WARNING: GL ERROR: GL_INVALID_OPERATION on glGetUniformLocation(_program, name) (backends/graphics/opengl/shader.cpp:225)! WARNING: GL ERROR: GL_INVALID_OPERATION on glUseProgram(_program) (backends/graphics/opengl/shader.cpp:203)! WARNING: GL ERROR: GL_INVALID_OPERATION on glUseProgram(_program) (backends/graphics/opengl/shader.cpp:203)! WARNING: GL ERROR: GL_INVALID_OPERATION on glUseProgram(_program) (backends/graphics/opengl/shader.cpp:203)! WARNING: GL ERROR: GL_INVALID_OPERATION on glUseProgram(_program) (backends/graphics/opengl/shader.cpp:203)!

raziel- commented 5 years ago

I get only a black screen after these WARNINGS show up

kas1e commented 5 years ago

Something wrong with your compile. You shouldnt have use of scumvm shaders, as you should build it without shaders.

Give me plz instructions how you build it, and i can try myself

raziel- commented 5 years ago

@kas1e

I did build it without shaders, it was picking them up automatically once the special SDL2 lib and GL dir was in place.

Anyway, i wouldn't waste your time. It's development and i'd rather wait for a release and go bug hunting from there.

capehill commented 5 years ago

It is MiniGL. I built a test library: http://capehill.kapsi.fi/minigl/minigl_texture_debug.lha

It would be nice to hear whether it fix the cursor issue for @raziel- , and also does it fix ticket #35. Basically anything halved/doubled/stretched could be explained by it.

One tiny change makes it work (could of course break something else). I will create a bug report to Hyperion, let's see what happens.

raziel- commented 5 years ago

@capehill

Awesome, thanks for finding the issue

raziel- commented 5 years ago

@capehill

Confirmed fixed with your minigl.lib (as is #35)

capehill commented 5 years ago

Thanks!

Closing as a MiniGL issue (reported).

kas1e commented 5 years ago

@capehill Bad news :( With that patch, we make some thing be broken. Try with your own debug build you upload there, and run over it Lugaru or Cube (both on os4depot) : they both will have problems with textures now. Lugaru in menu have white textures instead, and Cube in game itself have problems with textures.