Mac OS X Port

Get technical support about the C++ source code and about Lua scripts for maps, entities, GUIs, the console, materials, etc. Also covered are the Cafu libraries and APIs, as well as compiling, linking, and the build system.
User avatar
Stephen
Posts: 75
Joined: 2006-05-01, 06:34
Location: Australia
Contact:

Mac OS X Port

Post by Stephen » 2010-01-11, 14:25

I worked a little on getting Cafu working on Mac OS X, and I can see that it's probably going to be more complex that I first thought. I had hoped that I could (initially) use X, which would be far less work, but it turns out that Mac OS X's X server doesn't support GL, so I'll probably have to go ahead and write a Cocoa backend to the SingleOpenGLWindowT class in Libs using Objective-C++, which will probably be fairly complex, but I've played with this kind of stuff on OS X before so it shouldn't be too difficult.

I have done a little work on the build system that adds Mac OS X (darwin) as a supported platform in scons and I've got a bunch of object files and four static libraries compiling. It stops at OpenGLWindow.cpp at the moment so it could probably at least compile more libraries if I stubbed out an empty backend.
Attachments
darwin1.patch.txt
Initial patch gets some static libs compiling
(10.98 KiB) Downloaded 164 times
User avatar
Carsten
Site Admin
Posts: 2160
Joined: 2004-08-19, 13:46
Location: Germany
Contact:

Re: Mac OS X Port

Post by Carsten » 2010-01-12, 00:51

Hi Stephen!

I've looked at your patch, which (with the little Apple knowledge that I have) already looks very promising! :up:
but it turns out that Mac OS X's X server doesn't support GL
Hmmm. This somewhat surprises me...
so I'll probably have to go ahead and write a Cocoa backend to the SingleOpenGLWindowT class in Libs using Objective-C++
Why Objective-C++ ? Have you considered writing a wxWidgets backend instead? This would replace the current somewhat cumbersome OS event loop handling under all platforms with wxWidgets code, which I believe might achieve a comparable performance than the native (or rather: self-written) code. It would of course require to compile wxWidgets as well, but for CaWE, that would be needed anyways.
Best regards,
Carsten
User avatar
Stephen
Posts: 75
Joined: 2006-05-01, 06:34
Location: Australia
Contact:

Re: Mac OS X Port

Post by Stephen » 2010-01-12, 10:16

Carsten wrote:
but it turns out that Mac OS X's X server doesn't support GL
Hmmm. This somewhat surprises me...
I might be wrong, because this article makes it look like it is available, but I can't find the header file... I wouldn't be too suprised if it wasn't there too, because it's just there for compatibility with Unix apps, so I think they expect people making games

Wx is probably a good idea - I haven't really looked at it yet but I know there are Mac backends included with it so it's probably a good solution. Otherwise, I wouldn't be too worried using Objective-C++, since it's exactly the same as C++, but it lets you use the Objective-C libraries. I'll try and do some more tonight and check back.
User avatar
Stephen
Posts: 75
Joined: 2006-05-01, 06:34
Location: Australia
Contact:

Re: Mac OS X Port

Post by Stephen » 2010-01-12, 14:00

Also, SDL could be an option - it has Windows, Mac OS and Linux backend. I'm going to investigate OpenGL in WxWidgets, but I'm guessing that using SDL is probably going to be simpler - the base part (a 350 kb DLL on Windows) essentially just has window management (it just takes a few lines of code to get a full screen OpenGL surface), event handling and timers, which is probably a good fit. There are also some things like a threading abstraction, which could be useful, and some audio and image processing stuff that we wouldn't use because what Ca3D has is already far more powerful.

