Deep Platformer — looking for people for cross-platform testing

[furious programming]

If you can and want, test it on any other non-Windows system (Linux, FreeBSD, Solaris e.t.c.).

[lainz]

If you can and want, test it on any other non-Windows system (Linux, FreeBSD, Solaris e.t.c.).

I will try tomorrow on Linux.

But I just remember how I fixed the path problem for a bgracontrols project, I did like this

Code: Pascal  [Select][+][-]

1. BCImageButton6.BitmapFile := Application.Location + BCImageButton6.BitmapFile;

You need to add the Application.Location, or anything that does the same the directory of the executable file. A full path is needed.

[furious programming]

Damn...

Currently, all paths are relative and hardcoded, in the form of constants in the Platformer.Constants.pp unit. I could add Application.Location anywhere where paths are used, but I will have to do it with {$IFDEF DARWIN} directives, so it will be quite unreadable.

It will be better to map the file tree to a class tree, so that I can conveniently read these paths. Thanks to this, I can only once and in one place determine prefix for paths (ie Application.Location for macOS or empty string for other systems) and add it to the result of the getter.

Time for the Platformer.Files.pp unit...

By the way — when I choose the MacOS operating system as target, then the code inside the {$IFDEF DARWIN} is disabled (will be skipped during compilation). It is enabled only if I choose Darwin as target OS.

So, what is the correct directive to detect macOS?

[lainz]

No need to add Application.Location to macos only. It will work for all OS since it's cross platform.

[lucamar]

By the way — when I choose the MacOS operating system as target, then the code inside the {$IFDEF DARWIN} is disabled (will be skipped during compilation). It is enabled only if I choose Darwin as target OS.

So, what is the correct directive to detect macOS?

IIRC, the MACOS define was for MacOS 1..9, and DARWIN is for MacOS X and beyond (and iOS?). Let's see if I can find where I saw that ... Ah, yes, in the wiki: Target MacOS

ETA: More helpful - Platform defines

[furious programming]

No need to add Application.Location to macos only. It will work for all OS since it's cross platform.

I checked it — that's right, it is cross-platform. It's just a simple wrapper for ExtractFilePath, but it is short and easy to use. So I use it for all platforms and systems, without compiler directives.

IIRC, the MACOS define was for MacOS 1..9, and DARWIN is for MacOS X and beyond (and iOS?).

[…]

ETA: More helpful - Platform defines

Yes, I saw this article, but I was not sure.

This article states that the MACOS symbol is for classic systems, and the DARWIN symbol is for Mac OS X and iOS. The project code is intended for desktop version of the OS X systems and at the same time not for iOS. So I think that I should use the DARWIN symbol.

if it goes well I will not have to use other symbols than MSWINDOWS and UNIX.

[furious programming]

Ok, I improved the sources.

I have created a new unit — Platformer.Files.pp — in which is located the class preparing the paths.

First set of methods is used to convert a given path to native, always absolute, using native directory separators. These methods have protection against the multiple addition of the prefix in the form of an executable file path.

The second set of methods is used to check whether a file with a given path is on the disk. First, they prepare the path using the above methods, and then check the existence of the file with the standard FileExists function.

This class is used in all of my own classes having the LoadFromFile method and in other places where relative paths from constants are used. So, generally, everytime when the path to the file must be used, the TFiles.MakePath method is used. It is universal and convenient, because we can use both relative and absolute path, and in the result, always we will get the correct absolute path equipped with the native directory separator.

The improved sources are in the attachment. First new feature is the new mechanism for preparing the paths, and the second is the new clock mechanism, which should work on any of Unix-like systems. In addition better than this for Windows, because of using the FPNanoSleep to make delays between frames.

So, if you want to test, go ahead. You can test current sources on any operating system (Windows, Linux, BSD, Solaris and macOS) but, I care most about tests on non-Windows systems. In particular on macOS, because it has not yet been able to compile and run on this system (and now it is probably possible).

Feedback is welcome.

[lainz]

Hi, tested on Mac OS

Doesn't works with the default build mode, no window is shown.

Configured to 32 bit also doesn't works. Configured to 64 bit and the same, no window is shown.

I have no debugger installed or configured so I can't say why it doesn't show up.

[furious programming]

Doesn't works with the default build mode, no window is shown.

Configured to 32 bit also doesn't works. Configured to 64 bit and the same, no window is shown.

