I'm currently wrapping CEGUI for BlitzMax. I tend to compile all the source directly, skipping makefiles, and creating a static lib.
However, I struggled somewhat with the Mac build as it seems to require macPlugins.cpp, which itself has a main() method - handy for dylibs, not so for static
I guess my question is... Can I leave out a set of files which removes the macPlugins.cpp requirement?
I've currently got it building with everything, and the have the main() commented out. It all works. So I'm not overly concerned about compiling it into the lib
Otherwise this GUI library is very good, and "mostly" appears to work consistently on Mac, Win32 (MinGW), and Linux - barring some colour issues on Mac.
Thanks !
No static build for Mac?
Moderators: CEGUI MVP, CEGUI Team
- scriptkid
- Home away from home
- Posts: 1178
- Joined: Wed Jan 12, 2005 12:06
- Location: The Hague, The Netherlands
- Contact:
I am not sure about static builds for Mac OS. My guess is that it is missing by accident. Maybe CE can hook into this thread.
The colouring might be a known bug: http://www.cegui.org.uk/phpBB2/viewtopic.php?t=1006
The colouring might be a known bug: http://www.cegui.org.uk/phpBB2/viewtopic.php?t=1006
Check out my released snake game using Cegui!
scriptkid wrote:The colouring might be a known bug:
Yeah, I imagine it's to do with that. I remember I had some similar colour-swapping issues when wrapping FreeImage on Mac.
In my test, the WindowsLook frame close button is blue on Mac (Intel), but red on Linux and Win32.
At the moment, I'm just concerned with getting the API working... and then I'll start worrying about the niggly stuff
Cheers!
- CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
The only supported build for Mac at the moment is via the XCode project. When rolling your own build systems, you should consult the XCode project for any required definitions / configuration settings.
I did not get a chance yet to look into static builds on the Mac - when I updated the old broken XCode project, I did not add anything - it was just a major cleanup / fix update to get it working. Eventually the 0.7.x line of code will get an all new XCode project and also Mac support via configure / make and these will support the same set of possibilities that we have on Win32 and on linux. I have no ETA on this since I have very little time that I can spend on CEGUI at the present time (about three or four hours over the course of a week).
When trying to get the static build to work, do not forget to define CEGUI_STATIC
The colouring issues are endian related. I think your issue is different to the Property based one. Which image codec is being used? (assuming OpenGL renderer).
CE.
I did not get a chance yet to look into static builds on the Mac - when I updated the old broken XCode project, I did not add anything - it was just a major cleanup / fix update to get it working. Eventually the 0.7.x line of code will get an all new XCode project and also Mac support via configure / make and these will support the same set of possibilities that we have on Win32 and on linux. I have no ETA on this since I have very little time that I can spend on CEGUI at the present time (about three or four hours over the course of a week).
When trying to get the static build to work, do not forget to define CEGUI_STATIC
The colouring issues are endian related. I think your issue is different to the Property based one. Which image codec is being used? (assuming OpenGL renderer).
CE.
CrazyEddie wrote:I did not get a chance yet to look into static builds on the Mac
No probs. It's running well so far.
CrazyEddie wrote:The colouring issues are endian related. I think your issue is different to the Property based one. Which image codec is being used? (assuming OpenGL renderer).
FreeImage.
I probably should have had a proper dig around first myself, given the problems I've had previously with FreeImage on Mac
In CEGUIFreeImageImageCodec.cpp, FreeImageImageCodec::load(), I've hacked this in for now :
Code: Select all
for (uint j = 0; j < width; ++j)
{
uint p = *(((uint*)(srcBuf + i * pitch)) + j);
#if defined(__APPLE__)
p &= 0xFFFFFFFF;
#else
uint r = (p >> 16) & 0x000000FF;
uint b = (p << 16) & 0x00FF0000;
p &= 0xFF00FF00;
p |= r | b;
#endif
// At the same time we can flip verticaly the image
// (since textures are required to be upside down)
// hence this funny maths
*(((uint*)dstBuf) + (width * (height-1) - i * width) + j) = p;
}
which fixes it for Intel. I'll try it out on PPC and see how it looks there too.
(um, don't ask for a patch... I'm just a (bad) hacker, and tend to make things up as I go... )
<EDIT> I can confirm the "fix" works for PPC Mac too.
- CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
- CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
- CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
With regards to the FreeImage issue, I have committed a change that hopefully will resolve this issue in branches/v0-6 rev. 1859.
I say hopefully, because from reading some things on the 'net, it appears that FreeImage behaves differently depending upon the version in use (though I did not confirm this for myself - perhaps I might play around if I get some free time, ha ha!).
CE.
I say hopefully, because from reading some things on the 'net, it appears that FreeImage behaves differently depending upon the version in use (though I did not confirm this for myself - perhaps I might play around if I get some free time, ha ha!).
CE.
Return to “Bug Reports, Suggestions, Feature Requests”
Who is online
Users browsing this forum: No registered users and 3 guests