Phoenix, Asphyre or Andorra on Mac OS

[wagenheimer]

Somebody here get some success on running Phoenix, Asphyre or Andorra on Mac Os?

- Andorra 2D, it compiles, but when I did run it shows nothing.
- Phoenix, it almost compiles, I did get Linker error.
- Asphyre, still need some conversion to become Linux/Mac Os compatible.

Anybody here have some success with some of this engines in Mac Os?

[igel457]

Andorra 2D should work if you use the GLFW or SDL windowframework (the LCL TOpenGLContext, which is used by default does not work on MacOS, if I'm well informed).

Information about how to use other "windowframeworks" can be found in the "SimpleNoVCL" demo. Simply include "AdSDL" or "AdGLFW" instead of "AdStdWindow".

For me it would be very nice to know whether Andorra 2D runs on MacOS as I don't own a Mac (and don't plan to obtain one...).

[Stoney]

Aspyhre won't work on a Mac, because as far as I know, Aspyre just uses DirectX and DirectX is Windows-only.

Andorra 2D should work if you use the GLFW or SDL windowframework (the LCL TOpenGLContext, which is used by default does not work on MacOS, if I'm well informed).

Information about how to use other "windowframeworks" can be found in the "SimpleNoVCL" demo. Simply include "AdSDL" or "AdGLFW" instead of "AdStdWindow".

For me it would be very nice to know whether Andorra 2D runs on MacOS as I don't own a Mac (and don't plan to obtain one...).

GLFW won't work by default. You need to modify following lines in the glfw.pas (Line 356f.). Originally, it should look like this:

const
{$IFDEF WIN32}
 DLLNAME = 'glfw.dll';
{$ELSE}
 DLLNAME = 'libglfw.so';
{$ENDIF}

Now it need to look like this:

const
{$IFDEF WIN32}
 DLLNAME = 'glfw.dll';
{$ELSE}
 {$IFDEF DARWIN}
 DLLNAME = 'libglfw.dylib';
 {$ELSE}
 DLLNAME = 'libglfw.so';
 {$ENDIF}
{$ENDIF}

