mhsjlw / mcpilauncher Goto Github PK

Features:

• Move from SDL 1.2 to SDL 2

  • Improved Game Controller API

  • Improved fullscreen support

  • Clipboard support

  • zlib instead of LGPL

• Add fullscreen support

• Add clipboard support

• Add game controller support

• Packaging; i.e.: Flatpak or the like to allow people to easily run it

Fixes:

• Fix crashing when the game tries to load worlds from the directory

• Have the game run at the size of the window (will this break things?)

• Pointer size assertions

• Jail glEnable, glDisable and glEnableClientState to avoid undefined behaviour with inconsistencies accross desktop EGL and Raspberry Pi's EGL

• README that describes how to set up

• Ensure multiplayer and the scripting system work properly

• Remove QEMU from the source tree, possibly have it be a patch?

Use Flatpak to build a release for all the distros!

Use a shallow submodule, and a patch that uses a dlopen to ask a shared object linked against SDL, EGL and X11 to trampoline functions

Currently, the program does not crash. Both of the lock_func and unlock_func in the SDL struct have been filled, and now what happens is the unlock_func is called forever and the program just runs in that infinite loop. Code is provided below with usage of these functions

What is strange is that the unlock_function is being called, although I would think that according to the code below, the lock function would be called first? Yet, the X11 functions are never called, even though they are hooked

Also see the latest commit where I add the SDL lock/unlock, perhaps the function pointers are too large and one is overwriting the other.

The original functions are called in sub_1324C:

int __fastcall sub_1324C(int *a1, int *a2, _DWORD *a3, _DWORD *a4)
{
  _DWORD *v4; // r10
  int *v5; // r5
  int *v6; // r9
  _DWORD *v7; // r6
  int v8; // r0
  Display *v9; // r8
  Window v10; // r7
  int v11; // r0
  Window v13; // [sp+14h] [bp-24h]

  v4 = a4;
  byte_136450 = 1;
  v5 = a1;
  byte_136451 = 2;
  v6 = a2;
  v7 = a3;
  byte_136452 = 15;
  v8 = SDL_GetWMInfo(&byte_136450);
  v9 = dword_136458;
  v10 = dword_13646C;
  dword_136460(v8); // Likely x_lock_function(void);
  XGetWindowAttributes(v9, v10, &unk_136474); // Not called!
  *v7 = dword_13647C;
  *v4 = dword_136480;
  v11 = XTranslateCoordinates(v9, v10, dword_136490, 0, 0, v5, v6, &v13); // Not called!
  return dword_136464(v11); // Likely x_unlock_function(void); then a return (stack was messy)
}

Which is called from sub_12750 (snippet):

_DWORD *v4; // r6
_DWORD *v5; // r4
int v6; // r1
int v7; // r2
int v8; // [sp+8h] [bp-18h]
int v9; // [sp+Ch] [bp-14h]

v8 = a3;
v9 = a4;
v4 = a1;
v5 = a2;
sub_1324C(&v8, &v9, &dword_135C98, &dword_135C9C); // The call to the above function, arguments are passed as pointers and modified, then compared below
if ( v8 != dword_135CA0 || (v6 = v9, v9 != dword_135CA4) || (v6 = dword_135C98, dword_135C98 != dword_135CA8) || (v6 = dword_135C9C, dword_135C9C != dword_135CAC) )
{
  dword_135CA0 = v8;
  dword_135CA4 = v9;
  dword_135CA8 = dword_135C98;
  dword_135CAC = dword_135C9C;
  dword_13644C = 8;
  sub_124BC(v5, v6, 8);
}

Which is then called from a snippet from sub_DFD8 (which appears to be the main function, as it sets up the window, the environment, then appears to run this 'graphics loop'):

do
{
  sub_12750(v5, &v13, v8, v9); // This is the function above
  v10 = sub_128A8(); // This function appears to do the drawing, or terminate
  (*(*v5 + 36))(v5); // Note sure what this does
}
while ( !v10 );

I am yet to figure out the cause of this bug. I am going to trace the application on a real Raspberry Pi to see if I can snuff this out. As well, I need to see if this is just an issue on my system or if it occurs on others.

It likely crashes at XTranslateCoordinates, or some function accessing the struct fields of XGetWindowAttributes

Here's the program output:

x_unlock_function()
XGetWindowAttributes(window = 0)
XTranslateCoordinates(window = 0)
// x_lock_function() should be called

The code that handles the X-related functions:

int XTranslateCoordinates(Display *display, Window src_w, Window dest_w, int src_x, int src_y, int *dest_x_return, int *dest_y_return, Window *child_return) {
  printf("XTranslateCoordinates(window = %d)\n", src_w);

  *dest_x_return = 0;
  *dest_y_return = 0;
  *child_return = 0;

  return 1;
}

int XGetWindowAttributes(Display *display, Window w, XWindowAttributes *window_attributes_return) {
  printf("XGetWindowAttributes(window = %d)\n", w);

  memset(window_attributes_return, 0, sizeof(XWindowAttributes));

  window_attributes_return->visual = 0xdeadbeef;
  window_attributes_return->screen = 0xdeadbeef;

  return 1;
}

Something is going wrong with how the structs are handled/used/generated, not sure how to debug this one to figure it out.

Appears to only happen on my system, I need to do some investigation

I'm not sure what C specification is used in QEMU, but figure out a way to ensure that I'm not corrupting the stack by doing pointer arithmetic. These assertions should be in both stubs/ and QEMU's loader

Jail glEnable, glDisable and glEnableClientState to avoid undefined behaviour with inconsistencies across desktop EGL and Raspberry Pi's EGL

You are distributing other peoples works but don't include the respective licenses anywhere: https://github.com/mhsjlw/mcpilauncher/tree/master/natives/lib

Right after SDL_GetWMInfo, the program crashes when trying to call a non-existent function with non-existent addresses-- right after this call, XGetWindowAttributes and XTranslateCoordinates are called, followed by 0x136464 with arguments from XTranslateCoordinates.

Patching out this function bypasses this crash, however the program then sees itself in an invalid state and chooses to exit, terminating the EGL instance.

Currently, a sockopt error is thrown from QEMU stating that option 13 does not exist, investigate using the Raspberry PI headers