ptitSeb / Eldritch

Eldritch port to the OpenPandora (meaning Arm / GLES2 / OpenAL): Status Working (with latest data file from Steam)
https://boards.openpandora.org/topic/18323-eldritch/
Other
3 stars 2 forks source link

AmigaOS4 : Crash when trying to change language or resolution and game need to reinit screen #6

Closed kas1e closed 3 years ago

kas1e commented 3 years ago

So once we tried to change anything in the options (for example switch language, or resolution, etc), it also crashes and stack tracepoint out on the IUScreenReinitialize function

kas1e commented 3 years ago

Btw, is on Pandora those functions works? I mean language change and resolution? If I remember right, pandora has one resolution, and it can't be changed, but maybe on pandora switching of language fail too?

kas1e commented 3 years ago

I debug it a bit and find out that a crash happens in the code/libraries/UI/src/screen.cpp on the line 261 which is m_FocusedWidget->GetBounds(WidgetBounds); . Not sure though why in stack trace it says that crash happens in UIScreen:: Reinitialize, while the number of string point out on that "GetBounds" function. Seems just some mess happens.

Can you on Pandora change language/resolution ?

I tried to go the usual printf way, and put printfs everywhere around all lines in :

void UIScreen::Reinitialize() {
  for (uint i = 0; i < m_RenderWidgets.Size(); ++i) {
    printf("1\n");
    UIWidget* const pWidget = m_RenderWidgets[i];
    printf("2\n");
    pWidget->Reinitialize();
    printf("3\n");
  }
  printf("4\n");
  UpdateRender();
   printf("5\n");
}

And I correctly can see all prints. Like a crash happens somewhere else after.

ptitSeb commented 3 years ago

I finally tested on the Pandora and sure enough, it also crashes when I switch language.

kas1e commented 3 years ago

Oh, good to know! :) Didn't you try the resolution switch? On pandora, it set to some single resolution the time probably? But maybe just switching also will cause a crash as for me?

ptitSeb commented 3 years ago

No I didn't try, but I assume source of the crash is probably similar.

kas1e commented 3 years ago

Hi ptitSeb ! Haven't a chance to take a look at this one ?

ptitSeb commented 3 years ago

Nope, sorry, I haven't worked on that at all.

kas1e commented 3 years ago

My offer for 150$ is still valid if we can finish aos4 port :)

ptitSeb commented 3 years ago

I know, but I need to stay focussed on box86 for now. But I asked my son @rajdakin to have a look at it :), so things may still progress!

rajdakin commented 3 years ago

So, I've "fixed" the issue, but it's caused by the leaderboard not working properly (probably due to incompatible version?). I'm working on copying the 2019 code release to this repo, but this will take a very long time. (Hopefully there won't be a need for that fix after that.) I pushed the code on my repo.

kas1e commented 3 years ago

Hi! Sounds good!

But was in the hope to check the fix, but it isn't in the repo so far :(

Anyway, IMHO, updating the code will cause more issues than benefits. I mean, it's will be a lot of work. But the current code works well enough, just have 3-4 bugs to be fixed and be done with it :)

ptitSeb commented 3 years ago

fix is there: https://github.com/rajdakin/Eldritch he will do a Pull Request on my repo when all fixes are done.

kas1e commented 3 years ago

Yeah, missed that it was on his repo :) So tested :

1). Crash with language change gone for sure! I can switch now just fine between different languages!

2). Crash when change screen mode went too, but it leaves as with some bugs when we change the resolution of the window: it didn't clear the previous background and seems didn't close the previous window but create a painting area of choice resolution on the top of the current one. Like, if you have for example 1920x1080 by default, and then switch from menu to window mode (that done correctly), and then choose let's say 1024x768, then your big 1920x1080 window still here, but you have a new area created of 1024x768 size, but the previous window of 1920x1080 still here on the screen.

If I then exit, and run again, all settings save correctly, a window of the necessary size, etc. Seems that the previous window just didn't clean correctly. Maybe it happens only on AmigaOS4 dunno (some missing closing of context, flushing SDL buffers, etc? )

