How does Oolong compare to SIO2?

Has anyone used both?

I'm not thinking of switching; I just think there should be some information out there, comparing and contrasting.


Best,
-joshua

I've tinkered with both.

Oolong's priority is more about optimization and creating a toolkit for knowledgeable programmers than say a scripting type engine like Unity. They've leveraged an agreement with PowerVR (the manufacturers of the iPhone's graphics chip) to be able to use their pod file format and export tools; which is a win because the format is optimized specifically for the iPhone's graphics hardware. They don't have access to the source of the export tools atm so if you have an issue during export you just have to work around it, but I think they're hoping to change that. They do have some support for loading 3DS files directly. The PowerVR export tools are only for windows atm with exporters for maya and max. They also have a collada2pod exporter, which I was able to run on my mac using darwin. They have support for fast matrix math using the iPhone's undocumented vfp unit. The code comes with several examples. One that caught my eye was per-pixel normal mapping using multi-texturing. They also have several examples ported over from PowerVR's sdk. They're using the Bullet SDK for physics. Documentation is non-existant, although the mailing list archives were a very good resource for figuring out how things are architected. And the people on the list were very nice. It's written in C++. Comes with a custom memory manager. There are facilities for object culling, tri-stripping and whatnot, but I never figured out how it works.

SIO2's main strength is it's art pipeline. Nothing in oolong compares. For example, you can do particle effects with oolong, there's an example for it, but you have to wade through the example code and basically do it yourself. With SIO2 you export from blender, make the appropriate sio2 calls and you're done. Also with oolong you'll be making the opengl calls yourself to render your triangle strips. Which in my opinion kind of blurs the line between where my game ends and their engine begins. I found it difficult to see what oolong was providing me. SIO2 in contrast has a clear interface, thanks in part to the great video tutorials.

I'm biased towards sio2 though because I came to the table already knowing and liking blender. I imagine people might not tolerate the learning curve blender imposes (took me 3 months).

-Greg

Thanks dude. That's an awesome overview.

I like SIO2 and have no plans to change, but yes, the Blender aspect was an obstacle for me.


Best,
-josha

gtmacdonald wrote:For example, you can do particle effects with oolong, there's an example for it, but you have to wade through the example code and basically do it yourself. With SIO2 you export from blender, make the appropriate sio2 calls and you're done.

That's exactly the same with SIO2, isn't it? As far as I know there's no way to export particle systems from Blender, you need to write them yourself - with SIO2 support indeed.

Best,
Matt

Hi Matt,

You're right. My bad. I'm still learning the engine. I'd be great if it did though.

I was comparing the particle examples because glancing at sio2's tutorial 12, I immediately could tell that it was something I could work with whereas the oolong particle example confused me to be honest. It was hard to tell where I needed to plug in, or what to wrap. In oolong's defense though their particle example was something that was ported over from PowerVR's sdk. Just cause they have that example doesn't mean they'll not eventually make nice helper functions like sio2 has.

I'm incredibly happy I found sio2 because that means I can immediately start writing gameplay code. But it's also nice to have oolong around to show another way of doing things. The per-pixel lighting and fast matrix math code in oolong is intriguing. When my project matures I imagine I might pull their memory manager over for my c++ code or try to use the fast math routines.



-Greg

gtmacdonald wrote:I'm incredibly happy I found sio2 because that means I can immediately start writing gameplay code.

Yeah, second that, but: Once you're getting to more demanding parts you still need to work around some things or tailor the engine here and there to suit your needs. But all in all, SIO2 is a great thing to get started with.

Best,
Matt

I absolutly agree with Matt. As you´re going further in your project you need to patch sio2 to suit your needs. Do not misunderstand me, SIO2 is great but I think it´s still a little beta.

Do anybody know if oolong has the same issues or is it completely functional?

SIO2 is built to give you a base to start with, as the demand for the modern game of today can become really specific it would be impossible for SIO2 to handle them all...

However Im interested to get your ideas on what you would like to see added to the current framework (functions, helpers etc...)?

And which pieces you had to patch? and to achieve what?

Cheers,

First of all I have to say sio2 is a excellent piece of cake so don´t get angry

I think object duplication is something has to be fixed. I´m having problems with that and if you read on the forums, I´m not the only one.

The sio2 selection method is a little buggy too. I don´t know if it´s something with sio2 or bullet, I´m still working on the first problem.

iphoniac wrote:I absolutly agree with Matt. As you´re going further in your project you need to patch sio2 to suit your needs. Do not misunderstand me, SIO2 is great but I think it´s still a little beta.

Do anybody know if oolong has the same issues or is it completely functional?

Oolong is a bit raw to say the least. They set you up with a basic rendering pipeline and the rest is pretty much up to you. Docs are non existent, there is just a message group. No videos, tutorials, etc. The example apps are ported from PowerVR and some dont run well on the device (VERY low FPS). The really nice thing about it is that it has a high performance rendering engine that uses PVRTC compressed textures (speed increase and smaller size).

There are some optimizations that I would like to see in SIO2 for sure. I am working on a few of the additions to the SDK that I feel are necessary and will send the code over to SIO2 for inclusion if he would like. I intend to get the following implemented:

• SIO2 Remote for testing accelerometer without installing on the device (This is done and sent to SIO2 for inclusion into the SDK)
  
• CAF audio support (including compressed and uncompressed caf files. About 80% done as of right now)
  
• Tools for menu creation (Basically, a very easy way to create options screens. This will really just be a wrapper for SIO2Widget to make menu creation cleaner and easier)
  
• Save decompressed sio2 files to the device so that they don't need to be decompressed every time you need them
  
• PVRTC compressed textures (This one is probably a bit out of my league at this point but by the time I get to it, hopefully my OpenGL and C knowledge will be up to par)
  
• Some other things I probably forgot

iphoniac: Have you check tutorial06? Im using color picking by default with SIO2 since its the easiest and fastest way to do picking on the device...

Can you give me more information about the "buggyness" factor


uprise78:

high performance rendering engine that uses PVRTC compressed textures (speed increase and smaller size

>> PVRTC are not really easy to integrate with Blender, and recently I've been doing some tests and got a major speed increase just by sharing materials and using texture atlas... you might wanna give it a shot... ( rendering 41 objects ~ all visible, at 14.7k of triangles at 40 ~ 42 fps on the device )


SIO2 Remote for testing accelerometer without installing on the device (This is done and sent to SIO2 for inclusion into the SDK)

>> I already rewrite a new one (tutorial13_1 & tutorial_13_2) and create SIO2socket, which gives you access to networking functionalities and give you the opportunity to integrate your own communication protocol within SIO2.

CAF audio support (including compressed and uncompressed caf files. About 80% done as of right now)

>> Im waiting for your code to check, but once again it is not really easy to use .CAF since Audacity doesn't support it and the conversion have to be done manually...


Tools for menu creation (Basically, a very easy way to create options screens. This will really just be a wrapper for SIO2Widget to make menu creation cleaner and easier)

>> Yeah that's a great idea, but this require a full fledged editor on its own... I guess it would be easy to do that in cocoa and auto generate on the fly LUA code for the events that can then be picked up by SIO2, or go more for a GTK approach generating automatically the whole C code.

Save decompressed sio2 files to the device so that they don't need to be decompressed every time you need them

>> I'll think about that but...

PVRTC compressed textures (This one is probably a bit out of my league at this point but by the time I get to it, hopefully my OpenGL and C knowledge will be up to par)

>> Same as above about PVRTC...

Some other things I probably forgot

>> Hehe please do post'em when you remember them

Tks!

Cheers,

sio2interactive wrote:
>> PVRTC are not really easy to integrate with Blender, and recently I've been doing some tests and got a major speed increase just by sharing materials and using texture atlas... you might wanna give it a shot... ( rendering 41 objects ~ all visible, at 14.7k of triangles at 40 ~ 42 fps on the device )

I am interested about how you did the texture atlas. Did you just use one large texture and then UV map it to a bunch of different objects? If not, how did you do it?

As for the the menu "tools" that I mentioned, I think what I have in mind is very different than how I explained it. Basically, I am just going to make a wrapper that will take an array of menuItemObjects. The menuItemObjects will consist of an image for not-activated, an image for activated, a callback function and position data. The menuObject will take in a background image and either 1 or more menuItemObjects. It will just be a really easy way to create a full menu screen without having to wire up the sio2Widgets and deal with the tapDown/tapUp image changes and such.

I do use the color picking method and I get about 2/3 of selections in simulator and device (in the other third I get null).
Regarding object duplication, there is something strange with the culling, I get a dst value of 0 for objects that should be visible but i'm still working on that.

uprise78 wrote:

sio2interactive wrote:
>> PVRTC are not really easy to integrate with Blender, and recently I've been doing some tests and got a major speed increase just by sharing materials and using texture atlas... you might wanna give it a shot... ( rendering 41 objects ~ all visible, at 14.7k of triangles at 40 ~ 42 fps on the device )

I am interested about how you did the texture atlas. Did you just use one large texture and then UV map it to a bunch of different objects? If not, how did you do it?

I second this question. This would be a huge bump in performance for my application. I've actually enjoyed working with the sio2 sdk - great work thus far. Finding a way to incorporate a texture atlas, even just example code, would be excellent.

Keep up the good work - I'm looking forward to the next release'

Check in blender:

UV/Image Editor -> Image -> Consolidate into 1 image