libgdx on ios, day 3

Today i focused mainly on files and graphics. Files are done it seems. Internal files map directly to your app bundle. External files map to your app’s document folder and are accessible by the user. Local files map to the app’s Library directory and are not accessible by the user (except on jailbroken devices). Both local and external files will be backed up by iTunes.

In the graphics department i focused on getting GLES 2.0 to run. For that i already had native bindings from Android, i just modified a few bits here and there and things just magically ran. I have to resolve a minor thing concerning buffer positions and element sizes, nothing to bad really. Obligatory screenshot:

8 thoughts on “libgdx on ios, day 3

  1. So is the idea that games could be written in Java, and then the compiler would convert them to C# as an intermediary step before compiling for Mono? Or do you plan to convert the entire library to C#?

  2. so do you guys have any plans to add a networking module? iirc, the argument against it has always been that is sufficient (which I’m assuming will not work with the HTML5/iOS backends)

  3. My app is using libgdx (of course), with some extra functions specifically for the android backend, e.g. many custom android dialogs and notification on android status bar. Will I be able to code some platform dependent things similarly for iOS platform, i.e. likely via c# or objective-c?

  4. @Link, yes, that’s possible. The same principle applies: interface it, implement it using MonoTouch’s Cocoa bindings, push an instance of the interface implementation to your ApplicationListener. You can access the bindings either from Java or implement things in C#.

    @dantheman, i consider adding at least TCP/WebSocket support and a very lightweight HTTP module. No ETA on that.

Leave a Reply

Your email address will not be published.