A Second Look (iPhone + Haxe)

iphone2

Once the basics are in place, the rest comes pretty naturally.

Just a slight tweak to the MovieClip transformation gets Physaxe doing it’s thing.

Performace seems ok-ish in the simulator, not sure how it woud go on the real device.

This entry was posted in hxcpp, iphone, nme and tagged , , , . Bookmark the permalink.

9 Responses to A Second Look (iPhone + Haxe)

  1. deep says:

    What about to port Gnash to iPhone 😉

  2. Huge says:

    The problem with gnash (and neko) is that they are interpreted, which is explicitly forbidden by apple. ie, If you can create it without apple being able to vet your executables, then it ist forboden.

  3. JP says:

    Well done. This is a promising project. But you must know that all that is software rendred, is MUCH more slow on the iPhone. The graphics part is software rendred right now ? From what I can see on your screenshot, you will get about 1 frame / second on the iPhone.
    Even if you can support OpenGL ES later, the CPU ratio used for the physics engine will be much more important on the iPhone than in the simulator but this time that should be OK for the frame rate.

  4. Huge says:

    JP – yes I agree software rendering on the iPhone is going to be like pushing shape up hill with a sharp stick. But the physics simulation will run approximatly maximum device speed. So if you are suggesting that floating-point physics on the iphone may not be possible then you may be right, but I think we be able to give it a bloody good go.

  5. deep says:

    Huge, I now this problem 😉

  6. Tarwin says:

    Wow. Great work. Looking forward to giving this a go!

  7. Robin says:

    The speed of progression is fantastic. Great work!

  8. n8gray says:

    As somebody writing an iPhone game with plans for a web version in Haxe, I’ll be following this experiment with bated breath!

    BTW, by my reading of the iPhone developer agreement you *are* allowed to execute interpreted language code, but you have to ship the code with your app. In other words, you are only prohibited from executing interpreted *downloaded* code. The reason would be that a bug in your interpreter could allow remote exploitation of the phone. Not that such a thing isn’t possible with, say, Apple’s Javascript engine in Safari, but at least if that happens Apple “owns” the bug.

  9. Huge says:

    n8gray, I guess that makes sense that some program may use some form of scripting internally – otherwise where do you draw the line between data-driven and script? And I can see their point about not having a generic system (eating into their app revenue). So I guess this means you could probably have a neko system, if you embed the script into the app?

Leave a Reply

Your email address will not be published. Required fields are marked *