The only caveat is that you have to dynamically link it for commercial products (it's LGPL), but that's not really an issue.
User avatar
Stephen
Posts: 75
Joined: 2006-05-01, 06:34
Location: Australia
Contact:

Re: Mac OS X Port

Post by Stephen » 2010-01-12, 15:35

And, an update - I now have more libraries compiling! libcfsCoreLib.a, libcfsLib.a, libMatSys.a, libSceneGraph.a and libSoundSys.a. I worked out how to get glx included (turns out that you just have to add an include path), but it's still probably a good idea to eventually move to another method like SDL or WxWidgets that wrap around the OS's native interfaces instead of using X.

I haven't got any of the dynamic libraries going yet, since I need to work out how to get OpenAL working (I'm pretty sure there's a SDK or framework somewhere).
User avatar
Carsten
Site Admin
Posts: 2160
Joined: 2004-08-19, 13:46
Location: Germany
Contact:

Re: Mac OS X Port

Post by Carsten » 2010-01-12, 17:36

Hi Stephen,
thanks for the good news!!

The reason why I asked about Objective C++ is that it would create another (big) dependency, wouldn't it? I.e. everyone would have to have the entire Objective-C++ development environment setup in order to use it, which can in general be a quite heavyweight burden that would be worthwhile to avoid.

The same is true for any external library: each creates a new dependency, and thus adding new ones should be avoided whenever possible, or added only when they bring enough benefit to justify the additional "payload".

SDL might still be an option, but then it is probably a wrapper around the native OS API as well. The fact that it's LGPL is not a problem though, as static linking is in compliance with the LGPL, see http://teem.sourceforge.net/lgpl.html for details.
(Btw., isn't Mac OS like Linux built "on top" of X as well??)

Regarding OpenAL, your best starting point is probably the OpenAL website, which seems to have an OpenAL installer for Mac OS X.
Best regards,
Carsten
User avatar
Stephen
Posts: 75
Joined: 2006-05-01, 06:34
Location: Australia
Contact:

Re: Mac OS X Port

Post by Stephen » 2010-01-13, 11:22

Carsten wrote:Hi Stephen,
thanks for the good news!!
No problem!

The reason why I asked about Objective C++ is that it would create another (big) dependency, wouldn't it? I.e. everyone would have to have the entire Objective-C++ development environment setup in order to use it, which can in general be a quite heavyweight burden that would be worthwhile to avoid.[/quote]

If I was to make a native Mac OS backend, only the Mac OS X version would need to compile the Objective-C++ file (which would only implement the Mac specific methods while the regular C++ one implemented the common parts as well as Windows and Linux versions). So it wouldn't make a difference to the other platforms, and wouldn't matter on Mac OS X since the development tools are already there.

But I agree that it's a better idea to use WxWidgets or SDL to abstract the platform specific stuff, and then it can have a single implementation shared between Windows, Mac OS X and Linux (in regular, portable C++).
Carsten wrote:(Btw., isn't Mac OS like Linux built "on top" of X as well??)
No, Apple have their own display layer called Quartz. Native applications are generally written in Cocoa, which is the main toolkit, using the Objective-C language (which is an object oriented version of C but has quite different syntax). There's also Objective-C++ which is just C++ with the ability to make calls to Objective-C libraries, and then other people have written bindings for other languages like Python and Mono. Most cross-platform toolkits like WxWidgets and SDL wrap around Cocoa too.

Then there's the Carbon framework, which is an older framework designed for compatibility with the older versions of Mac OS X. It's not used much anymore since it doesn't have a 64 bit version.

Finally, X is available for backwards compatibility with older UNIX apps. The apps run on a rootless X server so you can have both normal apps and X apps (a bit like some X servers you can download on Windows).

Anyway, I'm going to try and get OpenAL working and also have a play around with OpenGL in WxWidgets.
User avatar
Carsten
Site Admin
Posts: 2160
Joined: 2004-08-19, 13:46
Location: Germany
Contact:

Re: Mac OS X Port

Post by Carsten » 2010-01-13, 12:30

Ah, thanks for the subsystems / APIs overview!
Stephen wrote: But I agree that it's a better idea to use WxWidgets or SDL to abstract the platform specific stuff, and then it can have a single implementation shared between Windows, Mac OS X and Linux (in regular, portable C++).
[...]
No, Apple have their own display layer called Quartz. Native applications are generally written in Cocoa,
Hmmm, I just read the Wikipedia article about Quartz when I from there also found the link to CGL, which is probably what both SDL and wxWidgets use for their implementation. Wouldn't this be the "right" API in the sense that it is the system native one that we're looking for? (assuming the Mac OS X implementation should be equivalently OS-specific than those under Windows and Linux?)

It's just a question/suggestion, and CGL might be harder to setup initially, but (from my experience with WGL and XGL) might be easier to debug and trouble-shoot when there is no extra layer of abstraction, and it should be possible to find examples or tutorials for its use.
Best regards,
Carsten
User avatar
Stephen
Posts: 75
Joined: 2006-05-01, 06:34
Location: Australia
Contact:

Re: Mac OS X Port

Post by Stephen » 2010-01-13, 15:02

Carsten wrote:Hmmm, I just read the Wikipedia article about Quartz when I from there also found the link to CGL, which is probably what both SDL and wxWidgets use for their implementation. Wouldn't this be the "right" API in the sense that it is the system native one that we're looking for? (assuming the Mac OS X implementation should be equivalently OS-specific than those under Windows and Linux?)

It's just a question/suggestion, and CGL might be harder to setup initially, but (from my experience with WGL and XGL) might be easier to debug and trouble-shoot when there is no extra layer of abstraction, and it should be possible to find examples or tutorials for its use.
Good idea - I hadn't thought of that. Also, since CGL is lower level than Carbon and Cocoa, it's a C library, which will keep the code all in the C++ file. I think that if we only need fullscreen, CGL can handle mode setting and everything else needed.
User avatar
Stephen
Posts: 75
Joined: 2006-05-01, 06:34
Location: Australia
Contact:

Re: Mac OS X Port

Post by Stephen » 2010-01-14, 10:48

Well, after a bit of hacking I've got most of the executables and external libs working. CaWE is having a problem though:

Code: Select all

CaWE/AppCaWE.cpp: In member function 'virtual bool AppCaWE::OnInit()':
CaWE/AppCaWE.cpp:157: error: invalid initialization of reference of type 'const wxString&' from expression of type 'std::basic_string<char, std::char_traits<char>, std::allocator<char> >'
ExtLibs/wxWidgets/include/wx/msgdlg.h:326: error: in passing argument 1 of 'int wxMessageBox(const wxString&, const wxString&, long int, wxWindow*, int, int)'
CaWE/AppCaWE.cpp:207: error: no matching function for call to 'wxBitmap::wxBitmap(std::basic_string<char, std::char_traits<char>, std::allocator<char> >, wxBitmapType)'
ExtLibs/wxWidgets/include/wx/osx/bitmap.h:112: note: candidates are: wxBitmap::wxBitmap(const wxIcon&)
ExtLibs/wxWidgets/include/wx/osx/bitmap.h:109: note:                 wxBitmap::wxBitmap(const wxImage&, int)
ExtLibs/wxWidgets/include/wx/osx/bitmap.h:106: note:                 wxBitmap::wxBitmap(const wxSize&, int)
ExtLibs/wxWidgets/include/wx/osx/bitmap.h:105: note:                 wxBitmap::wxBitmap(int, int, int)
ExtLibs/wxWidgets/include/wx/osx/bitmap.h:102: note:                 wxBitmap::wxBitmap(const void*, wxBitmapType, int, int, int)
ExtLibs/wxWidgets/include/wx/osx/bitmap.h:99: note:                 wxBitmap::wxBitmap(const wxString&, wxBitmapType)
ExtLibs/wxWidgets/include/wx/osx/bitmap.h:96: note:                 wxBitmap::wxBitmap(const char* const*)
ExtLibs/wxWidgets/include/wx/osx/bitmap.h:93: note:                 wxBitmap::wxBitmap(const char*, int, int, int)
ExtLibs/wxWidgets/include/wx/osx/bitmap.h:90: note:                 wxBitmap::wxBitmap()
ExtLibs/wxWidgets/include/wx/osx/bitmap.h:84: note:                 wxBitmap::wxBitmap(const wxBitmap&)
scons: *** [build/darwin/g++/release/CaWE/AppCaWE.o] Error 1
scons: building terminated because of errors.
Any ideas?
User avatar
Carsten
Site Admin
Posts: 2160
Joined: 2004-08-19, 13:46
Location: Germany
Contact:

Re: Mac OS X Port

Post by Carsten » 2010-01-14, 18:23

Dear Stephen,
Stephen wrote:Any ideas?
this is svn-head (currently r41), right?
If so, try this patch (untested):

Code: Select all

Index: CaWE/AppCaWE.cpp
===================================================================
--- CaWE/AppCaWE.cpp    (Revision 41)
+++ CaWE/AppCaWE.cpp    (Arbeitskopie)
@@ -154,7 +154,7 @@

     // Register the material script with the CaWE materials definitions.
     if (MaterialManager->RegisterMaterialScript(AppDir+"/res/CaWE.cmat", AppDir+"/res/").Size()==0)
-        wxMessageBox("CaWE.cmat not found in \""+AppDir+"\".", "WARNING");
+        wxMessageBox(wxString("CaWE.cmat not found in \"")+AppDir+"\".", "WARNING");


     // Create the MDI parent frame.
@@ -203,7 +203,7 @@
     // Show the splash screen.
     // printf("%s   Before Splash\n", wxNow().c_str());
     wxBusyCursor BusyCursor;
-#ifndef __WXGTK__
+#ifdef __WXMSW__
     wxSplashScreen SplashScreen(wxBitmap(AppDir+"/res/CaWE-logo.png", wxBITMAP_TYPE_PNG),
                                 wxSPLASH_CENTRE_ON_PARENT | wxSPLASH_NO_TIMEOUT, 250, m_ParentFrame, -1);
 #endif
Best regards,
Carsten
User avatar
Stephen
Posts: 75
Joined: 2006-05-01, 06:34
Location: Australia
Contact:

Re: Mac OS X Port

Post by Stephen » 2010-03-10, 14:47

It's been a while, but I took a look at the code today.

Any idea why I'm getting all these errors? Ignore the re-definition, I fixed that...
Attachments
build2.log
(78.23 KiB) Downloaded 149 times
User avatar
Carsten
Site Admin
Posts: 2160
Joined: 2004-08-19, 13:46
Location: Germany
Contact:

Re: Mac OS X Port

Post by Carsten » 2010-03-10, 16:55

Hi Stephen,
Any idea why I'm getting all these errors?
Starting at the top, the #else ... #endif clause in OpenGLEx.cpp, starting in line 34, is certainly a problem, because it is specific to Linux.

Without having a Mac available, it's difficult to be more specific, but in general, a way is required for accessing the OpenGL extensions.

If I understand http://rainwarrior.thenoos.net/dragon/sdl_glsl.html and the Mac OS X OpenGL Extensions Guide right, getting the function pointers as is done in OpenGLEx.hpp/cpp is not necessary under Mac OS X at all, as it is sufficient there to include the proper headers.

Does that help?
Best regards,
Carsten
User avatar
Stephen
Posts: 75
Joined: 2006-05-01, 06:34
Location: Australia
Contact:

Re: Mac OS X Port

Post by Stephen » 2010-03-11, 02:21

Yep, that makes sense. Now the only problem I'm having is trying to get those functions in the cf namespace... Hopefully I don't have to do a bunch of inline functions, but I may have to.

This is because the header has extern "c" around all the functions, so it doesn't work if I put the include inside the namespace.
User avatar
Carsten
Site Admin
Posts: 2160
Joined: 2004-08-19, 13:46
Location: Germany
Contact:

Re: Mac OS X Port

Post by Carsten » 2010-03-12, 02:24

Hi Stephen,

well, as mentioned before, without having an actual Mac system available, it's hard to make suggestions, but I'll try two shots into the blue anyway: ;-)

Assuming that the functions are actually predefined by the Mac OS X headers, and assuming that the declarations of the function signatures are compatible or match, you could just do something like this:

Code: Select all

#ifdef _WIN32 || __LINUX__   // Condition not checked, maybe something like #ifndef APPLE is better
    cf::glMultiTexCoord2dARB=(PFNGLMULTITEXCOORD2DARBPROC)GetProcAddress((StringPtr)"glMultiTexCoord2dARB");
    // [...]
#else
    // The new code for Mac OS X.
    cf::glMultiTexCoord2dARB=glMultiTexCoord2d;
    // [...]
#endif
This is not particularly beautiful (another bunch of #if ... #endif clauses), but very simple and straightforward.
The disadvantage (besides the #if ...) is that some of the extensions may be predefined in the header files, others may not.

Therefore, the alternative and second suggestion is to add a third case for Mac OS X to this statement near the beginning of OpenGLEx.cpp:

Code: Select all

#ifdef _WIN32
    #define GetProcAddress wglGetProcAddress
    #define StringPtr      const char*
#else
    // Don't confuse glx with glext...
    #define GLX_GLXEXT_LEGACY
    #include <GL/glx.h>

    #define GetProcAddress glXGetProcAddressARB
    #define StringPtr      const GLubyte*
#endif
I.e. you need to find the Mac-equivalent for wglGetProcAddress / glXGetProcAddressARB. This is universal and would require no changes to the rest of the code at all, afaics.
If you can find this GetProcAddress function (the Mac OS X docs should mention it), this might be the best approach.
Best regards,
Carsten
Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest