Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SDL1/2]: Resizing an OpenGL window trashes contents #71

Closed
raziel- opened this issue Mar 20, 2019 · 26 comments

Comments

@raziel-
Copy link

commented Mar 20, 2019

SDL2.0.9RC2 - MiniGL2.23

A really bad bug in the SDL window drawing/resizing routine.

If i resize a window (with running OpenGL drawn contents) the contents gets trashed.
Not only that, if i switch back a trashed content window to fullscreen it stays trashed and won´t rectify itself, even after a scene change inside the app.

Can be tested with ResidualVM and the Grim Fandango Demo from here: http://demos.residualvm.org/grim-win-demo2-en.zip

See attached pictures:
Window Normal -> Window Resized -> Fullscreen -> Fullscreen Next Scene

1_Window Normal
2_Window Resized
3_Fullscreen
4_Fullscreen Next Scene

@capehill

This comment has been minimized.

Copy link
Collaborator

commented Mar 30, 2019

Please try OS4 Depot version of MiniGL and retest. I will try to reproduce later (April?) with demo.

@raziel-

This comment has been minimized.

Copy link
Author

commented Mar 30, 2019

Since i can't build any new residualvm due to that dreaded png error, this may take some time

@capehill

This comment has been minimized.

Copy link
Collaborator

commented Apr 13, 2019

I just cloned residualvm yesterday, configured and built. I didn't see issue with PNG. Even if there would be issue, it should be possible to work around?

I can see the resize issue on MiniGL but it seems that window resize functionality requires the framebuffer objects. Disabling FBO capabilities in context.cpp on Linux, window content is no more resizable, even though the window itself is. There will be black borders.

So my question to you and ResidualVM devs: should window be resizable without FBOs?

@capehill capehill self-assigned this Apr 13, 2019

@raziel-

This comment has been minimized.

Copy link
Author

commented Apr 13, 2019

Maybe it's because of the flags i use?

I have these LDFLAGS in envarc
-athread=native -Wl,-no-keep-memory -L/sdk/local/newlib/lib
and these CXXCFLAGS
--std=gnu++11

and i'm doing this when configuring
sh ./configure --enable-static

I just tried with gmake clean, it still breaks at the same position

@capehill

This comment has been minimized.

Copy link
Collaborator

commented May 1, 2019

Breaks how? I think I used GCC4 but don't remember (should work anyhow).

@raziel-

This comment has been minimized.

Copy link
Author

commented May 1, 2019

@raziel-

This comment has been minimized.

Copy link
Author

commented May 2, 2019

@raziel-

This comment has been minimized.

Copy link
Author

commented May 10, 2019

Tried with gcc 4.2.4, same issue on compiling

writePNG is not a member of image (something like that)

So, i'm still not able to compile a working exe of residualvm, sorry

@capehill

This comment has been minimized.

Copy link
Collaborator

commented May 19, 2019

I think you can disable USE_PNG for now as a workaround. I seem to have some wrong version of libPNG because configure fails to find it.

@raziel-

This comment has been minimized.

Copy link
Author

commented May 19, 2019

Did you try that?

Setting USE_PNG to NO ot OFF?
I did some time back and it still failed, because the problem lies in sdlsurface source and not in png (or so i think)

I will try again once my compiler is ready again and report back

@raziel-

This comment has been minimized.

Copy link
Author

commented May 19, 2019

Ok, so Bastien heard my pleads and "fixed" the PNG error even with --disable-png for me
residualvm/residualvm@119ff7f

I'm finally able to build both SDL1 and SDL2 residualvm again (with --disable-png in place, so no in-program screenshots).

I'm on to testing again, give me some minutes/hours and i'll report back

@raziel-

This comment has been minimized.

Copy link
Author

commented May 19, 2019

ResidualVM -SDL1 - behaviour cannot be tested because the window does not have a resize gadget!
ResidualVM - SDL2 - behaviour is still there

Test with original (OS4Depot) MiniGL.library doesn´t change it, still there!

@capehill

This comment has been minimized.

Copy link
Collaborator

