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.
New Technology, Old Programmer
What about to port Gnash to iPhone 😉
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.
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.
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.
Huge, I now this problem 😉
Wow. Great work. Looking forward to giving this a go!
The speed of progression is fantastic. Great work!
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.
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?