Haxe on the iPhone – For Real!

iphone3 To progress this project a bit further, I needed a real device – so I convinced the little woman that an iPod touch would be a good thing to have around. She seems to have taken to it, so now I’m thinking I may need one each :).

After much phaffing about, I’ve finally managed to get stuff running on the actual device. I had to comment out quite a bit of NME, since I only used the base SDL, not all the extras. Boehm GC was also a bit tricky because I didn’t really know what I was doing, but I brought in some bits from the mono project and then disabled USE_MUNMAP because it caused it to crash. In the end, it seems to work – no crash, but then I may not have been running it long enough. I will have to try some memory thrashing later.

One thing I found with Xcode is that if you ever change the project name/AppID settings then you really need to clean the project, exit Xcode and get back in. But the hardest part was working out where to go the get the developer certificate! I guess I’m a bit thick, or missed the meno, but it took me ages to get to the web form to create a certificate.

So the big question is perfromance. In this demo, initally, it runs at about 2.5 frames a second (I don’t have a fps counter yet), but slows a bit later when things spread out. But this is using the high-quality, anti-aliasing software renderer. Next job is to hook up the OpenGLES renderer, then I’ll really know where I stand.
But overall, pretty positive result I think.

24 Replies to “Haxe on the iPhone – For Real!”

  1. Hey Hugh, any progress? I’m checking the site pretty much daily in the hopes that there is some news 😛

  2. Sam, I’m working feverishly to get things ready for the next haxe release. I don’t think I’ll get time for a mini-release since we are only talking about a week or two.
    I’m trying to do things in order of lock down – so haxe will be locked down first (including the hxcpp generation) and I will do a simutaneous release of hxcpp runtime, which I’m getting together now. Then I’ll do an NME release and then a iPhone project. I can then update the runtime and NME more quickly than the haxe release.
    I have already added some thirdparty libraries to NME (SDL, SDL_ttf, zlib) but have not made it easy to use.
    The good news is that I’m treating the iphone target like a proper target – up there with Win, Max & Linux, so it should be well supported.
    Keep checking – things are moving forwards quite quickly.

    P.S. I’m getting about 10fps for the above screen now, so getting better all the time.

  3. Great to hear that your getting closer to a release! i just bought a macbook, so i’m ready to roll with some iphone testing when the time comes ;P
    If you want any prerelease testing done, id love to give it a crack… i’m only really up to the stage of opening the lid of the laptop so far.. but i’m sure macs arnt thaat scary.
    We wait with much anticipation!
    ps. you still need that donate button

  4. Hey, the same trick worked well on my lady – got her an iPod touch to show her how cool it is, now she’s letting me get an iPhone!

    BTW, I seriously can’t wait to try this out on the iPhone/iPod Touch.

    Thank you for all your work.

  5. Hey Hugh – hope its all going well!
    I am designing a game at the moment which i hope to test the iphone target on. I am going to be using particles and drawing directly to a bitmapData quite a lot. (maybe do all rendering myself). I was just wondering, will doing something like copyPixels or a bitmapData.draw be restricted to the software renderer, or will openGLES kick in? I guess i could just put sprites on the stagem that seems v.slow atm tho. by blog shows an example of a part of what i plan.
    just curious ;P

  6. Hi Tony. Yes, all is good – just finalizing some hxcpp stuff. Currently copyPixels will be software-only. I’m pretty sure rendering to texture will be slow (if not impossible?) on OpenGLES. However, I have some good news on this topic. It is pretty easy to step outside the flash API, do a bit of opengl, and then continue with the display objects – as long as you just need to display the sprites, rather than do post effects (such as glow filter). So, using a conditional compile (#if !flash), you can get 99% opengl blit speed. I have some example code that encapsulates the API difference, and used copyPixels on flash and “glTexture” on opengl.
    This is coming up on my “todo” list but I can send you a sneak peek if you like (although probably not too much use to you until iphone port is released?)

  7. Okay, well thats good/bad news ;P I guess i’ll have to wait to see which way is fastest/achievable, as blitting over the top will mean that its over all other sprites (short of blitting them too). I wouldnt mind a sneak peak – if it allows me to play around with just exe as the target that’d be good too.
    Any inside info on when a release might come? A few weeks?

  8. I had a little set back with the release bacause I changed the way I compiled (I now don’t have a hxcpp.dll, or a makefile – I use a neko script) and the way external dlls are linked (I can now use the same dll for neko and hxcpp). These are both very good things to get out of the way. It also means that the NME release can be independent of the compiler release.
    So the main things todo are to tidy up the iphone target and sort out the odd compiler problems that some people had when cl.exe failed to run.
    I would like to say a week or two, but these things have a way of taking longer.
    Re the particle code – the API still presents a flash.display.DisplayObject, so you can put stuff over the top. However, it uses copy pixels on flash, so you probably want to combine it with your copyPixels into a single bitmap. Perhaps I (we) can add specific support for particles to produce an optimised iphone/flash sprite(in 1980s sense)/particle rendering engine.

  9. Okay great- i didnt realize it would be working on a displayObject – thats perfect. I’m sure i’ll be able to work something out when the time comes. I dont want to steal your thunder by too many pokey questions – but how is the OpenGLES going? Is the speed up to a reasonable pace – better than 2.5fps? ;P

  10. Hi tony – yep, I got it up to 10fps, and I still have a few ideas. This is probably a bad example because it re-creates the line drawings every frame, rather than using bitmaps. I’ll let you know more soon 🙂

  11. I really hope this project comes to fruition, as it has a great potential of simplifying iPhone game development.

    A pity you’re only getting ~10fps in OpenGLES though. Still, i’m betting there’s a whole load of room for optimization as from experience i’ve noticed there are various neat tricks one can use to improve rendering performance with GLES on the iPhone.

    Good luck. 🙂

  12. Hi James,
    I’m getting about 40fps for a simple sprite based game. The physaxe example sufferes from too many vector graphics changes. Also, my font implementation was not that good, so I still think there is room for improvement. I think I’ll try to get the code out very soon, and then work on some more optimisations.

    1. Hi,
      There is currently no direct path from flash->iphone. To uses this code, you would first need to port your flash code from flash to haxe – the languages are very similar so it should be reasonably easy, although not trivial. Once you have the haxe code, you can then compile for iphone. There may be some performance issues, so some final tweaking may be required.

Leave a Reply

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