Hmm... I had a similar problem earlier on Linux — the game started and worked, but the window did not show up on the screen (it was invisible). All because the game is single-threaded, so it is needed to force the window to show on the screen before the game main loop will be started. And this was done thanks to the custom message handler, which worked on Windows, but not on other platforms. It looked like this:

Code: Pascal  [Select][+][-]

1. uses
2.   LMessages, LCLIntf, Forms, Classes;
3.  
4. const
5.   LM_AFTERSHOW = LM_USER + 1;
6.  
7. type
8.   TMainForm = class(TForm)
9.     procedure FormShow(ASender: TObject);
10.   protected
11.     procedure LMAfterShow(var AMessage: TLMessage); message LM_AFTERSHOW;
12.   end;
13.  
14. {..}
15.  
16. procedure TMainForm.FormShow(ASender: TObject);
17. begin
18.   PostMessage(Self.Handle, LM_AFTERSHOW, 0, 0);
19. end;
20.  
21. procedure TMainForm.LMAfterShow(var AMessage: TLMessage);
22. begin
23.   // here the game main loop starts
24. end;

This solution work only on Windows. The test application is in the attachment — you can try.

I changed this code and use cross-platform function to force the window to show, inside the OnShow event handler. Thanks to this, messages are not used and the game can show the window on Linuxes too. Example:

Code: Pascal  [Select][+][-]

1. uses
2.   LCLIntf, LCLType, Forms, Classes;
3.  
4. type
5.   TMainForm = class(TForm)
6.     procedure FormShow(ASender: TObject);
7.   end;
8.  
9. {..}
10.  
11. procedure TMainForm.FormShow(ASender: TObject);
12. begin
13.   ShowWindow(Self.Handle, SW_SHOWNORMAL);
14.   // here the game main loop starts
15. end;

See the second attachment. And this solution is currently implemented in the game project:

Code: Pascal  [Select][+][-]

1. // Platformer.Window.pp, line 77
2.  
3. procedure TGameForm.FormShow(ASender: TObject);
4. begin
5.   ShowWindow(Handle, SW_SHOWNORMAL);
6.   Game.Start();  // here the game main loop starts
7. end;

But I do not know why this work on any systems, but on macOS not.

It is a pity that the TForm class does not have an event performed after actually showing the window on the screen (eg OnAfterShow) — I would not have to do all this stuff...

If this project must work on this system, we need to figure out how to force the window to show on the screen inside the OnShow event handler, before the Game.Start method call.

If someone wants to try to solve this problem on macOS, just download the showwindow test.zip and try to change it so that the message box appears above the program window, not alone. The correct result can be found on the screenshot in the attachment.

[Thausand]

It is a pity that the TForm class does not have an event performed after actually showing the window on the screen (eg OnAfterShow) — I would not have to do all this stuff...

I already make show you 

If not event then make own 'fake'. can use asynccall or application.onidle. Onidle have make boolean and only call once. If forget boolean then call many time 

Other can do postmessage make own when onshow.

May be is many more solution....

[furious programming]

May be is many more solution....

All I need is one, that works on macOS. 

[Thausand]

All I need is one, that works on macOS. 

hehe 

All example write have lazarus api. If no work then api error and make report bug 

Can make easy test example things i write, and may be someone macOS make test for you ?  I think many safe is application.onidle ?

add:
here find qeueasynccall example https://forum.lazarus.freepascal.org/index.php/topic,44908.msg317303.html#msg317303

any can test macos. If framecount write then work 

[furious programming]

here find qeueasynccall example https://forum.lazarus.freepascal.org/index.php/topic,44908.msg317303.html#msg317303

I know how to use QueueAsyncCall, but I do not know if it can solve the problem on macOS.

Ok, I prepared the test of the QueueAsyncCall — sources in the attachment. If it will work on macOS (and other non-Windows systems) and show the message box over the main form, then I will implement it in the game project. Just test it and tell me if it work or not.

[Thausand]

I know how to use QueueAsyncCall, but I do not know if it can solve the problem on macOS.

Ok then wait macos and test see ...

Test i know work raspbian and make complete i post attach.

I make sure write raspbian have problem first level play meadow and have no path/bump that can walk see. I still no found problem. Is complicate when intro level work ok no problem 

[furious programming]

So, the test on the macOS will be a moment of truth.