Now you need to get libglfw.dylib. There are two possibilites to do that: Install Fink and download libglfw.dylib and then configure to link against /sw/lib (if that's the directory where you put Fink) or download the source package from the GLFW homepage and compile it yourself. (You need to link against the library, of course.)
When deploying your application, don't forget to leave the path to your library relative or others can't use your application if they don't have Fink installed.
(The better way would be to build a GLFW.framework, I guess, it should work like described above, but I couldn't test it yet.)

As for Andorra2D, I tried a few things, but I couldn't get it to work. Yet. I will try harder once my exams are over.

Phoenix2D should work with the fix described in this post, but I wouldn't recommand to use GLFW on a Mac, because it uses the old Carbon interface, which is an old artefact from Mac OS 9 - times and is still supported in Snow Leopard, but who knows, what will happen with Carbon in Mac OS 10.7?
Furthermore, the GLFW Object Pascal port hasn't been updated since 2005 if I recall correctly.

The safest bet is to use SDL (and/or OpenGL) which uses Cocoa (introduced with Mac OS X and a lot more future-proof than Carbon). This is the combination I'm using at the moment and built a little framework around it, you can check some of the games on my blog and recently my framework has been used for a semi-commercial product.
I'm not quite sure if my framework would fit your needs since I designed it espacially for prototyping and rapid game development.


Update: I tried to port Phoenix in the last hours. Unfortunately without any success and tried the two latest beta versions. There are following problems:
- dglOpenGL.pas needs to be modified like described here: http://delphigl.com/forum/viewtopic....&highlight=mac (last post)
- The FreeImage Delphi Wrapper only supports Windows and is not designed to be platform-independant, there are too many dependencies on Windows.pas
- Also there is no equivalent for getTickCount, so phxTimer won't work

[Andreaz]

Phoenix2D should work with the fix described in this post, but I wouldn't recommand to use GLFW on a Mac, because it uses the old Carbon interface, which is an old artefact from Mac OS 9 - times and is still supported in Snow Leopard, but who knows, what will happen with Carbon in Mac OS 10.7?
Furthermore, the GLFW Object Pascal port hasn't been updated since 2005 if I recall correctly.

The safest bet is to use SDL (and/or OpenGL) which uses Cocoa (introduced with Mac OS X and a lot more future-proof than Carbon). This is the combination I'm using at the moment and built a little framework around it, you can check some of the games on my blog and recently my framework has been used for a semi-commercial product.
I'm not quite sure if my framework would fit your needs since I designed it espacially for prototyping and rapid game development.

I have added a SDL renderer to Phoenix in the latest version (the demo 13_Device.SDL), if you feel like it test it out
http://phoenixlib.net/files/Phoenix%202009-07-30.7z

It uses GraphicEx for the image loading so no need for Freeimage.dll either.

[pstudio]

Hi Andreaz,
I tried out the latest Phoenix and it is looking great.

However I'm having some trouble using it with Turbo Delphi on Windows. If I try and run and debug the Template example I get an access violation. But if I just build it and run it through Windows it works fine. Have you experienced any like that? The previous versions of Phoenix didn't have this problem.

EDIT:

It turns out the access violation happens when the OGL renderer calls glfwOpenWindow() which seems pretty strange to me.

I think I'll move this to it's own topic since it is a bit offtopic.

[Stoney]

I clearly underestimated the amount of time it would take to port one of these engines to Mac OS X.
But it's not all bad news, I updated the GLFW header from API version 2.5 to 2.6 and it's now cross-platform, works with Delphi and FreePascal on Windows, Linux and most important Mac OS X. Furthermore, I modified the dglOpenGL header to work correctly with GLFW on Linux and Mac OS X.
I also converted the Mipmaps example from C to Object Pascal.
Take a look at my blog post or download the updated glfw.pas here.

[wagenheimer]

Hi Stoney!

Have you any success in making the Phoenix run in Mac OS I'm still with some big problems...

There are a solution for the GetTickCount Problem.

http://forum.lazarus.freepascal.org/...p?topic=6099.0

[Stoney]

I haven't had much success yet.
I've used Andreaz Phoenix version from 09-07-30. The problem with GetTickCount has been solved.

I tried to get the DeviceSDL sample to work.
But there are still some other problems:
- GraphicEx doesn't really work on Mac OS X:
-- The included JPG unit doesn't work
-- Asm calls can't be used on Mac OS X (e.g. GraphicColor.pas)
-- The Convert16_8/Convert16_8Alpha for example won't work. Errors:
[code=pascal]
/Users/.../GraphicColor.pas(649,33) Error: Illegal qualifier
/Users/.../GraphicColor.pas(649,33) Hint: may be pointer dereference is missing
/Users/.../GraphicColor.pas(649,33) Error: Illegal expression
/Users/.../GraphicColor.pas(649,33) Fatal: Syntax error, ";" expected but "identifier R" found
[/code]
-- Compression doesn't work

So, I tried to get an empty window to work. But still, I got a linker error:
[code=pascal]
Undefined symbols:
"_iconv_close", referenced from: _CWSTRING_FINITHREAD in cwstring.o _CWSTRING_FINITHREAD in cwstring.o
"WSRegisterMenuItem", referenced from: _WSMENUS_REGISTERMENUITEM in wsmenus.o
"WSRegisterHintWindow", referenced from: _WSFORMS_REGISTERHINTWINDOW in wsforms.o
"WSRegisterPopupMenu", referenced from: _WSMENUS_REGISTERPOPUPMENU in wsmenus.o
"WSRegisterWinControl", referenced from: _WSCONTROLS_REGISTERWINCONTROL in wscontrols.o
"WSRegisterCustomForm", referenced from: _WSFORMS_REGISTERCUSTOMFORM in wsforms.o
"WSRegisterMainMenu", referenced from: _WSMENUS_REGISTERMAINMENU in wsmenus.o
"WSRegisterControl", referenced from: _WSCONTROLS_REGISTERCONTROL in wscontrols.o
"WSRegisterCustomImageList", referenced from: _WSIMGLIST_REGISTERCUSTOMIMAGELIST in wsimglist.o
"WSRegisterCustomControl", referenced from: _WSCONTROLS_REGISTERCUSTOMCONTROL in wscontrols.o
"_iconv_open", referenced from: _CWSTRING_INITTHREAD in cwstring.o _CWSTRING_INITTHREAD in cwstring.o
"WSRegisterGraphicControl", referenced from: _WSCONTROLS_REGISTERGRAPHICCONTROL in wscontrols.o
"WSRegisterCustomFrame", referenced from: _WSFORMS_REGISTERCUSTOMFRAME in wsforms.o
"WSRegisterScrollBox", referenced from: _WSFORMS_REGISTERSCROLLBOX in wsforms.o
"_iconv", referenced from: _CWSTRING_WIDE2ANSIMOVE$PWIDECHAR$ANSISTRING$LONGI NT in cwstring.o _CWSTRING_WIDE2ANSIMOVE$PWIDECHAR$ANSISTRING$LONGI NT in cwstring.o _CWSTRING_ANSI2WIDEMOVE$PCHAR$WIDESTRING$LONGINT in cwstring.o _CWSTRING_ANSI2WIDEMOVE$PCHAR$WIDESTRING$LONGINT in cwstring.o
"WSRegisterMenu", referenced from: _WSMENUS_REGISTERMENU in wsmenus.o
"WSRegisterScrollingWinControl", referenced from: _WSFORMS_REGISTERSCROLLINGWINCONTROL in wsforms.o
"WSRegisterDragImageList", referenced from: _WSCONTROLS_REGISTERDRAGIMAGELIST in wscontrols.o
ld: symbol(s) not found
Error: Error while linking
[/code]
So you need to add the unit Interfaces in the DeviceSDL.dpr, but still some errors left:
[code=pascal]
Undefined symbols:
"_iconv_close", referenced from: _CWSTRING_FINITHREAD in cwstring.o _CWSTRING_FINITHREAD in cwstring.o
"_iconv_open", referenced from: _CWSTRING_INITTHREAD in cwstring.o _CWSTRING_INITTHREAD in cwstring.o
"_iconv", referenced from: _CWSTRING_WIDE2ANSIMOVE$PWIDECHAR$ANSISTRING$LONGI NT in cwstring.o _CWSTRING_WIDE2ANSIMOVE$PWIDECHAR$ANSISTRING$LONGI NT in cwstring.o _CWSTRING_ANSI2WIDEMOVE$PCHAR$WIDESTRING$LONGINT in cwstring.o _CWSTRING_ANSI2WIDEMOVE$PCHAR$WIDESTRING$LONGINT in cwstring.o
ld: symbol(s) not found
Error: Error while linking
[/code]
And that's were I'm stuck right now. The curious part is, libiconv is installed on my machine and I linked to it.

Maybe it's a bug because I used a daily snapshot of Lazarus, but for some reason I can't properly uninstall Lazarus on Mac OS X and if I just replace my daily snapshot with the old 0.9.26 Lazarus, Lazarus won't start.

[Traveler]

Hi Stoney, I've modified your reply so that the pascal code becomes more clear.

[Andreaz]

Could it be something like this bug that we have bumped into?

http://bugs.freepascal.org/view.php?id=11565