commented May 25, 2019

If I understand it correctly, this is still open: "my question to you and ResidualVM devs: should window be resizable without FBOs?"

MiniGL doesn't have frame buffer objects. I tested on Linux and without FBOs, window content cannot be resized without FBOs.

@raziel-

This comment has been minimized.

Copy link
Author

commented May 25, 2019

Yes, i know and i apologize, but i haven't got an answer myself from the forums.
I have now sent a message directly to one of the maintainers, lets see...

@raziel-

This comment has been minimized.

Copy link
Author

commented Aug 26, 2019

Finalkly got an answer, hope it helps

quote:
On desktop we render directly to the default framebuffer (either a window or the full screen), no FBO is involved.
As the native resolution of the games are fixed, there is no reason to allow resizing.
There is also no code path that calls SDL_CreateWindow with the SDL_RESIZABLE flag, so the answer is a solid "no" on all fronts.

@raziel-

This comment has been minimized.

Copy link
Author

commented Aug 26, 2019

If i understand it correctly, window shouldn't be allowed to be resized at all?

@raziel-

This comment has been minimized.

Copy link
Author

commented Aug 26, 2019

quote:
I think it is SDL's task to inform the OS this window does not want to be resized.

@capehill

This comment has been minimized.

Copy link
Collaborator

commented Aug 26, 2019

Thanks for info. Obviously your window has the resize gadget so something has gone wrong :)

EDIT: Actually there is resize flag in the code, https://github.com/residualvm/residualvm/blob/d474e3f94fbcf54398b70c7f2c62e45ccb132652/backends/graphics/openglsdl/openglsdl-graphics.cpp#L382 (but I didn't test/verify anything so far).

SDL1 code near line 421 doesn't seem resizable.

@raziel-

This comment has been minimized.

Copy link
Author

commented Sep 7, 2019

@capehill

You were spot on, that was the exact place where it adds the resize gadget.

PR opened on the ResidualVM codebase: residualvm/residualvm#1574

And i guess this issue can be closed?

Thank you very much

@raziel- raziel- closed this Sep 7, 2019

@capehill

This comment has been minimized.

Copy link
Collaborator

commented Sep 8, 2019

Ok, but why change is only for AmigaOS 4? If the window is not supposed to be resizable, then it still is for other platforms?

@raziel-

This comment has been minimized.

Copy link
Author

commented Sep 8, 2019

True.

I was about to change it for every platform, but since i'm waiting for confirmation on the PR anyway i was hoping for discussion on why the RESIZABLE flag was set there in the first place.

Secondly it seems that only AmigaOS4 is affected by this, because i got zero feedback on the forums (guessing that this may mean no one else has this kind of problem.

And finally there may be the possibilty of a code snippet that deals with the resizable windows elsewhere (which "fix" it for all the other platforms), which i didn't want to ditch completely.

@raziel-

This comment has been minimized.

Copy link
Author

commented Sep 9, 2019

Changed in residualvms source now (see link above), albeit taking platforms with FBOs (and games who support resizing) into account, which leads me to the question, will minigl ever have FBOs in the future or are they mutually exclusive?

@capehill

This comment has been minimized.

Copy link
Collaborator

commented Sep 12, 2019

It's unlikely for MiniGL to support FBOs which are "complicated" as Khronos puts it: https://www.khronos.org/opengl/wiki/Framebuffer_Object

Main reason is that Warp3D doesn't support FBOs and probably never will.

But enjoy OGLES2 and Nova.

@raziel-

This comment has been minimized.

Copy link
Author

commented Sep 12, 2019

Ok, so minigl is more or less a dead end and ogles2/nova will eventually surpass and replace it?

@capehill

This comment has been minimized.

Copy link
Collaborator

commented Sep 20, 2019

@raziel- well nobody is actively working on MiniGL and even less with the classical Warp3D.

@raziel-

This comment has been minimized.

Copy link
Author

commented Sep 21, 2019

@capehill

Hmm, i thought Daytona took over MiniGL for his MiniGL/Warp3D reloaded (or something like that) project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.