Python/pygame Vs G++

[may88]

What a fascinating topic. Loving every word of it. Had the same dilemma myself and plumped for Python/Pygame.
Performance is a worry. Could do with a lovely Dev doing some benchmarking.

@OP - The answer is Both! :lol:

 

[aho]

[...]
- Python certainly can be used for games; you might look into Civilizatoin, EVE Online and others; that said, those are non-handhelds.
[...]

Yea, of course it can. But on the current handheld generation things look a bit meh. Things will surely look different with the next generation or the one after that.

[...] Python can be compiled to native, and Java could not be.. [...]

You can compile Java to native executables with Jet or GCJ. However, Jet is very expensive and GCJ is very slow. The biggest issue of GCJ is its stone-age garbage collection, which comes with a hefty performance hit. The only way to make it perform reasonably well is to avoid creating any garbage at all.

By the way there are many ARM compatible VMs which support some kind of just-in-time compilation. All of the smaller more popular VMs (CACAO, JamVM, Kaffe, and PhoneME) do support it these days. However, the amount of optimizations they can perform are rather limited.

IcedTea got a virtually ASM free hotspot interpreter (called Zero) and an LLVM based JIT (called Shark). These two components make the VM very compatible with all kinds of architectures such as PPC, IA64, S390, and ARM.

So, the first choice should be always IcedTea. However, it comes with a rather big memory footprint. On the Wiz you only got like 20 something mb of free memory... so, it doesn't really look like a good option. A more lightweight VM such as JamVM is probably a better choice. On the Pandora, however, there are a whopping 256mb, which means you surely have those 64mb you need for a advanced VM + some app.

Another thing you have to consider is the storage/download footprint. Python/Pygame and Java are unfortunately pretty bulky. V8 on the other hand only takes 2-3 MB (uncompressed). If you add some support for graphics, sound and input it takes probably another MB, but that's about it. So, you can put your small game and everything it needs in a ~3mb archive. Sounds very reasonable to me.

I'm currently trying to put some minimalistic V8 based platform together. It will support a subset of Canvas (that HTML5 thing), images (PNG), audio (Ogg/Vorbis), and input. The cool thing is that you can run it in any awesome browser... or develop it with the help of any good browser.

Now, what's interesting in this context is that the Pandora supports GLES 2.0, which means WebGL stuff could run on it in a similar fashion. And that would be pretty cool indeed.

 

[dflemstr]

I'm currently trying to put some minimalistic V8 based platform together. It will support a subset of Canvas (that HTML5 thing), images (PNG), audio (Ogg/Vorbis), and input. The cool thing is that you can run it in any awesome browser... or develop it with the help of any good browser.

Now, what's interesting in this context is that the Pandora supports GLES 2.0, which means WebGL stuff could run on it in a similar fashion. And that would be pretty cool indeed.

Awesome. Add me to the beta tester list (I can even contribute code if you want me to). Javascript isn't the best language in the world but if there was a simple game creation framework that would run in the freaking *Browser*, that would be amazing.

 

[rabidpoobear]

1) V8 can be compiled for ARM. And it still does that native code generation stuff there. A big part of the standard library is actually written in JS, which means it has to be compiled at startup. You can also do this just once and embed the resulting native code (snapshot). However, building for ARM with a snapshot is currently very difficult... so, you probably won't get this startup booster. On the Wiz starting takes about 2 seconds if there isn't a snapshot.

I apologize, I was completely in the wrong here, I thought V8 was closed-source.

On the Pandora you have a 800x480 display, which means you'd have to draw 416 (26*16) 32x32 tiles to cover the screen just once. If the Pandora isn't about 10 times faster than the Wiz, you won't be able to write a nice looking game which runs fast enough (>=30 fps).

Of course you can still write some kinds of games (e.g. puzzles) with Python, but scrolling 2D stuff probably isn't an option.

Um, yeah this will not be very good performance if you redraw every tile every frame. But why not just render the background to a big surface and just blit animated/moving sprites over it?

 

[dflemstr]

1) V8 can be compiled for ARM. And it still does that native code generation stuff there. A big part of the standard library is actually written in JS, which means it has to be compiled at startup. You can also do this just once and embed the resulting native code (snapshot). However, building for ARM with a snapshot is currently very difficult... so, you probably won't get this startup booster. On the Wiz starting takes about 2 seconds if there isn't a snapshot.

I apologize, I was completely in the wrong here, I thought V8 was closed-source.

