CEGUI (Crazy Eddie's GUI) Forums

Hi
I would like to know if it is possible to port ceGUI into iPhone/iPod. If the answer is yes, it would be a ceGUI simplification? If the answer is not, why?
Thanks

I think it may be possible, though I've not tried anything like this. It is something that interests me, if only from the curiosity point of view. Perhaps I'll have a play around with it and see what I think. It's possible that features might need to be removed or otherwise adjusted, though I couldn't say for sure at the moment since I do not know enough about it (yet).

CE.

Well the IPhone uses OpenGL ES 1.1, so you'd need to make sure CEGUI's OpenGL driver is compatible with that. I'm pretty sure OpenGL ES requires the use of vertex arrays/buffers, which CEGUI already does. Also you cannot use glPushAttrib/glPopAttrib, so CEGUI would have to manage that internally. I don't think it would be too difficult to write an OpenGL ES 1.1 backend for CEGUI.

The IPhone OS is derived from Mac OSX/Darwin, so the backend os support in CEGUI may not need any porting; you'd have to try it and see.

Yeah, I think it's almost certainly "do-able" - and without a massive amount of work. Maybe, just maybe, in a few weeks it will be possible to post some pictures of success

CE

So, after those conclusion, I got another question for CE. I can expect an official release for iPhone?
Thanks

I think an official release for iPhone is unlikely, mainly because we do not want to be in a position of providing support for that. If we get it working, it will probably be more akin to the mingw support; something we have set up and test now and then (usually around the time of a release), largely rely on others to tell us when we mess it up, and otherwise do not provide any level of meaningful support since it's something we'll probably not use ourselves (don't forget there's only scriptkid and myself, and both of us are trying to wear many hats simultaneously already).

CE.

Hi, first of all, thanks for great work.

Seems that this is the only thread dedicated to iPhone.
Im learning CEGUI to try to integrate it to my 2d cross-platform (but primary is iPhone) little engine and before actually starting to do that, i wanted to know a number of details to make sure it is possible at all.
Write render on OpenGL ES is not a problem, but first i need to get rid of image codecs and all platform-depended elements.
I suppose image codecs are used to load and work with couple of kinds of image formats. iPhone's gpu has it's own image format called 'pvr' so all these codecs are usless for me. I should know that i could just cut them off with no troubles.
Also i have my own resource manager, somehow CEGUI should cooperate with it. I see that should not be a problem since ogre and irrlicht has theirown resource managers.
There alot of dependencies libraries that scares me. Hope all of them could be thown away without loss.
(Wonder what is that "Perl C Regular Expression" is used for)

So how you estimating amount of work and what kind of problems should be solved?

The first question you have to ask is which version of the code should you be working with; 0.6.x or current trunk - soon to be 0.7.x. This is important for a few reasons, the main reason being that the renderer model used is totally different for the two branches of code. Also of consideration is that once 0.7.0 is released, that effectively - in my eyes anyway - makes 0.6.x obsolete; and I don't intend spending a lot of time supporting that old code. Most of the rest of my answers lean more towards the trunk/0.7.x code, since that's what interests me at the moment.

To get down to the more specific areas of your post... First you should be aware of this thread: viewtopic.php?f=10&t=4194, while the OP is not sharing his code, there are some insights there into the issues and such that you may expect to see (at least on the rendering side).

The ImageCodec is a means by which a chunk of memory containing image file data is parsed and image data contained therein is transferred to a texture. If you wish to dispense with all the image library based codecs (like SILLY, DevIL, FreeImage, etc), you should be implementing an ImageCodec yourself that hooks into any existing image/texture loading facilities available. This does not mean you have to have it available as a loadable module, it's just a lightweight class and can be integrated with the rest of the renderer code (we already do this in a couple of cases, similar to what we do with resource providers).

There are only two external dependency libraries; FreeType2 and PCRE, all those other libs are for the 'options' we provide - they're not dependencies if you do not want the facilities they provide. Additionally, in the 0.7.x code, even FreeType2 and PCRE have been made optional - although disabling these will remove functionality from the core lib. FreeType2 is (obviously) used for font handling, and PCRE is used as a validation system to limit the legal characters that may be entered into an Editbox (or combo box or spinner); if you don't need that facility, for example if all the editboxes will always accept all characters then PCRE can be done away with (although it renders the Spinner pretty useless).

I can't estimate the amount of work since I have no baseline to measure against; porting something to the iPhone is something I've never done.

CE

Going to use last trunk version.
That guy it the thread porting on OpenGL ES 2.0, since iPhone 2G\3G based on OpenGL ES 1.1 (only 3GS supports 2.0), and they are totally different in conceptual approach. 2.0 use modern concept, its totally shader based. 1.1 use fixed pipelines, TnL, and no shaders support.
FBO is supported on iPhone but is not supported on Windows OGL ES 1.1 simulator, witch i use for actual development under Windows.
How is critical FBO? Is it just used for some kind of effects?
Also rotation of images is critical to me.

There are only two external dependency libraries; FreeType2 and PCRE, all those other libs are for the 'options' we provide - they're not dependencies if you do not want the facilities they provide. Additionally, in the 0.7.x code, even FreeType2 and PCRE have been made optional

Fine, then i cannot see any significant problems at this moment to port it, except FBO.

ShiftZ wrote:How is critical FBO? Is it just used for some kind of effects?

FBO specifically is not critical in and of itself, what may be considered critical is some form of ability to render to textures; whether this come via FBO, pbuffer or rendering to an aux buffer and copying, you'll almost certainly want some level of support for this.

ShiftZ wrote:Also rotation of images is critical to me.

See, now this makes some kind of RTT critical also - because rotation at the window level requires the window content to be cached to texture first. It's possible to rotate some other basic stuff without render to texture, but for Windows it's required.

CE.

Im almost done with OpenGL ES renderer.
Here is my first ingame screenshot http://ipicture.ru/Gallery/Viewfull/22949032.html.
As you can see there is problem with font scaling - its too thin. I guess you scale it with horizonal axis as primary. Maybe primary should go the longest axis? In my case its vertical axis.
And its not only fonts problem, window elements also looks pressed.

We actually scale on both axes independently according to what the 'native' resolution is set to for the imageset (or font) and what the system thinks the display resolution is - you can test whether it is the autoscaling causing the issue by turning it off in the imageset and/or font xml files, the only problem with doing the scaling this way is that it does not preserve the aspect of the imagery. The issue is almost certainly this, and I think the only fix (other than disabling autoscaling) is to adjust the native resolution in the imagesets and fonts to something that has the correct aspect; there are similar issues when using widescreen ratios on 'normal' displays.

Other than this, it's looking good though

CE.

Only thing i still have to do is FBO render.
When im done, i could share it if you interested, with PVR image codec ofcause.
Its just few changes form trunk OpenGL renderer. Only big problem is that OpenGL ES 1.1 has no glPushAtribs. Ive done some of most popular gl state saving, but others surely will cause problems to some users.

I'm certainly interested in the code, thanks for the effort put in and the various issues you've highlighted along the way

With regards to state changes, if the GLES renderer is pretty close to the normal GL one, the number of states used should be fairly minimal - so I guess manually saving/restoring those should not be too much overhead (at least, unless you enable the 'extraStates' option, then it gets a bit more cumbersome).

CE.

Finished messing with OpenGLESFBOTextureTarget. Well, almost.
Here how it looks like without FBO usage on PC OpenGL ES emulator.


And here is FBO enabled.


Any idea what its all about?

Its modified today's trunk version of OpenGLFBOTextureTarget. Modified only decarations, content almost untouched.
Hope to get some hints where to start digging.