Share

Game Done. Port to Marmalade?. What and how?

2 replies [Last post]
Wed, 2012-02-22 18:07
by: Jorge MR
userbadge
Status: Offline
Joined: 2012-02-14
Points: 10

Hi

Let's say I have a finished and working IOS game written 95% on C++ and some specifics with Objetive-C

I want to port it to as many platforms as possible, so Marmalade sound like the right choice

I don't need some of the Marmalade's modules like lwGLx, lwGLxFont, lwGeom,lwAnim since they are already implemented in my application,

Well, in general my questions are

Does it worth to port my working , 95% C++, open GL ES app to Marmalade?
What would I gain?, quick wins? (having in mind I already implemented my own animation, rendering, etc..)
Or , is it easier just to implement the specifics for Android, BlackBerry, etc, myself , without MM?
Is there something in the Marmalade's rendering pipeline I can take advantage of? Deffered Shading?
Can the rendering pipeline be combined with a different implementation rather than lwGeom?

Hopefully some experienced Marmalade users can point me in the right direction

Thanks

Jorge

Top
Thu, 2012-02-23 18:37
by: Kite
userbadge
Status: Offline
Joined: 2010-11-15
Points: 1870

Since no-one has answered this yet.. (!)

Quick Wins:

* Platform support is great. I've ran a project for iOS on bada, PlayBook, Android with 0 modifications.

* Some really nice APIs. Play a video over GL? s3eVideoPlay(file). Music? s3eAudioPlay(file). Access to the camera.

* If you want something on Android or iOS they don't implement, you can do it yourself with the EDK.

Some losses:

* Forum can be slow. (both slow server and slow responses).

* Some things are not fixed in a timely manner.

Here's a quick summary of the rendering in Marmalade. The docs are not that clear and there's usually confusion about it.

* s3eSurface: Simple surface/framebuffer API. Slow-ish.

* IwGL: GL wrapping API. It will setup GL for you, handle extensions across devices, virtual res etc. You render with usual GL calls.

* IwGx: Marmalades steam based renderer. In "HW" mode it uses GL underneath, in "SW" it uses Marmalades special software renderer (which is pretty cool actually). You can even mix HW/SW for different stages.

* Iw2D: 2D API built on top of IwGX.

* IwGeom: This isn't actually a rendering API, it's contains lots of classes for 3d such as vectors etc.

* IwGxFont: Font classes for IwGx.

* Theres also a whole set of "studio" apis for models, animations etc.

Some APIs, such as IwGx implicitly initialise others (IwGeom, IwUtil). You don't use IwGx and IwGL at the same time etc. You can mix IwGx and actual GL calls but have to be careful of state.

From the sounds of it, you should use IwGL. Our project is similar (own resource management, animation, renderer) and we just init with IwGLInit() then use our own code.

I have actually tried writing a deferred renderer in IwGx using shaders and it does work :)

Hope this helps, any questions ask.

Top
#1
Fri, 2012-02-24 14:41
by: Tim C
adminbadge
Status: Offline
Joined: 2009-10-26
Points: 990

@Kite is right...

If you have an iOS codebase that is 95% C++, and OpenGL ES, then porting to Marmalade should be really quick. You just need to port the remaining 5% of Obj-C code to C++, and the iOS core framework calls to Marmalade calls (most of which will become stdc library calls, or S3E API calls).

The advantage of having your codebase on Marmalade is that you then have a single codebase from which you can deploy to iOS and Android simultaneously (so great for app updates), as well as platforms like BlackBerry 10, bada and beyond. No switching between Windows/Mac, or between IDEs. Plus Marmalade handles a ton of OS-specific and device-specific pain for you.

Top
#2