News:

The Forum Rules and Guidelines
Our forum has Rules and Guidelines. Please, be kind and read them ;).

No executable files for Mac? r8077

Started by THLeaderH, February 13, 2017, 03:00:17 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

THLeaderH

Simutrans 120.2 r8077 was released today, but there is no executable files for Mac! Why?

I compiled the code and now I have the executable file for Mac :)
http://www.filedropper.com/sim-r8077-mac

Ters

Probably because the nightly build server doesn't have a (working) cross-compiler for Mac, and we have not had any Mac developers for some time.

THLeaderH

Oh, that's sad :(
Please use my binary for distribution if you want :D

TurfIt

The provided binary appears linked 'incorrectly' against SDL2.

dyld: Library not loaded: /opt/local/lib/libSDL2-2.0.0.dylib

By 'incorrectly' I mean by not having SDL2 installed as per the official instructions in the SDL2.dmg file:

To Install:
Copy the SDL2.framework to /Library/Frameworks



The most recent OSX binaries have come from me, however since OSX requires the SDL2 backend, and this is currently busted - crashing, I've not provided one.

HaydenRead

Quote from: TurfIt on February 14, 2017, 03:57:26 AM
The most recent OSX binaries have come from me, however since OSX requires the SDL2 backend, and this is currently busted - crashing, I've not provided one.
At what point is the SDL2 backend crashing?

The Steam Build for Windows, Linux, and Mac are all using the SDL2 backend... And they all are working fine for me... (I will admit with Mac and Linux I have only opened the application and confirmed that it is able to load a Saved game, I do most of my actual playing on the Windows build).

TurfIt

Resize the window. Sometimes it works. Sometimes it partly works - the bottom ~1/3 of the screen ends up black. Mostly it crashes.

When the SDL2 backend was developed, this was discovered to happen on the Windows builds using the directx driver. Forcing the opengl driver was a simple workaround.
Since then, the crash seems to have spread. I have 3 win7 machines, 2 win10, and 1 osx now all exhibiting the same.

Strangely your Steam builds of 120.1.2 did work (on Windows at least, I never tried the steam OSX one.) With 120.2, the Steam builds crash the same as my builds.

prissi

The SDL2 routines ignored the given h and w, and then set the internal width and height, so simgraph16 never noticed a resize. The SDL2 was really bugged. There are still some issues with scaling, but now SDL2 should no longer crash on resizing.

TurfIt

Still crashes. The black bottom no longer occurs, presumably height is now set correct. There's now a variable sized black bar to the right of the screen depending on the screens width. It's not immediately obvious where the incorrect width is coming from.

It appears the "// FreeSurface only works if the texture is locked. crashes otherwise..." hack no longer works to prevent crashing. The only way I can get resizing without a crash is to not call SDL_FreeSurface() ever. I expect this causes a leak, but better than a crash, unless the wrong width is somehow responsible...

Ters

Quote from: TurfIt on February 16, 2017, 04:01:38 AM
FreeSurface only works if the texture is locked.

That seems backwards compared to all other APIs with locking of images/textures I've used.

But simsys_s2.cc seems to do things in a rather odd order. When resizing, it first resizes the window, then destroys the texture, then the renderer. After that it creates a new renderer and a new texture. First after that, it destroys the old surface. Although the surface seems disconnected from everything else, maybe it is a good idea to first destroy everything, then resize and then recreate everything. Although I am not sure destroying and recreating the renderer is really necessary.

prissi

I just fiddled a little with the code I got. Before it was using not the w and h given to the resize routine, but the global width and height. So maybe more cleanup is needed.

Since I do not get crashes on my computer, would you mind to make a crash free built on yours, please.

TurfIt

I think it's going to take a while, I'm completely lost in a sea of w, h, width, height, screen->w, screen->h, disp_width, disp_actual_width, disp_height, scale_x, scale_y, and on, and on, ...
Utterly confusing mess. GDI, SDL1, and SDL2 are all completely different in updating disp_width, disp_actual_width, and disp_height. I don't see why they should here.


Quote from: Ters on February 16, 2017, 06:28:21 AM
That seems backwards compared to all other APIs with locking of images/textures I've used.
Agreed. But it worked. Past tense.
And the chopped part of your quote is the important part - it crashed if you didn't. Just like it is now even when you do.

Ters

Quote from: TurfIt on February 16, 2017, 09:34:39 PM
And the chopped part of your quote is the important part - it crashed if you didn't.

I didn't consider the possibility of there being a third option in addition to working and crashing.

Dwachs

#12
I committed some fixes to SDL2 stuff. Please test with r8090. There were a few flaws at work:

1) SDL_DestroyRenderer already calls SDL_DestroyTexture, any extra call to SDL_DestroyTexture resulted in a double free attempt.

2) SDL_LockTexture( screen_tx, NULL, &screen->pixels, &screen->pitch ) modified screen->pixels, hence any calls to SDL_FreeSurface potentially freed memory not allocated by CreateSurface. Just removing SDL_FreeSurface yields to memory leaks.

Now I can run the SDL2 build under linux without any valgrind complaints and memory leaks from resizing. Please test wether this works under Windows as well.

Edit: Attached is a patch to fix the black vertical bars. It works, dont ask me why.
Parsley, sage, rosemary, and maggikraut.

prissi

#13
Sadly that part will not work as soon as the width != w. i.e. when scaling due to high DPI displays cames into play. But I see now where the black bar comes from.

EDIT: Now the bottom part seems missing with high DPI.

TurfIt

Quote from: Dwachs on February 17, 2017, 10:20:21 AM
2) SDL_LockTexture( screen_tx, NULL, &screen->pixels, &screen->pitch ) modified screen->pixels, hence any calls to SDL_FreeSurface potentially freed memory not allocated by CreateSurface. Just removing SDL_FreeSurface yields to memory leaks.
Ignoring the modified pixels seems completely wrong. i.e. Returning screen->pixels, when SDL_LockTexture has set pixels to the valid writable area as per the documentation I can find on the function.
Of course returning pixels doesn't work at all....


Quote from: Dwachs on February 17, 2017, 10:20:21 AM
Edit: Attached is a patch to fix the black vertical bars. It works, dont ask me why.
Correctly setting disp_width and disp_actual_width seems to be very loosely done with all backends. SDL2 now appears correct with r8104, the others...  When the render surface ends up at a size other than simgraph_resize() asks for, that's not being communicated back.


Quote from: Dwachs on February 17, 2017, 10:20:21 AM
Now I can run the SDL2 build under linux without any valgrind complaints and memory leaks from resizing. Please test wether this works under Windows as well.
It appears to be working on Windows now, both in opengl and direct3d. I'd like to try it on some other computers next week, but if the direct3d is now working, the forced opengl might best go away.

prissi

Opengl crashes on my computer and potentially all the other 80% computer around that are using only an Intel builtin GPU driver only ... So I would use some caution agains forcing stuff.