Page 1 of 2 12 LastLast
Results 1 to 20 of 32

Thread: ClanLib 2 OS X Snow Leopard (Macintosh)

  1. #1

    Default ClanLib 2 OS X Snow Leopard (Macintosh)

    Hi all,
    Anyone know what the state is of ClanLib on the Macintosh? I see that SDL 1.3 is up to date for the Mac side of things... What needs to be done with ClanLib? I take it there is no active maintainer?

  2. #2
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,824

    Default

    As far as I know, no developers are working on the mac.

    See - http://www.rtsoft.com/forums/showthread.php?p=9783

  3. #3

    Default Working on Mac port

    Hi. I'm trying to do a Mac port of CL 2.2.0 I'm not a ninja Mac programmer (lots of other experience, but little Mac ), so if you have any solid Mac skills and could help getting ClanLib using Cocoa then perhaps reply to this thread and perhaps I can use your advice or you can send patches.

    So far I've got a few of the frameworks compiling and linking and am starting to get one of the tests, Display 2D, working. All source is in the Subversion repo at the moment.

    There are some starter notes here: http://chinbilly.blogspot.com/2010/0...c-osx-106.html

    The SourceForge project is here: https://sourceforge.net/projects/gameres/

    SVN repo is here: http://gameres.svn.sourceforge.net/v.../ClanLib22osx/

    I was using Allegro (4.4), which does use Cocoa, but is missing loads of features (GUI, fonts, etc) that ClanLib has. I don't have an infinite amount of spare time so be patient! One idea is to make CL use the internals of Allegro to implement the Mac version. I don't see this as so different from using SDL, which I think the previous working version of CL did (0.8?). But SDL now has an LGPL licence so that doesn't play so well with more liberal licenses in CL and Allegro.

  4. #4
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,824

    Default

    Awesome

    You can also use the ClanLib 1.0 OS X source code as reference. It "should" contain most of the functions required. (as far as I know)

    You probably have discovered, the OS X source in the ClanLib 2.2 release has not been updated for over 4 years, and will be totally broken.

    ClanLib 0.8 (1.0) does not require SDL.
    Last edited by rombust; 08-03-2010 at 06:53 AM. Reason: spelling mistake

  5. #5
    Administrator Seth's Avatar
    Join Date
    Jul 2002
    Location
    Japan
    Posts
    5,345

    Default

    Good to hear someone is brave enough to tackle it. Keep us posted!
    Seth A. Robinson
    Robinson Technologies

  6. #6

    Default A few thoughts

    Hi,

    i appreciate your work !

    I was working on porting some stuff over to OS X last year, building the required libs as frameworks (libxml2, pcre etc.). Additionally i was discussing a port with Magnus. What has to be rewritten, changed and so on, as the old broken stuff is based on AGL.
    So basically it has to be re-implemented to NSOpenGL and CGL.
    Well, it depends on how much you want to rely on Core. But i guess you just want to do a OS X Rendertarget.
    Regarding the Target, rewriting the AGL stuff would do, no?

    I was reading your blogpost. It seems you are not going for frameworks? You are just compiling the libs the UNIX way (standard locations/structures like /usr/local etc. regarding the libs and includes).
    On Mac i would definitely go for the frameworks, which is better for making user-installable software packages. The Fink or MacOSPorts way was not intended for the Mac

    I was using Allegro (4.4), which does use Cocoa, but is missing loads of features (GUI, fonts, etc) that ClanLib has. I don't have an infinite amount of spare time so be patient! One idea is to make CL use the internals of Allegro to implement the Mac version. I don't see this as so different from using SDL, which I think the previous working version of CL did (0.8?). But SDL now has an LGPL licence so that doesn't play so well with more liberal licenses in CL and Allegro.
    Do you think it's a good idea to bring in a 3rd party "game/graphics" lib (allegro) as a base of another "game/graphics" lib (clanlib)?
    If Allegro is braking some stuff, clanlib also does. You have to deal with bugs in an additional library.

    If SDL and their LGPL-License is a problem for you, you can still try SFML.
    SFML is C++, may be even faster, more convenient and uses the zlib/png License.

    Allegro is basically a 2D Library (Quartz is for 2D), but clanlib is also utilizing 3D, so you also have to rely on AllegroGL. OpenGL is only fully supported with Allegro5.

    Although this "Porting Games to Mac OS X" Guide from GDC is from 2001, it is worth a read
    http://www.omnigroup.com/ftp/pub/sof...rtingToOSX.pdf

    Nevertheless, hang on to it
    Cheers.

  7. #7

    Smile

    Quote Originally Posted by iQD View Post
    i appreciate your work !
    Thanks, and thanks for the GDC link, that looks very useful.

    as the old broken stuff is based on AGL. So basically it has to be re-implemented to NSOpenGL and CGL.
    As I understand it yes, I believe AGL is a Carbon API and NS and CGL are Cocoa. CGL is the underlying common API, but I think you have to be careful about mixing the two together, i.e. you either choose NS or CGL. As a reference I found Allegro and Irrlicht. Allegro seems to use NS and Irrlicht seems to use CGL. I was thinking of using NS.

    I was reading your blogpost. It seems you are not going for frameworks? You are just compiling the libs the UNIX way (standard locations/structures like /usr/local etc. regarding the libs and includes).
    This is mainly because I'm not sure how to make them. It is easy to unzip the required libraries, build and install them (to /usr/local). Is there some sort of tool for automatically creating frameworks?

    On Mac i would definitely go for the frameworks, which is better for making user-installable software packages. The Fink or MacOSPorts way was not intended for the Mac
    I agree. I don't want a competing build environment on my Mac, but /usr/local isn't Fink, or MacPorts, it is native Mac, just not frameworks. I do not have Fink or MacPorts installed. I was thinking that the frameworks would be local anyway (like I think they were in Clanlib 0.8), so I don't see much difference if I provide pre-compiled Mac static libs anyway. ?

    Do you think it's a good idea to bring in a 3rd party "game/graphics" lib (allegro) as a base of another "game/graphics" lib (clanlib)?
    Mmmm that was an idea I was toying with, but I think it will create problems, and ClanLib is a nicely engineered library, so it would be good to keep it that way, not a hacked up hybrid. I was thinking initially I could hack in an Allegro framework that CL uses and if that was successful then pull out that required functionality and put it in CL. I believe a previous version of Clanlib incorporated SDL, so it has been done before, but I think Allegro is probably too archaic to include.

    If SDL and their LGPL-License is a problem for you, you can still try SFML.
    SFML is C++, may be even faster, more convenient and uses the zlib/png License.
    Thanks for that. I did not know that library. I will take a look.

    Allegro is basically a 2D Library (Quartz is for 2D), but clanlib is also utilizing 3D, so you also have to rely on AllegroGL. OpenGL is only fully supported with Allegro5.
    AllegroGL has been part of Allegro since something like 4.3/4.4, but it is a plug-in. I liked Allegro because it was one of the few cross platform Mac libraries that used Cocoa and seemed quite simple. I put notes on my blog.

    I'll keep plodding on with the port. If you read the check-in comments you see the progress. It might be a couple of weeks before I have something working. It is useful to have all this reference code to use. Cheers!

  8. #8

    Default

    Quote Originally Posted by Chin Billy View Post
    As I understand it yes, I believe AGL is a Carbon API and NS and CGL are Cocoa. CGL is the underlying common API, but I think you have to be careful about mixing the two together, i.e. you either choose NS or CGL. As a reference I found Allegro and Irrlicht. Allegro seems to use NS and Irrlicht seems to use CGL. I was thinking of using NS.
    Well, CGL is the low level API.
    AGL (Carbon) and NS (Cocoa) are the high level classes.
    Irrlicht just takes advantage of the faster low level API instead of using the high level NS classes. Additionally Irrlicht is more targeted to a full-screen application, rather than a windowed one.
    Basically NS is for drawing into a view (every NS context has a CGL context) and CGL is for creating a full-screen content.

    You may want to take a look here:
    http://developer.apple.com/mac/libra..._concepts.html
    http://developer.apple.com/mac/libra...l_drawing.html

    This is mainly because I'm not sure how to make them. It is easy to unzip the required libraries, build and install them (to /usr/local). Is there some sort of tool for automatically creating frameworks?
    Well, the compiler and the dynamic linker is searching for the frameworks in specific areas. So it's more convenient if you are working with developer tools that came with a Mac (f.e. XCode), manage different versions or targets.
    It's just copying and pasting the framework into the specific location (although you can create an installer). No unzipping or building fuzz

    Unfortunately there is no tool for creating frameworks. You have to use XCode and the framework templates for carbon/cocoa instead.
    http://developer.apple.com/mac/libra...02258-BAJDHDAF

    I agree. I don't want a competing build environment on my Mac, but /usr/local isn't Fink, or MacPorts, it is native Mac, just not frameworks. I do not have Fink or MacPorts installed. I was thinking that the frameworks would be local anyway (like I think they were in Clanlib 0.8), so I don't see much difference if I provide pre-compiled Mac static libs anyway. ?
    You're right with /usr/local etc., but as Mac OS X makes extensive use of frameworks to distribute shared code and resource, it think it's cleaner to follow that system.
    The difference between pre-compiled Mac static libs and frameworks is to have the resources, libs, headers etc. in one place, the framework bundle. It wraps the library's required files and metadata.

    A framework is a hierarchical directory that encapsulates shared resources, such as a dynamic shared library, nib files, image files, localized strings, header files, and reference documentation in a single package.
    I was thinking initially I could hack in an Allegro framework that CL uses and if that was successful then pull out that required functionality and put it in CL. I believe a previous version of Clanlib incorporated SDL, so it has been done before, but I think Allegro is probably too archaic to include.
    It may be a possibility, yes. I never used Allegro, but from what i can read in the docs, it's lacking a lot of the CL functionalities. So you have to adapt many features anyway.
    There was a SDL target in CL 1.x but it was dropped with CL 2.x . CL has it's own software renderer called ClanGDI.

    AllegroGL has been part of Allegro since something like 4.3/4.4, but it is a plug-in. I liked Allegro because it was one of the few cross platform Mac libraries that used Cocoa and seemed quite simple. I put notes on my blog.
    Yeah. OS X seems to be the least relevant platform with all those libraries out there.
    The Mac port of SFML came to a hold last year. They are more concentrating on SFML 2.0 and the Windows/Linux platforms than Mac.

    I'll keep plodding on with the port. If you read the check-in comments you see the progress. It might be a couple of weeks before I have something working. It is useful to have all this reference code to use. Cheers!
    Any progress is more than i can excpect

  9. #9
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,824

    Default

    I am a bit puzzled with the talk of using allegro or other library to do the GL drawing.

    (Note, I have never used OSX before)

    1) Adding an external library will add an additional layer, there would be a performance penalty
    2) ClanLib is designed so the user can call the OpenGL directly ; replacing glFunctionName with clFunctionName (GL target) or cl1FunctionName (GL1 target)
    3) I would be very surprised if the external library (if used) could manage multiple windows and sharing graphic contexts between them. afaik, SDL cannot do this.
    4) ClanLib 1.0 has AGL support. Wouldn't it be easier to just use that code? (Found in http://clanlib.org/wiki/Download )
    5) SDL was dropped because it was slow and could not cope with all of ClanLib's API


    Note, when porting, ignore all existing AGL code in clanlib 2.2. It will be easier to simply delete all of it. And build a new target using either (GL or GL1) GLX target.

    As stated earlier (item 4), copy AGL code from clanlib 1.0 into the GLX target framework (renaming GLX or otherwise)
    Last edited by rombust; 08-07-2010 at 03:21 PM.

  10. #10
    ClanLib Developer
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    554

    Default

    The AGL code is unfortunately useless because Apple decided to stop supporting Carbon for 64 bit Mac and its also not usable if one would want to target their embedded devices.

    About the frameworks part, if you are more comfortable in building it like a Unix library and have already managed to create the makefiles required, then there's no harm done in continuing. This is because the main difference between a framework bundle and a classical ELF dynamic library is where the library is located, specified to the linker as the final step.

    You can therefore do it as two step project, where you first get the actual Mac port to compile and work, and then create the XCode project and bundles as a second step. This was also in fact how I originally created the ClanLib 1 port, since I cannot stand XCode as an IDE. I know some people really like it, but personally I would rather use a text editor in a console than this application. It also has the advantage that there are a lot more people that know how to create the XCode project, so you might be able to get someone else to do this step for you.

    About the actual port, ClanLib is designed in such a way that there are only a few select classes that do the platform specific code. For example, we have CL_Win32Window and CL_X11Window that is used by clanDisplay to provide the basic services required by CL_DisplayWindow. To port it to Mac, what is required is that you create a CL_MacWindow class with the same functions as the other two and find the Mac equivalent functions to implement those functions.

    If we look at CL_Win32Window::create(CL_DisplayWindowSite *new_site, const CL_DisplayWindowDescription &description) as one of the examples, this function should create the actual window on the screen. In Windows this equals to calling CreateWindowEx and on Mac it probably equals to constructing a NSWindow cocoa object or whatever they may have named it. So that function would create such an object and store it in a member variable, to be used by the remaining functions on CL_MacWindow.

    I personally do not find any advantages in using SDL or Allegro to do these mappings, since all you do is adding additional abstractions that may not be able to do precisely what these functions ask of you. But the source code of SDL or Allegro may help you figure out which Mac functions are required to implement CL_MacWindow::create(), so in that sense they may be beneficial.

    If you have any questions about the code base, don't hesitate to ask. I'm more than willing to spend time on describing things if it helps you port ClanLib 2 to Mac.

  11. #11

    Smile

    1) Adding an external library will add an additional layer, there would be a performance penalty
    I think any performance penalty would be almost unnoticeable. You'd just have another layer of abstraction between you and the hardware. The reason for doing it was/is ease for me as I have limited playtime and want to knock up some games. I started on Allegro, but then found that it cost me more time to fix the things I'm missing (e.g. fonts and UI) than to get Clanlib working on OSX. Well that is the plan.

    3) I would be very surprised if the external library (if used) could manage multiple windows and sharing graphic contexts between them. afaik, SDL cannot do this.
    I'm assuming that if I use the NS API this will handle all the windowing and be able to handle multiple contexts for multiple windows.

    4) ClanLib 1.0 has AGL support. Wouldn't it be easier to just use that code? (Found in http://clanlib.org/wiki/Download )
    As stated, AGL is part of Carbon (32-bit API) and OSX is now 100% 64-bit, including kernel. Although apps and libs can be compiled in 32 (i386) mode. All apps must now be Cocoa (64-bit). You cannot even create a new Carbon app in the latest XCode, only Cocoa. And if you want to do iPhone, it has to be Cocoa. Personally, I just want a good library and cross platform is a bonus. Clanlib is one of the best I've found, its just a shame OSX is overlooked so much. It is a bit of a leap going from Win32 & POSIX to OSX though.

    5) SDL was dropped because it was slow and could not cope with all of ClanLib's API
    Slow?

    Note, when porting, ignore all existing AGL code in clanlib 2.2. It will be easier to simply delete all of it. And build a new target using either (GL or GL1) GLX target.
    That is the plan. I was temporarily considering making an "allegro" target and calling the internals of Allegro, rather than the public API, but I've since decided to just to try and get an NS targetted version of CL working.

  12. #12

    Cool

    About the frameworks part, if you are more comfortable in building it like a Unix library and have already managed to create the makefiles required, then there's no harm done in continuing.
    Yep. Until I get this all working they will be static libs in /usr/local. If I succeed I'll look at making frameworks.

    ... since I cannot stand XCode as an IDE.
    The IDE is a little different, although is does have some nice features once you get used to it (I think MSVC is equally "interesting" TBH). I'm quite looking forward to seeing Xcode 4.0. This is apparently all one window and may be more productive. I don't really like the multi-window paradigm (like Code Warrior).

    It also has the advantage that there are a lot more people that know how to create the XCode project, so you might be able to get someone else to do this step for you.
    With any luck Hopefully I can get something going a ninja Mac programmer will fix any issues. I'm hoping that the existing code examples I have will help enough. Allegro is pretty mature.

    To port it to Mac, what is required is that you create a CL_MacWindow class with the same functions as the other two and find the Mac equivalent functions to implement those functions.
    Will try that first. Going to try a SW renderer. All seems to compile so far. Need to get a target linking and running to test, just working out one dependency at a time.

    If you have any questions about the code base, don't hesitate to ask. I'm more than willing to spend time on describing things if it helps you port ClanLib 2 to Mac.
    Thanks for taking an interest. I'll try and find a few hours this week.

  13. #13
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,824

    Default

    Ref SDL
    Quote Originally Posted by Chin Billy View Post
    Slow?
    Off topic, but i'll try to explain the reasoning:

    Back in mid 2009, I created the SDL target for ClanLib 2.0. This was before the clanGL1 target existed and clanGDI (now clanSWRender) was in it's infancy.
    It was created to support old hardware that could not use OpenGL 2.0
    (See : http://www.rtsoft.com/forums/showthr...anLib-V2.0-SDL )

    It used sdl-gfx library to perfom a lot of the software rendering. And some of my own functions to perform software rendering that sdl-gfx was not capable of performing.

    It worked quite nicely. Except the limitiation of SDL 1.2 only supporting single windows.

    During that time, the clanGL1 target was created and clanGDI was almost complete.

    clanGDI software renderer was a lot faster than clanSDL software renderer. ClanGL1 ran on old hardware.

    So, nobody was interested in clanSDL anymore, including myself. So it was moved into:
    svn://esoteric.clanlib.org/ClanLib/Development/Contrib

  14. #14
    Administrator Seth's Avatar
    Join Date
    Jul 2002
    Location
    Japan
    Posts
    5,345

    Default

    I agree, CL 2.X should not rely on SDL, it should replace SDL.

    SDL 1.3 seems to have some licensing issues that would be a problem for commercial apps on iDevices (no dynamic linking allowed for free) when the inevitable iOS port happens, so best to steer clear from the get-go.

    I mention this because the iOS port probably will want to steal a lot of code from the OSX port as a lot of systems are similar and it would be easier if it isn't using SDL.
    Seth A. Robinson
    Robinson Technologies

  15. #15

    Default

    If we look at CL_Win32Window::create(CL_DisplayWindowSite *new_site, const CL_DisplayWindowDescription &description) as one of the examples, this function should create the actual window on the screen. In Windows this equals to calling CreateWindowEx and on Mac it probably equals to constructing a NSWindow cocoa object or whatever they may have named it. So that function would create such an object and store it in a member variable, to be used by the remaining functions on CL_MacWindow.
    Ok, I started trying to do this, after copying the win32_window, just so I have a template to fill in. I may try and stub it out and get it to compile and possibly link and then fill the bits in. Then I'll find out if I have any big obstacles.

    If I want to create an OpenGL window/target do I still have to create a MacWindow? Does this window host the context or is that a different window altogether?

    Notes:
    • There is ifdef WIN32 and __APPLE__ code. What is the define for X11? I'm not sure there is one. It would be nice if Clanlib had defines of its own, e.g. CL_PLATFORM_WIN32/OSX/X11.
    • Looks like I'll have to glue the C++ to Objective-C or Objective-C++. Woo. http://stackoverflow.com/questions/5...of-objective-c
    • font_config.[h|cpp] is part of X11 and looks like it should generic.
    • The SWRender, non-WIN32 seems to quite heavily rely on X11.

  16. #16
    ClanLib Developer
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    554

    Default

    Currently the code uses the tactic that if neither WIN32 or __APPLE__ is defined, then it is assumed the platform is Unix with X11. Yes, it would have been prettier with our own defines, but laziness caused me to just rely on the built-in defines of MSVC and GCC.

    The official strategy of ClanLib is that the code is abstracted in the following ways:

    First there is the Provider principle, which is just another fancy word for defining an Interface each target implements. The main difference between a provider and a classical interface is that we protect the naked pointer of an Interface by wrapping it. As an example of this we can take the CL_DisplayWindow class, which really just forwards any heavy-lifting to the CL_DisplayWindowProvider object it holds. Each display target (clanGL, clanSWRender, etc) implements this provider to perform the tasks required and the CL_SWRenderDisplayWindowProvider class is the clanSWRender implementation of it. To create a new clanDisplay target, one simply has to implement all the providers and you're done.

    In the early versions (ClanLib 1) the CL_SWRenderDisplayWindowProvider class was then inherited into a Win32, X11 and Mac version. The only #ifdef required was at the creation point where it would allocate the one specific to the platform.

    But as time went on it became more and more clear that all this abstraction stuff made it very annoying to actually work with the code. Simply put, I reached the conclusion that ideally the provider implementations shouldn't be doing any code of their own, but should rely on classes that stand on their own. The rationale behind this decision is that in order to work well with a specific topic in a code base, you must be able to study the code without suddenly bringing every other aspect of the system into play. The CL_Win32Window class is an example of such a worker class that moves code away from the abstraction class. In this particular case, the class happens to be usable across multiple display targets and is therefore placed in clanDisplay.

    Anyway, back to the various #ifdefs. Usually if you find lots of #ifdef code, it is a sign that the code for one reason or another didn't bother to create a class platform abstraction or that the code has simply been placed a poor place. I.e. the ifdefs that are in swr_display_window_provider.cpp, they can basically be boiled down to:

    • Include or object allocation statements differing between platforms (which is unavoidable)
    • Platform specific code that really belongs to CL_Win32Window/CL_X11Window, but was lazily written in the provider
    • Code that probably didn't make sense to place in the window helper class, but should have been placed in a new class covering this particular problem. Things like CL_SWRenderDisplayWindowProvider::draw_image belong to this category. It serves as a helper function used by CL_SWRenderDisplayWindowProvider::flip


    Usually the best way to deduce what an #ifdef hack does is to first study the header file. The Win32 #ifdefs there usually indicate which parts work together.

    The clanSWRender target is probably the easiest target to port first, since the only platform specific code in that target is the CL_Win32Window class and the draw_image function that displays the generated image in the window.

    About the font classes, these things are probably best answered by Rombust that know a lot more about their internals than me.

  17. #17
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,824

    Default

    Ref: "font_config.[h|cpp] is part of X11 and looks like it should generic."

    Fontconfig is a library designed to provide system-wide font configuration, customization and application access
    The code was added by "Kevin Bluck" to assist in matching microsoft fonts with linux fonts. (Previously, I had created a hack to guess the full filename of a truetype font and adjust it's size, which only worked on ubuntu)

    If OS X also uses the library, yes it could be made generic. Personally, I would just copy the code because I am lazy You would need a #ifndef WIN32 around the file.

    Note: The fonts in ClanLib 2.3 SVN are currently broken on linux, they don't display correctly. Use ClanLib 2.2.1 (or ClanLib 2.2 SVN)

    Ideally, I prefer to add OS X support onto the 2.2 branch. (Since it has a stable API)

  18. #18
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,824

    Default

    Reference: the #ifdefs, you may find this useful http://www.rtsoft.com/forums/showthr...ll=1#post10875

  19. #19

    Question

    Quote Originally Posted by rombust View Post
    Reference: the #ifdefs, you may find this useful http://www.rtsoft.com/forums/showthr...ll=1#post10875
    Thanks. Reading those makes me more inclined to believe that you need CL specific defines!

    Something like:

    CL_DEBUG
    CL_OS_WINDOWS
    CL_OS_LINUX
    CL_OS_OSX
    CL_I32
    CL_I64
    CL_MANAGED

    In the meantime I'll have to just use #if !defined(WIN32) && !defined(__APPLE__) for X11/POSIX, and if I break anything else you may have to fix it when I'm done.
    Last edited by Chin Billy; 08-13-2010 at 06:22 PM. Reason: OSX is part POSIX

  20. #20

    Default

    clanGDI software renderer was a lot faster than clanSDL software renderer.
    So the s/w renderer part of it was limited and slow, but the rest of SDL is fast as anything else.

    ClanGL1 ran on old hardware.
    Yes, I need GL1 to compile/test CL on my laptop. My use of GL will be mostly GL1 as I'm interested in 2D for the masses.

Similar Threads

  1. OS X Leopard build problem
    By yogi183 in forum Official ClanLib SDK Forums
    Replies: 1
    Last Post: 12-19-2007, 08:21 AM

Bookmarks

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •