zaphire / monocle-engine Goto Github PK

It seems the domain expired.

monoclepowered.org

The Xcode project is broken. It references lua files that don't exist in the repository.

Monocle-Engine/Code/Colliders/CircleCollider.cpp:47: error: ‘fabs’ was not declared in this scope

Some #include is missing probably.

Can we compromise with something like this? It puts a requirement on the user to compile with a define though, which may not be an option.

I'm wondering if mantaining the low level platform specific input handling is a good idea or just a big source of problems. I totally appreciate the control that comes from this kind of independence but at the same time i'm worried about the fact that code is not heavily tested.

I'm asking if you think that some external, well tested lib can do the trick. OIS[0] seems to be a good candidate for this dirty job:

• Multiplatform (win, linux, osx, ios)
• Clean OO interface
• Compact
• Fairly recent
• Liberal Open license (zlib)

I could try to integrate this solution in Monocle Linux platform to explore the possibility, but i'd like to know your point of view first.

Emanuele

[0] Objec Oriented Input System: http://sourceforge.net/projects/wgois/

See title; things otherwise seem pretty OK on the 64-bit front. I don't know if 64-bit is a priority for you, but it surprised me when I saw the bug: the textures just have white backgrounds where there should be alpha.

I'm using nvidia's linux driver which reports my monitors as having a color depth of 24, which means the new default of 32 in the Game class can't find a compatible display from glXChooseVisual. Does a default of 24 break the Windows init, and if not, can the default be set to 24?

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.

Destructors of derived classes won't be called if deleted from an Entity*.

Patch is at https://gist.github.com/982009, but it's only a word long. There are probably other candidates for this change, too.

I expected KEY_QUOTE to be the ' character on the keyboard, but that is incorrect in my case. The linux platform implementation binds XK_quotedbl to that key, but the value that works for ' is XK_apostrophe.