OpenGl versus Codea

It has been a while since I’ve been on. Love all the updates, sample apps.

I have finally setup an apple developer account published a few simple apps and thought it was time to tackle something 3d and fun.

I started looking at OpenGL samples and it doesn’t look hard, but I remembered the many nights I played with codea and thought I’d relook at it.

So my question is in general what are benefits of each and the draw backs. I remember codea itself being limited it things like access to mp3 files, voice and custom images. I think with the runtime tool kit I can get around those?

@Ric_Esrey - yep pretty simple once you work out what connects to what. The new Xcode export functionality is magic. My prediction is that this is going to see a lot more codea apps being submitted to iTunes.

Codea now does the 3d stuff pretty well. It allows for custom shaders and you can do a lot there. Depending on the complexity of what you want to do there are some shortcomings currently with multipass rendring as rendering to an image doesn’t support z buffers. Also I’ve found updates to vertex information can be a little slow, so dynamically modifying your meshes at every frame isn’t so hot, but you can do a lot of this in the shaders anyway depending on your use case.

As to using OpenGL directly in xcode, I don’t have much experience with this, but generally it means you would be writing a lot more of the plumbing yourself, where codea gives you a decent simple API for doing this. It might run faster, but equally the slowness may be hardware issues in the handover from memory to GPU etc.

I think Codea is very good in this area and significantly simplifies what you need to do compared to the raw opengl apis.

Oh, and we can’t access/play mp3 files unless you modify a compiled runtime app.

@aciolino the next version has a plugin style system allowing you to expose custom functions (such as music playback) in a much neater way.

I have no issues using the runtime. Once I do how configurable is it? Easy to customize?

@wrmichael the new runtime will export from Codea. It allows you to register additional native functions for use in your Codea apps (these can be anything, such as playing music, additional rendering, native UI), as well as manipulate the Codea viewer in some ways.

It’s just a cleaner hook into Codea than we have had in the previous runtime.

I’m curious how we hook in…guess I’ll see soon!

@aciolino there’s a CodeaAddon Objective-C protocol. You build a class that implements it and call [codea registerAddon:myAddon] to get it hooked into Codea. This first release will be considered experimental until we stabilise the API around what people need.

@Reefwing, just curious… Are you going to build a tutorial on how to use the Obj-C hooks (i.e. to add music)? By the way, Mr. @Reefwing’s superb tutorials can be found at http://codeatuts.blogspot.nl/ .

Exiting news. Hope that it means that udp listen is now possible (through x-code I beleive).
Scanning for the update at regular intervals now :slight_smile: Saturday is my guess as useal.

Just tried it out, I’m also excited! Here is some ugly code showing how to save an image to the photo album and how to share an image on facebook from your app. :slight_smile: :slight_smile:

https://gist.github.com/tnlogy/5371725

Totally error-check-free. :slight_smile:

Wait, what did you try out? I cannot see the update yet

and how do we load that assembly into Codea? I look forward to seeing this work, I’m sure that MP3 will be one of the first examples of this working.

I tried the beta version, it will hopefully show up soon! The addon system seems quite convenient, so I hope to see a lot of useful addons here in the future. :slight_smile:

So @tnlogy, how much of that was what you wrote, and how much was temple/code genned?

I wrote that in cooperation with copy-paste from the wisdom of the internet and based on the sample code @Simeon wrote.

It’s a lot more convenient than before, now I just need to add two files in Xcode and I have my extensions running.

…but we can’t debug (or should I say, RUN) them in Codea on the iPad. :frowning: that’s what I was hoping for.

@aciolino the addon system is for native code extensions, the only way to run them on an iPad is to compile them with Xcode and code sign them with your developer certificate. There’s no other way to get native code running on an iPad (except jailbreaking).

@Simeon, I understand that; I have a cert and I can code sign. The question is whether or not Codea can get to the assemblies on the iPad; we’re not recompiling Codea, so I’m trying to understand how Codea is reaching out to other locations and reading the assemblies.

Maybe I just don’t understand iOS sandboxing and assemblies; I live in a Windows world that doesn’t have a sandbox issue.