Mac OS X Port
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.
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.98KiB)Downloaded 497 times
Re: Mac OS X Port
Hi Stephen!
I've looked at your patch, which (with the little Apple knowledge that I have) already looks very promising!
I've looked at your patch, which (with the little Apple knowledge that I have) already looks very promising!
Hmmm. This somewhat surprises me...but it turns out that Mac OS X's X server doesn't support GL
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.so I'll probably have to go ahead and write a Cocoa backend to the SingleOpenGLWindowT class in Libs using Objective-C++
Best regards,
Carsten
Carsten
Re: Mac OS X Port
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 gamesCarsten wrote:Hmmm. This somewhat surprises me...but it turns out that Mac OS X's X server doesn't support GL
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.
Re: Mac OS X Port
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.
The only caveat is that you have to dynamically link it for commercial products (it's LGPL), but that's not really an issue.
Re: Mac OS X Port
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).
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).
Re: Mac OS X Port
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.
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
Carsten
Re: Mac OS X Port
No problem!Carsten wrote: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.[/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++).
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.Carsten wrote:(Btw., isn't Mac OS like Linux built "on top" of X as well??)
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.
Re: Mac OS X Port
Ah, thanks for the subsystems / APIs overview!
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.
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?)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,
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
Carsten
Re: Mac OS X Port
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.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.
Re: Mac OS X Port
Well, after a bit of hacking I've got most of the executables and external libs working. CaWE is having a problem though:
Any ideas?
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.
Re: Mac OS X Port
Dear Stephen,
If so, try this patch (untested):
this is svn-head (currently r41), right?Stephen wrote:Any ideas?
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
Carsten
Re: Mac OS X Port
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...
Any idea why I'm getting all these errors? Ignore the re-definition, I fixed that...
- Attachments
-
- build2.log
- (78.23KiB)Downloaded 491 times
Re: Mac OS X Port
Hi Stephen,
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?
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.Any idea why I'm getting all these errors?
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
Carsten
Re: Mac OS X Port
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.
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.
Re: Mac OS X Port
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:
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:
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.
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
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
If you can find this GetProcAddress function (the Mac OS X docs should mention it), this might be the best approach.
Best regards,
Carsten
Carsten
Who is online
Users browsing this forum: No registered users and 10 guests