On the Pandora you have a 800x480 display, which means you'd have to draw 416 (26*16) 32x32 tiles to cover the screen just once. If the Pandora isn't about 10 times faster than the Wiz, you won't be able to write a nice looking game which runs fast enough (>=30 fps).

Of course you can still write some kinds of games (e.g. puzzles) with Python, but scrolling 2D stuff probably isn't an option.

Um, yeah this will not be very good performance if you redraw every tile every frame. But why not just render the background to a big surface and just blit animated/moving sprites over it?

Or why not just use OpenGL and let the SGX deal with the drawing like it's supposed to?

 

[dbrodie]

I wanted to point out that if you want a 3d game I have been playing around with OGRE and it seems to have descent python bindings. I will PROBABLY be using it to write a game. I do not want to use C (even though that is what I read/write in my day job) because it is a pain compared to writing in python. I really think that, unless you have written a game once, write it using python. It will seriously be considerably more fun!

 

[Yoyobuae]

[...]
- for one, OO has little to do with language per se; some languages make it easier, but you can _certainly_ do OO in C. Consider the FILE "object", which has methods and encapsulatoin and data hiding. You can do Inheritance with some pointer magic even, or some handy functions. It ain't pretty, but my point stands. (Also consider that first C++ (CFront) was a recompiler to C.) anyway.. pednatic, I know
[...]

Another example: GObject library. It has pretty much everything needed do do OOP in C. Inheritance, polimorfism, etc. Everything well designed, with a set of conventions for writting a new objects and some naming conventions also.

I use it at work and, once I got used to it, enjoy programming with it.

 

[rabidpoobear]

I wanted to point out that if you want a 3d game I have been playing around with OGRE and it seems to have descent python bindings. I will PROBABLY be using it to write a game. I do not want to use C (even though that is what I read/write in my day job) because it is a pain compared to writing in python. I really think that, unless you have written a game once, write it using python. It will seriously be considerably more fun!

Speaking of which, I'm not sure if Panda3D is going to be ported to Pandora, but it's a really fantastic library and I recommend checking it out as well, even if just for desktop stuff. Ogre3D is good but Panda is based on its Python bindings (I.E. they designed it to be controlled form Python) so it's more pythonic in how it works.

As for Ogre3D, does anyone know if you can load shaders to the graphics card in Ogre through Python, or do you have to drop down to C++ to do it? I just started learning about shaders and Panda3D makes it really easy to use shaders from python (basically shader = loadShader('/path/to/my.sha') and then node.setShader(shader) ) and it'd be cool if Ogre did that as well. I'll probably ask the Ogre guys if no one here is familiar with it.

 

[may88]

@Jack-the-Knife

I found a cheap copy of The L Line's Game Programming by Andy Harris. ISBN: 978-0-470-06822-9
I think I was expecting more from this but it sure has got me started. Recommended to all with basic programming skills that want to get coding.

 

[rv6502]

So anyway.. and wait, GOTO. There is _nothing_ wrong with goto; in fact, there are times when its use is prettier and more desirable than some super nested structure; usually it is unwise to use a goto and leave it to the compiler, but remember.. most of your high level constructs are built on goto. Goto is the asm that got left in high level languages People who say 'no goto ever' are the other extreme, than 'always use it'. Programmers must be wise -- use the right tool, at the right time, the right way. Goto just might save your bacon, so if you close your mind, you're as bad as someone who uses it too much.

Anyway, couldn't resist the rant

jeff

LOL, 100% with you there.

I was commenting on how the same people who blindly complains about GOTOs (even well used ones) will say exceptions are a great invention even tho exceptions are in a sense extreme versions of GOTO with all the problems amplified.

its one of the huge hypocrisies of "magic OOP" and C++ advocate sheeps.

anyway, back on the subject of easy game development, why not try a modern BASIC (one that supports functions) ?

