Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Monocle Mac Install/Support #112

Open
amackworth opened this issue Jul 6, 2012 · 3 comments
Open

Monocle Mac Install/Support #112

amackworth opened this issue Jul 6, 2012 · 3 comments

Comments

@amackworth
Copy link

I've been trying to implement Monocle on the Mac and I've had a series of issues, which I decided to put in an issue, rather than pull requests, as I'm not sure how some of these would be addressed. Let me know your thoughts.

Replacing the Mac OSX section of the README

Mac OS X:
0) Be sure to use the git development branch, not the master.

  1. Download premake4 and put on your path. Make sure to get the latest beta; at least 4.4-beta4 at the time of writing), but see note below.
  2. cd to the folder and run
   premake4 --cc=gcc --os=macosx --platform=PLATFORM [BUILD_ACTION]

PLATFORM is x32, x64, universal, universal32, universal64, ps3 (experimental), xbox360 (experimental)

Also, to generate test applications (recommended for beginners/getting started with Monocle), append --testapp=all to the install

These are the available BUILD_ACTIONs:

clean        Remove all binaries and generated files
xcode3      Generate Apple Xcode 3 project files
xcode4      Generate Apple Xcode 4 project files 

For example, on OSX, an example install would be

premake4  --cc=gcc --os=macosx --platform=x64 --testapp=all xcode4 ```

(if you have a 32-bit Mac, then use --platform=x32)

The files will appear in Build/gen-xcode4-all

To get the content into the location where the samples expect it, you have a couple of steps;

  1. Select the target and add a Build Phase "Copy Files". Change destination to "Products Directory" and subpath to "Content".
  2. Hit + at the bottom of the Copy Files Phase, and hit "Add Other", then select the content folder for your app (e.g. Ogmo or Jumper). Don't copy into destination folder, and be sure to change Folders to "Create Folder References for any added references"
    This will put the files in a folder next to the executable called "Content"

Other Issues

With Xcode 4.3.2 and 4.3.3, there is a incompatibility in Premake that sets the SDK incorrectly. If you get hundreds of errors starting with " is not found", then change the SDK from "Current Mac OS" to "Latest Mac OS X …" (Select Monocle project, then MonocleCore Target, then Build Settings, then change Base SDK value.) Alternatively, you can use a temporarily forked version that fixes this issue at https://github.com/erwincoumans/premake-dev-iphone-xcode4/downloads

There is also an issue where Premake is loading the libraries from the production /Library/Frameworks//OpenAL.framework/OpenAL instead of the developer SDKs. This can be a problem if you have changed your frameworks (e.g. installed certain graphics software). The symptom is crashing on OpenAL calls. To fix, just add the appropriate framework to your project (either inside Xcode or your /Developer folder).

If you get an error msg about base_ios.tcc, then you're running into a compatibility issue between C98, 03 and 11. The monocle source assume 03, but Xcode only provides 98 and 11. Reference:
http://stackoverflow.com/questions/7964360/using-stdshared-ptr-with-clang-and-libstdc.
The easiest workaround is to disable the ability to log to a file, leaving the console. Find the line

Debug::DebugOutStream Debug::outStream = Debug::DebugOutStream();

and change to:

Debug::DebugOutStream Debug::outStream;

(this occurred during commit 1ac9806)

There is a typo in OpenGLTextureAsset.cpp, which is specific to the mac version. Look for the line:

gluBuild2DMipmaps(GL_TEXTURE_2D, GL_RGBA8, width, height, format->glPixFormat, GL_UNSIGNED_BYTE, data);

and change fmt.glPixFormat to format->glPixFormat This occurred during pull request 110, commit 31baa48

There is an incompatibility error in Debug.cpp, where logOut.open is being called with filename, which is a std::string, but open expects a char *. I confess that I'm unclear how this would compile on any platform. I fixed my copy with

char *cfilename = strdup(filename.c_str());
logOut.open(filename);

but I'm not clear if that will work on other platforms

Warning Messages

There are many other warnings from the compiler:

  • in ChannelStream.cpp, memset(this->buffers,0,sizeof(this->buffers)) should be memset(this->buffers,0,sizeof(*this->buffers)), and same for obtainedBuffer. I think this is an actual bug, but may not have a real world manifestation.
  • in stbtt__isfont in stb_truetype.h, stbtt_tag(font, "1") theoretically indexes beyond the end of the string; be nice to fix, but it can't actually go over.
  • I'm not a C++ expert, so I don't know what "Delete called on <> that is abstract but has non-virtual destructor means." It looks like this is also a 98/03/11 issue. I found this article ( http://www.gotw.ca/publications/mill18.htm ) which suggests that destructors should either be public and virtual, or protected and nonvirtual
  • in stb_truetype.h, 's last parameter should be "const char *tag"
  • Foundation.framework defines MIN and MAX, so compiling CocoaWindowListener.mm hits a redefinition in Macros.h
  • Most of the others are unused variables.

Once you get it running, Monocle is one heck of a great engine, but right now the install process is a bit rough. I'm happy to submit the obvious ones above as pull requests, but I wanted to see if you had any thoughts first.

@rosshays
Copy link

rosshays commented Jul 6, 2012

Hmm I am personally not going to be much help on this one. I only have windows and linux computers available to me so I cannot really play around with it myself. I am going to play around witha few things when I get home from work later tonight and see about some of the warnings and C03 issues you mentioned.

Also, with those warnings, do you know if you were using the Mac OS X gcc or using clang for the compiler?

@amackworth
Copy link
Author

I'm pretty sure it was gcc, but LLVM had similar results.

@rosshays
Copy link

I tested everything on Windows in the pull request and it seemed fine. I am going to leave this issue open for the time being until we can get some more Mac users to test out the development branch to make sure everything is working there too. But from what I can tell Windows was good with this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants