Welcome!
This is the community forum for my apps Pythonista and Editorial.
For individual support questions, you can also send an email. If you have a very short question or just want to say hello — I'm @olemoritz on Twitter.
3D / Physics support?
-
How about pygame? One of the things I like about pythonista (in contrast to Codea, which I do love) is the traditional procedural architecture; you're not forced into an event loop, which makes certain types of programming (I'm looking at the http server example, which makes me very happy) much easier. Python has pygame, it's very popular, and I suspect a nice chunk of code would be able to come over unmodified.
-
Not sure if that's possible, haven't looked into it in enough detail... The problem with a lot of libraries that aren't "pure python" (i.e. use native code for performance-critical stuff) is that they often rely on linking dynamic libraries. While technically possible, iOS apps aren't allowed by Apple to include dynamic libraries, which makes porting these things pretty difficult.
So, yes, PyGame is an interesting option and I think I'll look into that at some point, but I wouldn't be surprised if porting it turns out to be quite difficult or maybe impossible.
-
I can see what you're saying about 3D being too complex for an interpreted language to reasonably use large-scale.
PyGame relies on SDL, and I believe that SDL is ported to iOS. So long as all of the libraries are compiled statically (.a files instead of .dylib), the final executable will be just one standalone file and therefore allowed by Apple. The only problems that I forsee with porting PyGame are getting it to display on an iOS screen and making it understand touch events. Porting it to ARM shouldn't be too dificult as I'd imagine that it has already been ported to arm.
In any case, good luck with the app. In case I gave the wrong impression, I don't want this to turn into Codea but using Python instead of Lua. It's just that Codea has some nice features included with it that Pythonista doesn't have, but the opposite is true as well.
-
The big thing with converting PyGame will be converting NumPy, and if I remember right, NumPy hooks into a C code block.
-
Oh, I forgot that pygame uses numpy. I actually tried porting numpy about a month ago but didnt get very far. I don't have a Mac though, so I do all of my development on my iPad. I may try again later.
-
Maybe Box2D and its pure python wrapper PyBox2D would work? I know that Box2D works on iOS, though the Python wrapper might need to be tweaked somewhat.
-
Yes, numpy would be very difficult to port, I've experimented with it a little, but didn't get very far (for one thing, it seems to require a Fortran compiler...). I'm not sure if PyGame really requires numpy, from what I've read, it seems to be optional, but again, haven't looked into it in much detail yet.
-
Yeah, fortran is the part that stopped me, as the iPad doesn't have a fortran compiler. I've never used pygame before, so I don't know for sure whether it requires numpy or not.
-
I didn't try it, but according to the scipy/numpy docs, only scipy needs fortran. Numpy only needs a C compiler. So numpy alone might be doable after all.
-
Now that NumPy is supported, would that open the gates for porting PyGame?
Or is the new Scene module equivalent to it in functionality? -
@nascif - there had been recent discussion about this again. You can find some of it by searching for kivy in the forum. This other project has SDL/Pygame working on IOS. However, the rest of the info in this thread remains true. You still have to make everything link into one big static library in an IOS App and this is a lot of work and then ongoing maintainence.
I looked at kivy recently and found that they don't have an IDE that runs on IOS - only on desktop OS's. This is where Pythonista really shines and keeps getting better and better.
Since you mention Numpy, I would love to read an article from omz on what his experience was getting this port done.