I tried googling for gnu basic and this came up (haven't tried it)
http://lbpp.sourceforge.net/
translates Liberty BASIC so that gcc can compile it.
I don't know if it supports decent function calls with parameters tho.

might be interesting for someone who just want to make a game.

too bad there aren't nice books about "how to use C++ and STL to write easy and safe code with somewhat acceptable performances and no headaches" they all go off into overly complicated academic BS very soon into the book.

NES games had on average max 5 to 10 objects on screen at a time not hundreds, SNES barely had double that.
shouldn't be too hard to reach that kind of performance on a Pandora in an interpreted language.
(if that's the kind of game the OP has in mind)

 

[geckojsc]

Wow, very useful thread here! The mention of other JVM languages has been stored at the back of my head for future use, it sounded very exciting.

 

[aho]

[...]

On the Pandora you have a 800x480 display, which means you'd have to draw 416 (26*16) 32x32 tiles to cover the screen just once. If the Pandora isn't about 10 times faster than the Wiz, you won't be able to write a nice looking game which runs fast enough (>=30 fps).

Of course you can still write some kinds of games (e.g. puzzles) with Python, but scrolling 2D stuff probably isn't an option.

Um, yeah this will not be very good performance if you redraw every tile every frame. But why not just render the background to a big surface and just blit animated/moving sprites over it?

Well, usually it's done like that and usually it's fast enough. E.g. on a 500mhz K7 or P3 drawing this "many" tiles is a piece of cake if you're using Java and an OpenGL binding. You could easily draw 2000 sprites at 60fps - even if you were doing it in the most stupid way (immediate mode rendering).

The most popular way on puny handsets with GLES support are so called meta tiles. You create a pile of VBOs which contain the geometry (and texture coords) for huge meta tiles which contain several tiles. When you then draw the scene you have to bind the texture just once and then draw at most 4 of those meta tile VBOs per layer. This minimizes the amount of native calls and it also batches things up very nicely. Doing it this way isn't possible with Pygame though.

I didn't bother trying anything else on the Wiz with Pygame since the performance was already too low with these few sprites. No matter how fast it might be to use some sort of cyclic buffer tiles[1]... there wouldn't be enough processing power left.

[1] E.g. you have 4 or 9 buffers which each contain a pile of tiles. These buffers scroll and wrap. And each frame you overdraw at most one full row and one full column. While it does sound like it might be worthwhile I haven't seen a graphics pipeline yet where doing something like that would be actually faster. You see... I had this idea ages ago, but I couldn't use it yet. So far the overhead always crushed the theoretical benefits.

 

[jlepley]

So if you, say, wrote a 3D game program with Python using the Venom Irrlicht binding, would it run almost as fast as a similar C++ program?

 

[samuraicrow]

So if you, say, wrote a 3D game program with Python using the Venom Irrlicht binding, would it run almost as fast as a similar C++ program?

Using the not-yet-finished Unladen Swallow version of Python, maybe. Using conventional Python, probably not. It just depends on how many calculations are done in the JIT and how many are done in the bindings. C++ based bindings are the same speed as C++ because they are written in C++.

 

[WizardStan]

So if you, say, wrote a 3D game program with Python using the Venom Irrlicht binding, would it run almost as fast as a similar C++ program?

Unlikely to run comparably to C++, but it won't be nearly as bad as some are suggesting. The limiting factor is likely to be in object manipulation, AI, that sort of thing. If you implement complex collision detection within python, then it'll be slow. Keep it simple, and let the library take care of the graphics, and it should be fast enough.

 

[Jourdy288]

too bad there aren't nice books about "how to use C++ and STL to write easy and safe code with somewhat acceptable performances and no headaches" they all go off into overly complicated academic BS very soon into the book.

I agree with you, one of the reasons I'm having trouble getting into programming is because I'm having trouble finding resources written in "English", or more accurately, layman's terms. I might learn the way I usually do; reverse engineering of open source programs. I'll pick them apart and learn which part does what, learning how these things affect each other. Maybe that is how I will learn. I have done it in the past with HTML.
Spoiler contains XKCD.

Spoiler

Randall Munroe brought out that if professors wrote for Simple Wikipedia we'd be in better shape academically. He's right.

 

[Calmatory]

Its the small things which add up as a whole. Simple 2D tilemap rendering isn't a big deal, easily implemented and runs flawlessly. Enough for most people. The problem arises when one wants to add more logic. Yes, you can write it in C, but that quite much defeats the purpose of using Python. Would be about the same just to use C and implement the simple parts with Python scripts. Regardless, it should be clear that one at least WANTS(if not NEEDS) to know both if one wants to make something more advanced than just a basic tile renderer and input system, at least when working with such a limited hardware as Pandora.

Taking the best from the both worlds is the ideal approach again, not really limited to Python or C/C++. One could try Lua and Ruby too, mix in some ARM assembly etc. This goes beyond beginners experience and needs though, but really would give benefits of high level languages fast development and low level languages fast execution. With some agile profiling and ingenious usage of these tools, one could get into VERY decent results with the game/engine speed, while allowing the users/other gamers to create and modify the game with simple Python/Lua/Ruby scripts. Everyone benefits and everyone is happy.