kas1e commented 3 years ago

Should add some more about that bug when we change screen mode: that "didn't close the previous window" happens when we tried to set window resolution lower than we have. But if we tried to set resolution bigger than we have, then window didn't recreate of necessary size (just painting area inside is starting to be bigger, like the game is increase as expected, but SDL window is not and stay the same). And at this time in the shell console, we have "Tried to reinitialize nullptr".

As another issue about the switching of video modes, but this time about fullscreen: if we in fullscreen, then we can't switch modes at all, it just blinks, and jump to the mode we had originally on running. And of course in the shell famous "Tried to reinitialize nullptr".

Seems the game loose connection with SDL window/resolution at some point :)

kas1e commented 3 years ago

I also made a video to show how those bugs with resolution changing in window mode look like (sorry for the low-quality video again, but things can be seen anyway): https://youtu.be/eHdIatgz_Q8

rajdakin commented 3 years ago

Huh, strange... It's working on my side (native OpenGL). Maybe a GLES problem? I'll try to look into that. (Also, the "Tried to reinitialize nullptr" message is due to the fix, it's "normal". The leaderboard screen cannot be generated, so it is set to nullptr, then when trying to reinitialize all the screens, it tried to do it to the leaderboard screen too, which led to the crash.)

rajdakin commented 3 years ago

So, I've looked into it, but it seems like everything is alright... Maybe it's an AmigaOS-specific bug?

In GL2RenderTarget::Initialize in 3D/src/GL2/gl2rendertarget.cpp, try to add std::cerr<<"GL2RenderTarget::Initialize "<<m_Width<<" "<<m_Height<<Params.ColorFormat<<" "<<ERTF_None<<"\n"; (also add #include <iostream> at the beginning), then tell me what happens when you try to resize the game (for me, when updating to 1152x864 for example, it shows

GL2RenderTarget::Initialize 1152 864 6 1
GL2RenderTarget::Initialize 192 384 6 1
GL2RenderTarget::Initialize 192 144 6 1

.) If the last two numbers are different and the first two (of the first line) is the correct size you chose, then I don't know what can cause this bug...

kas1e commented 3 years ago

Sorry for the late reply.

So I added that print to the on line 109 (right after the first block of code where m_Width and m_Height set.

Then I run Eldritch in fullscreen 1920x1080 mode, then go to the menu, do switch to window mode, and choice 1024x768. And for all these operations that what I have in the console:

Eldritch initialization complete.
EldritchFramework::ToggleFullscreen
Framework3D::ToggleFullscreen false
Enumerating SDL display modes...
Enumerated mode 1920x1080
Enumerated mode 1280x768
Enumerated mode 1024x768
Enumerated mode 800x600
Enumerated mode 640x480
UIScreenEldSetRes info:
  ScreenWidth:  1920
  ScreenHeight: 1080
EldritchFramework::SetResolution
Framework3D::SetResolution 1024 768
Tried to reinitialize nullptr
GL2RenderTarget::Initialize 1024 7686 1
GL2RenderTarget::Initialize 192 3846 1
GL2RenderTarget::Initialize 192 1446 1
EldritchFramework::UpdateViews
EldritchFramework::CreateHUDView
EldritchFramework::CreateMirrorView
EldritchFramework::CreateMinimapView
EldritchFramework::CreateBuckets 

Is it what expected ?

rajdakin commented 3 years ago

Yes... Unfortunately, my computer doesn't seem to support GLES and only gives me a black screen, so I can't test it, but everything seems OK...

kas1e commented 3 years ago

@rajdakin

Haven't any luck with merging with the latest Eldritch repo ?:) My offer with a donation once we can deal with all bugs still valid, of course :)

kas1e commented 3 years ago

@All I deal with issues about switching video modes: it turned out was issues in our SDL2 port, named "SDL_SetWindowSize + SDL_SetWindowPos combo can fail when calling too fast". So we fixed it on our side.

Now what is left is: "Resurrect in Asylum" didn't work" => https://github.com/ptitSeb/Eldritch/issues/8, which happens on both AmigaOS4 and Pandora, so seems a general issue.