Python/pygame Vs G++
- Thread starter scyzor
- Start date
Got to love the ignorance.
Few points:
1) C and C++ are different languages. Now go google the differences and understand them.
2) Python is awfully slow. You WILL NOT be wanting to write games with it. While you CAN make your regular 2D platform adventure with it, over time as you add featues and want more bling, you will run into problems. Just forget about it. Please.
3) C++ is kind of "big" compared to C. This means, on embedded devices you dont want to use C++. Do you really need object oriented programming or generic programming? Why don't you just stick to procedural programming and use C? Let me give an example; a generic swap function in C, which uses void*'s for arguments only takes one copy of the function definition per data types used. In C++ you'd use templates, which means that for every possible call to that function with different variable types, the compiler would generate it's own function definition. What if our function includes another inline'd function? Well, to put it short, you would end up having WAY, WAY more compiler generated USELESS code to fill the(Very limited!) CPU caches and registers with. -> Not good. Stick to C. However, with Pandora, I am sure one can use C++, its just that the environment is somewhat more limited than with typical x86 computer, using pure C(or even just procedural programming with C++) may show some benefit.
4) To use external libraries, the libraries need to be compiled for ARM. You can't just use library A just because "It's cross platform, works on linux and windows" unless you've compiled it for ARM. And difference between x86 and ARM is way wider than difference between Linux and Windows.
5) Learn programming with your computer first. Now it is GREAT time to learn the basics instead of "I'm waiting for pandora so I can start learning". I still suggest to start out with Python, it is simple, it is powerful and it is enough for you to understand that making even a simple 2D game is no walk in the park. However, don't consider C or C++ to be "big bad monster" either. While they can be considered as "hard" languages, it is just because it is YOU who writes the code. The compiler does EXACTLY as you tell it to do. If you tell it to bang it's head to a wall, it tries to do it. It won't tell you "Oh well, you're doing something stupid here, I wont't do that". If you have access to 10 blocks of memory, and you try to access to 11th block, Java or C#, BASIC etc will just tell you that "Oh, I won't do that because I am allowd to access 10 blocks only". C/C++ compiler will not care, it will try access that block(11th, which you dont have access to). It won't check anything, just do what it's told to do. It won't hold your hand. If something fails, YOU are to be blamed for it. It is fast. It is elegant. It is pretty. It is powerful.. AND it is dull at you. Kind of like a very sharp knife. If you know what you're doing, it will be the best tool available. If you dont know what you're doing, you will just end up cutting your fingers. But then again, you learn from your mistakes, and eventually you DO know what youre doing -> youre proficient with C/C++ and you pity the rest.
Few points:
1) C and C++ are different languages. Now go google the differences and understand them.
2) Python is awfully slow. You WILL NOT be wanting to write games with it. While you CAN make your regular 2D platform adventure with it, over time as you add featues and want more bling, you will run into problems. Just forget about it. Please.
3) C++ is kind of "big" compared to C. This means, on embedded devices you dont want to use C++. Do you really need object oriented programming or generic programming? Why don't you just stick to procedural programming and use C? Let me give an example; a generic swap function in C, which uses void*'s for arguments only takes one copy of the function definition per data types used. In C++ you'd use templates, which means that for every possible call to that function with different variable types, the compiler would generate it's own function definition. What if our function includes another inline'd function? Well, to put it short, you would end up having WAY, WAY more compiler generated USELESS code to fill the(Very limited!) CPU caches and registers with. -> Not good. Stick to C. However, with Pandora, I am sure one can use C++, its just that the environment is somewhat more limited than with typical x86 computer, using pure C(or even just procedural programming with C++) may show some benefit.
4) To use external libraries, the libraries need to be compiled for ARM. You can't just use library A just because "It's cross platform, works on linux and windows" unless you've compiled it for ARM. And difference between x86 and ARM is way wider than difference between Linux and Windows.
5) Learn programming with your computer first. Now it is GREAT time to learn the basics instead of "I'm waiting for pandora so I can start learning". I still suggest to start out with Python, it is simple, it is powerful and it is enough for you to understand that making even a simple 2D game is no walk in the park. However, don't consider C or C++ to be "big bad monster" either. While they can be considered as "hard" languages, it is just because it is YOU who writes the code. The compiler does EXACTLY as you tell it to do. If you tell it to bang it's head to a wall, it tries to do it. It won't tell you "Oh well, you're doing something stupid here, I wont't do that". If you have access to 10 blocks of memory, and you try to access to 11th block, Java or C#, BASIC etc will just tell you that "Oh, I won't do that because I am allowd to access 10 blocks only". C/C++ compiler will not care, it will try access that block(11th, which you dont have access to). It won't check anything, just do what it's told to do. It won't hold your hand. If something fails, YOU are to be blamed for it. It is fast. It is elegant. It is pretty. It is powerful.. AND it is dull at you. Kind of like a very sharp knife. If you know what you're doing, it will be the best tool available. If you dont know what you're doing, you will just end up cutting your fingers. But then again, you learn from your mistakes, and eventually you DO know what youre doing -> youre proficient with C/C++ and you pity the rest.
mindlord
Notices Two Things
Preach it brother! I swear if I could travel back in time and tell myself at age 12 to turn my back on Basic forever, and start learning C/C++. I'd be a happier, wealthier man today. I spent years fretting over C and how "hard" it was. I was afraid it was going to take a long long time to learn. I finally convinced myself to try and to my amazement quickly found out how liberating, and *gasp* easy it really was.
My advice, start with C, skip over any language that has "interpreted" anywhere near it, unless someone is paying you to learn it. C++ has its place too, and the Pandora will be happy to run your programs should you choose to use it.
My advice, start with C, skip over any language that has "interpreted" anywhere near it, unless someone is paying you to learn it. C++ has its place too, and the Pandora will be happy to run your programs should you choose to use it.
rabidpoobear
Active Member
You guys stick with your lower-level languages, I'll stick with my high-level ones, you have fun writing swap functions and debugging your segfaults, and I'll have fun writing actual softwaremindlord said:
Last edited by a moderator:
PoisonedV
Yeah, I'm a GIRL gamer, what of it?
jesus christ give it a rest at this point you aren't helping op at all just confusing them, that is, if they even care enough to continue reading the thread, which they may as well not. I wouldn't blame them.
rabidpoobear said:You guys stick with your lower-level languages, I'll stick with my high-level ones, you have fun writing swap functions and debugging your segfaults, and I'll have fun writing actual softwaremindlord said:
I'll elaborate for the people with less knowledge; First that above is a great example of provoking post, possibly intentional one. Someone was feeling bad/frustrated when writing it. Don't fall for them.
That put aside; C/C++ are called low-level languages due to the fact that they lack many of the common features found in other languages, because they focus on fast and portable code. Thus said, the generated code is fast and small. In other words C/C++ programs are efficient. How efficient? (This is based on a relatively small set of software, but it gives a good overview) C(gnu gcc) vs. Python 3; Python generates 4-360 times slower, and 0.2-38 times bigger programs in terms of RAM, though Python programs can be written with over 50 % less lines of code as compared to C programs. C vs. C# (C# Mono); C# generates 1-53(usually 1-14 though) times slower, and 0,5 - 12 times bigger programs in terms of RAM usage. C and C# share about the same amount of code lines. This information comes from here: http://shootout.alioth.debian.org
Basically, C is THE fastest language out there. But it comes with a cost - its usually faster(and somewhat easier, at least as a beginner) to write code with higher level languages. Doesn't help you to get the game running in 2 weeks, if it can't run fast enough. For same reason doesn't help you to get the program finish its job in 0,1 second when it took 2 weeks to write, as opposed to 2 days to write and finishing the job in 3 seconds.
Fast and easy development comes with a cost, as does fast program execution and efficient system resource use. It's stupid to stick to one language only, they are just tools for the task. Best builders use wide variety of tools, just like best programmers and developers use wide variety of languages, some fast, some easy. It's best to choose the right tool for the right task. Use higher level languages where the speed or system resources aren't that expensive. Use low level languages when you work with heavy software and under limited system resources.
I'd stick to C or C++ with Pandora.
Last edited by a moderator:
bzar
A Commando
Calmatory said:rabidpoobear said:You guys stick with your lower-level languages, I'll stick with my high-level ones, you have fun writing swap functions and debugging your segfaults, and I'll have fun writing actual softwaremindlord said:
I'll elaborate for the people with less knowledge; First that above is a great example of provoking post, possibly intentional one. Someone was feeling bad/frustrated when writing it. Don't fall for them.
That put aside; C/C++ are called low-level languages due to the fact that they lack many of the common features found in other languages, because they focus on fast and portable code. Thus said, the generated code is fast and small. In other words C/C++ programs are efficient. How efficient? (This is based on a relatively small set of software, but it gives a good overview) C(gnu gcc) vs. Python 3; Python generates 4-360 times slower, and 0.2-38 times bigger programs in terms of RAM, though Python programs can be written with over 50 % less lines of code as compared to C programs. C vs. C# (C# Mono); C# generates 1-53(usually 1-14 though) times slower, and 0,5 - 12 times bigger programs in terms of RAM usage. C and C# share about the same amount of code lines. This information comes from here: http://shootout.alioth.debian.org
Basically, C is THE fastest language out there. But it comes with a cost - its usually faster(and somewhat easier, at least as a beginner) to write code with higher level languages. Doesn't help you to get the game running in 2 weeks, if it can't run fast enough. For same reason doesn't help you to get the program finish its job in 0,1 second when it took 2 weeks to write, as opposed to 2 days to write and finishing the job in 3 seconds.
Fast and easy development comes with a cost, as does fast program execution and efficient system resource use. It's stupid to stick to one language only, they are just tools for the task. Best builders use wide variety of tools, just like best programmers and developers use wide variety of languages, some fast, some easy. It's best to choose the right tool for the right task. Use higher level languages where the speed or system resources aren't that expensive. Use low level languages when you work with heavy software and under limited system resources.
I'd stick to C or C++ with Pandora.
Yes, and now profile your typical pygame game, and you'll see it spends most of its processor time in SDL function calls, which are internally just as efficient as wit C/C++ (because pygame is just a wrapper around SDL). Same for physics (pybox2d for example), IIRC. Yes, pure python programs are slower and more memory-consuming than their lower-level counterparts, but the point is, that if you only use python to do the parts which are not (asymptotically) significant performance-wise, you'll get a result nearly as efficient as with C/C++. Performance results gained with pure single-language tests do not reflect the actual use case, and thus are not accurate in this case.
Say what you say about portability, but python programs are portable given that the required libraries are ported, same as everyone else. The difference is that python programs themselves rarely require major porting, chiefly regarding screen resolution, controls and that kind of stuff.
If your program, however, attempts to get every last nanogram of performance out of the platform, go with C. Otherwise you might as well use a good C/C++ engine/library with python bindings.
Last edited by a moderator:
rabidpoobear
Active Member
Calmatory said:
As was said before by B-ZaR, you will hardly ever find a program in Python that is implemented completely in Python.
If you are, say, using hash tables, or sorting lists, Python's versions of this functionality are much much more efficient than any you could hope to write yourself in C. Python's standard library IS C, and it's VERY GOOD C. Python is just gluing these pieces together.
If you write a program completely in pure python, it will be a hell of a lot slower than the C program. But you don't. Python has a fantastic stdlib and you leverage this to make your life easier, and because they're better at that stuff than you are (not you specifically, the general "you").
If you find a part of your Python program is slow, you rewrite THAT ONE PART in C. That's the rub, you still need to know C.
Yes, I completely agree, you shouldn't know just one language. I know a ton of languages. But in almost every case I can write a Python program that is as fast as I need it to be. And in the few cases I can't, I can rewrite the performance-intensive parts in C. No reason to use a low level language for the whole program.
Part of being a programmer is, as you said, being able to identify the best tool for the job, and one of the biggest factors in deciding that tool is speed of development and maintenance cost, and Python programs have historically proven to be much better than C in both regards.
People tend to jump all over Python because it's interpreted, it's slow, it doesn't run on multiple cores, etc, etc. I agree that, in some cases, efficiency is key. But I also think that these cases are much fewer and further between than some would want to admit. Besides, Python's rapid development makes good throwaway prototypes, and even if you end up rewriting the whole thing in C, it will help you make a lot of architectural decisions before you even get to the C development, and will probably reduce your overall development time anyway since you won't pursue unfruitful avenues.
Hopefully that's less baited of a reply.
Last edited by a moderator:
Rockthesmurf
Advanced Member
emil10001 said:
An interesting read, puts me off wanting to write any code that has to be *that* portable, as half of it is about getting around compiler bugs.
Steve
Last edited by a moderator:
dflemstr
It's a ball.
Just wanted to throw in my contribution in this discussion. I don't want to provoke anyone here, I just speak from my own experience.
First of all, I'll say that I've done a wide variety of things when it comes to programming. Everything from building complete websites to programming security door switches to OpenGL programming to writing (albeit simple) Linux device drivers. I've dealt with everything from C to Haskell to Erlang to VisualBasic to Python/Ruby to Java.
Now, here's what I'll say about various programming languages and how they're suited for game development:
C/C++: (Yes, they are similar enough after compilation that there really isn't that much of a speed difference, except for template stuff as mentioned above)
Great languages for the situations when you want speed, but only for situations when you really need the speed. If I was to write a physics engine, I would use C/C++. If I want to write a program that spends 80% of its time inside OpenGL calls, I wouldn't. And, believe it or not, many games today are slowly more and more just becoming event dispatchers: you're waiting for input from everywhere and, if no input is given, you do nothing. It's not like in the old days where you'd have to have a game loop constantly running to check if that byte representing that key would change, and where you'd have to optimize that loop to hell, or you'd miss the keypress. And when you think about it, you don't even find tight-bound loops anywhere else in your code either (except for when you want to make physics engines etc). This means that your code is executed every once in a while, and then almost only once. So why would you need that extra C speed? Where would you need it, except for hotspots?
Python:
It's slow, but extremely flexible. If I need to generate code at runtime that I then want to execute semi-quickly, I'll use Python. Now, I'm not a fan of dynamic typing, first because it's extremely for a compiler/JIT-compiler to optimize dynamic code in any shape or form, and secondly because you loose control over a huge aspect of your program. Also, it doesn't really give you any benefits; you can do everything that you can do with Python dynamic typing using C++ polymorphism and small wrapper functions (the wrap pattern etc); the only difference is that C++ needs more syntax.
Yeah, yeah, Python uses C++ modules to accelerate hotspot parts of your program, but you can't tell me that that's a Python feature, since 1. C isn't Python and 2. you can do exactly the same thing in almost every other language in existence (including freaking VisualBasic!)
I'll use Python any day for writing extension scripts for my game, but probably not anything else. I would never dream of writing the heavily multi threaded "central core" of a game in Python, what with Python's global locks and all those shenanigans.
Java:
Extremely horrible syntax and a ripoff of C++, except slower. However, the JVM is something I think is more interesting. Imagine compiling code that can run on every platform in existence without changes (Yes! It's possible, and it's easier than you think! You can run it on mobile phones, even!), and that will be optimized at runtime for your specified platform! No other system can do that (except for the CLI and LLVM of course; similar technologies); you can't write a C++ program for instance that will use that extra vector SIMD instruction of your new CPU without recompilation.
Also, not having to worry about different primitive sizes, or different initialization technologies on different platforms does make a difference (you create a window the same way on Windows, x86 Linux and Symbian devices; no code changes). Same goes for things such as OpenGL: I make a program using the (OpenGL ES 2.0 & OpenGL 2.0) subset of the OpenGL spec, and the program runs flawlessly on OpenGL ES 2.0 devices as well as on OpenGL 2.0 devices, again, without recompilation. That makes a huge difference when it comes to development time (without sacrificing execution speed really; Java might be only 50% as fast on sunny days as C is, but that is more than enough and Java is still 8-32 times faster than Python in most situations)
However, those features are not features of the Java language, but of the JVM. So I therefore often choose to use different languages for the JVM (there are hundreds, as you all know) including JRuby, Jython (that are exactly like their interpreted counterparts, except that they run much faster on the JVM), Scala (Finally a *Statically Typed* feature-rich programming language!), Groovy, etc. Even C++ runs on the JVM if you want it to (but for C++, LLVM is a better alternative).
Oh and BTW, yes it blows that a "byte" in Java-code takes up 16 (!!) bytes of actual memory, but you do actually never really need to deal with individual bytes in Java. If you want to load, say, a binary file (it happens, right?) you just create a ByteBuffer which stores the bytes using one byte per byte (imagine that!), or even just a normal "byte[]" array that uses a 4-byte header and then stores bytes one byte per byte as well, and you even gain performance by doing so (because the ByteBuffer uses unmanaged memory, arrays do not but give you faster access anyways). It's only JVM newbies that write code using loads of memory in Java; Java can actually be very memory-efficient if you know how to make it so. It's the same thing with C++ really; a C++ noob will do stupid things (I've seen guys that extend a class instead of friending it. Yeah.) and so will a noob Python programmer. Accept it the way it is, and don't blame the JVM for penalizing a bad Java programmer more than gcc penalizes a bad C programmer (when it comes to memory at least; bug-nastiness is another topic entirely).
First of all, I'll say that I've done a wide variety of things when it comes to programming. Everything from building complete websites to programming security door switches to OpenGL programming to writing (albeit simple) Linux device drivers. I've dealt with everything from C to Haskell to Erlang to VisualBasic to Python/Ruby to Java.
Now, here's what I'll say about various programming languages and how they're suited for game development:
C/C++: (Yes, they are similar enough after compilation that there really isn't that much of a speed difference, except for template stuff as mentioned above)
Great languages for the situations when you want speed, but only for situations when you really need the speed. If I was to write a physics engine, I would use C/C++. If I want to write a program that spends 80% of its time inside OpenGL calls, I wouldn't. And, believe it or not, many games today are slowly more and more just becoming event dispatchers: you're waiting for input from everywhere and, if no input is given, you do nothing. It's not like in the old days where you'd have to have a game loop constantly running to check if that byte representing that key would change, and where you'd have to optimize that loop to hell, or you'd miss the keypress. And when you think about it, you don't even find tight-bound loops anywhere else in your code either (except for when you want to make physics engines etc). This means that your code is executed every once in a while, and then almost only once. So why would you need that extra C speed? Where would you need it, except for hotspots?
Python:
It's slow, but extremely flexible. If I need to generate code at runtime that I then want to execute semi-quickly, I'll use Python. Now, I'm not a fan of dynamic typing, first because it's extremely for a compiler/JIT-compiler to optimize dynamic code in any shape or form, and secondly because you loose control over a huge aspect of your program. Also, it doesn't really give you any benefits; you can do everything that you can do with Python dynamic typing using C++ polymorphism and small wrapper functions (the wrap pattern etc); the only difference is that C++ needs more syntax.
Yeah, yeah, Python uses C++ modules to accelerate hotspot parts of your program, but you can't tell me that that's a Python feature, since 1. C isn't Python and 2. you can do exactly the same thing in almost every other language in existence (including freaking VisualBasic!)
I'll use Python any day for writing extension scripts for my game, but probably not anything else. I would never dream of writing the heavily multi threaded "central core" of a game in Python, what with Python's global locks and all those shenanigans.
Java:
Extremely horrible syntax and a ripoff of C++, except slower. However, the JVM is something I think is more interesting. Imagine compiling code that can run on every platform in existence without changes (Yes! It's possible, and it's easier than you think! You can run it on mobile phones, even!), and that will be optimized at runtime for your specified platform! No other system can do that (except for the CLI and LLVM of course; similar technologies); you can't write a C++ program for instance that will use that extra vector SIMD instruction of your new CPU without recompilation.
Also, not having to worry about different primitive sizes, or different initialization technologies on different platforms does make a difference (you create a window the same way on Windows, x86 Linux and Symbian devices; no code changes). Same goes for things such as OpenGL: I make a program using the (OpenGL ES 2.0 & OpenGL 2.0) subset of the OpenGL spec, and the program runs flawlessly on OpenGL ES 2.0 devices as well as on OpenGL 2.0 devices, again, without recompilation. That makes a huge difference when it comes to development time (without sacrificing execution speed really; Java might be only 50% as fast on sunny days as C is, but that is more than enough and Java is still 8-32 times faster than Python in most situations)
However, those features are not features of the Java language, but of the JVM. So I therefore often choose to use different languages for the JVM (there are hundreds, as you all know) including JRuby, Jython (that are exactly like their interpreted counterparts, except that they run much faster on the JVM), Scala (Finally a *Statically Typed* feature-rich programming language!), Groovy, etc. Even C++ runs on the JVM if you want it to (but for C++, LLVM is a better alternative).
Oh and BTW, yes it blows that a "byte" in Java-code takes up 16 (!!) bytes of actual memory, but you do actually never really need to deal with individual bytes in Java. If you want to load, say, a binary file (it happens, right?) you just create a ByteBuffer which stores the bytes using one byte per byte (imagine that!), or even just a normal "byte[]" array that uses a 4-byte header and then stores bytes one byte per byte as well, and you even gain performance by doing so (because the ByteBuffer uses unmanaged memory, arrays do not but give you faster access anyways). It's only JVM newbies that write code using loads of memory in Java; Java can actually be very memory-efficient if you know how to make it so. It's the same thing with C++ really; a C++ noob will do stupid things (I've seen guys that extend a class instead of friending it. Yeah.) and so will a noob Python programmer. Accept it the way it is, and don't blame the JVM for penalizing a bad Java programmer more than gcc penalizes a bad C programmer (when it comes to memory at least; bug-nastiness is another topic entirely).
rabidpoobear said:
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.
2) V8 is about 10 times faster than Python.
3) Good Java VMs (e.g. IcedTea or Sun's) are way faster than V8. The native code generation is smarter and the GC is also more advanced. (V8's GC is way better then simple ref counting though.)
Python really isn't famous for its performance. On the Wiz Python/Pygame is so goddamn slow that it's barely usable for very simple things. As soon as you draw 100 puny 16x16 sprites (and nothing else) which bounce around on the screen it drops down to
0fps.The Wiz got a 320x240 display, which means you'd have to draw 336 (21*16) 16x16 tiles to cover the screen just once. If you're using 3 layers you get even more looping. And then you still need some foreground graphics, sound, and of course some game logic. This doesn't work.
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.
Last edited by a moderator:
WizardStan
Mega GP Mania
- Joined
- May 24, 2008
- Messages
- 16,731
So because the Wiz implementation is poor, all implementations (or at least the Pandora version that doesn't exist yet) are therefore poor?aho said:Python really isn't famous for its performance. On the Wiz Python/Pygame is so goddamn slow that it's barely usable for very simple things. As soon as you draw 100 puny 16x16 sprites (and nothing else) which bounce around on the screen it drops down to
Last edited by a moderator:
Close. Because the Wiz implementation performs poor, all similar implementations (on similarly weak platforms) will suffer from the same issues.WizardStan said:So because the Wiz implementation is poor, all implementations (or at least the Pandora version that doesn't exist yet) are therefore poor?aho said:Python really isn't famous for its performance. On the Wiz Python/Pygame is so goddamn slow that it's barely usable for very simple things. As soon as you draw 100 puny 16x16 sprites (and nothing else) which bounce around on the screen it drops down to
The problem is the interpreter. It simply isn't very fast (graphics/audio via SDL or whatever is of course alright). Well, if you convert it to native code things look different. Or if you convert it to JS (via Pyjamas) and let it run in V8 it's also a lot faster.
But the usual thing (i.e. the same kind of interpreter you're running on your desktop or laptop) is just very slow and it doesn't really look like this will change anytime soon.
Last edited by a moderator:
skeezix said:"C++" and "portability" used in the same breath?
Ahh, people who've never done mobile or embedded work before
jeff
Panda is a standard linux machine, but in general for C++ on embedded machines .. you watch your rtti and exceptions carefully
shouldn't be using rtti and exceptions in a game engine anyway, rtti isn't really usefull for games and its too easy to live without,
and exceptions are a really really bad idea, they're worst than any GOTO could ever hope to be.
goto makes the program jump from point A (the goto) to point B (the label) and they're judged evil for making program flow unclear,
exceptions jump from "you don't really know where" to "you don't really know where either", and somehow a lot of people thought it was the best thing ever. :blink:
(go go flame war)
about OpenGL ES, you can either use OpenGL using only ES-compatible stuff (draw arrays, no GL_QUADS) or have an OpenGL wrapper layer over OpenGL ES and add glBegin / glEnd support QUADS to TRIANGLES translation, etc.
which is really easy to do, very small code-wise, and have little performance impact, to the point where one wonders why they bothered designing the crippled OpenGL ES.
btw, shouldn't this topic be moved to "developers' corner" ?
Last edited by a moderator:
PoisonedV
Yeah, I'm a GIRL gamer, what of it?
xkcd sucks stop posting it
skeezix
Internal Development
holy crap, so much BS
- 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
- Python certainly can be used for games; you might look into Civilizatoin, EVE Online and others; that said, those are non-handhelds.
- Python is generally not compiled to native code (yet), while a good Java JVM often is. Of course, Python can be compiled to native, and Java could not be.. it dpeends on the tools, the platfornm, etc. A Java JVM for ARM with native compiler ... not so likely right now, but a number of candidates are around. Anyway, people arguigng between Python and Java .. its just not a pretty scene. It is better to encourage each other
- my snide bitterness; the only real portable language is C. Not Java, not C++, not C#, nada.. just straight C. Its a shame things have come so far, yet this is the true reality. (Consider mobile phones right now .. ObjC versus crippled Java (RIM) versus full Java on a non-quite-java-JVM (Android), all with custom UI systems.. its only gotten worse over the last decade, not better! (Least Palm OS and WinCE both used C and C++, though with different UIs and their own cripples... don't get me started
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
^- use CLOS (Common Lisp) like a man. clisp _does_ run on Pandora!
- 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
- Python certainly can be used for games; you might look into Civilizatoin, EVE Online and others; that said, those are non-handhelds.
- Python is generally not compiled to native code (yet), while a good Java JVM often is. Of course, Python can be compiled to native, and Java could not be.. it dpeends on the tools, the platfornm, etc. A Java JVM for ARM with native compiler ... not so likely right now, but a number of candidates are around. Anyway, people arguigng between Python and Java .. its just not a pretty scene. It is better to encourage each other
- my snide bitterness; the only real portable language is C. Not Java, not C++, not C#, nada.. just straight C. Its a shame things have come so far, yet this is the true reality. (Consider mobile phones right now .. ObjC versus crippled Java (RIM) versus full Java on a non-quite-java-JVM (Android), all with custom UI systems.. its only gotten worse over the last decade, not better! (Least Palm OS and WinCE both used C and C++, though with different UIs and their own cripples... don't get me started
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
^- use CLOS (Common Lisp) like a man. clisp _does_ run on Pandora!
dflemstr
It's a ball.
The right tools for the right job. Those words have always been true and will remain true. It's always a balance between how hot you want the developer to become and how frustrated you want your machine to become (and vice versa).
Yeah, sure, C is portable as heck but it's a pain to deploy C programs for multiple platforms (have you guys ever had to make multiple RPMs/DEBs/EXEs/DMGs for multiple architectures etc? Different package dependencies, different ABIs, different instruction sets, different compilers... It takes a *lot* of scripts to automate the process). But for that, the program will run "flawlessly" on all platforms (provided that the correct library versions are available everywhere and portable C is used).
And Java, well, it has the disadvantage of running a bit slower on all platforms, but then you should look at the kind of build process you gain access to. For example, take a look at the README.markdown for the QuantumDrive project (we called it SpaceRTS before; also note that that repo doesn't contain any actual code atm except for the build framework). I can, with one single command, using 0 cross compilers, deploy to everything from windows-i586 to solaris-sparcv9. The build script will create a ZIP for me, include the correct Java .so/.dll/.jnilib extensions automatically (as said, Java uses native extensions like Python does to accelerate vital parts), create launch scripts etc. I can build on any platform and deploy to any platform, still using one single command. It's incredibly helpful, and saves me days of packaging the app for multiple platforms.
The same is probably true for Python (It's supposed to be flexible like that but I have no experience of packaging Python programs in RPMs and whatnot). Still, it's better than deploying C for sure. Again, the performance/convenience tradeoff.
If you feel that you have the need for more developer-friendly development and are willing to sacrifice some performance, then I say that it's worth it. You might not agree, but then we all have different opinions etc.
Yeah, sure, C is portable as heck but it's a pain to deploy C programs for multiple platforms (have you guys ever had to make multiple RPMs/DEBs/EXEs/DMGs for multiple architectures etc? Different package dependencies, different ABIs, different instruction sets, different compilers... It takes a *lot* of scripts to automate the process). But for that, the program will run "flawlessly" on all platforms (provided that the correct library versions are available everywhere and portable C is used).
And Java, well, it has the disadvantage of running a bit slower on all platforms, but then you should look at the kind of build process you gain access to. For example, take a look at the README.markdown for the QuantumDrive project (we called it SpaceRTS before; also note that that repo doesn't contain any actual code atm except for the build framework). I can, with one single command, using 0 cross compilers, deploy to everything from windows-i586 to solaris-sparcv9. The build script will create a ZIP for me, include the correct Java .so/.dll/.jnilib extensions automatically (as said, Java uses native extensions like Python does to accelerate vital parts), create launch scripts etc. I can build on any platform and deploy to any platform, still using one single command. It's incredibly helpful, and saves me days of packaging the app for multiple platforms.
The same is probably true for Python (It's supposed to be flexible like that but I have no experience of packaging Python programs in RPMs and whatnot). Still, it's better than deploying C for sure. Again, the performance/convenience tradeoff.
If you feel that you have the need for more developer-friendly development and are willing to sacrifice some performance, then I say that it's worth it. You might not agree, but then we all have different opinions etc.
samuraicrow
Member
JackTheKnife said:Are there any good tutorials and books for ARM programming (Python and GCC)? I'm not totally noob with coding (PHP, ANSI C for device drivers/controllers, old Amiga stuff like ASM for MC68000 and AMOS) but I need to find something to start before I will get Pandora
If Amos: The Creator is the most you've worked with, I'd suggest you stick with Python and PyGame for now. Google has people working on the problems with Python speed in their Unladen Swallow project based on LLVM. As for Java being faster as some people pointed out, Jython will get your Python code running on a Java Virtual Machine anyway so you might as well skip Java. Python is simpler anyway.
As for tutorials, I usually recommend How to Think Like a Computer Scientist: Programming in Python. There are hardcopies available but also an online version. It is text-only but will get you started. Once you're familiar with Python syntax you can start picking up PyGame.
Last edited by a moderator:
dflemstr
It's a ball.
Yeah exactly, as I said before: Java sucks, JVM languages own. If I develop anything big for personal use, I always use Scala for instance (I've never used a more easy-to-use and intuitive language). And if I need scripting in my project, I build it using Java/Scala and embed a Jython or JRuby interpreter that uses the JVM's JIT.Samurai_Crow said:
My dream is that there should be a similar set of languages for LLVM and that LLVM could take over the role of the JVM: you compile your program using your languages of choice and they will run everywhere. Yeah, I know that that was Microsoft's vision with the CLI but the CLI isn't widely adopted yet (never mind the political problems the CLI has faced in the OSS world).
BTW, I just thought of something: Haskell's gotta be a pretty portable language, isn't it? I mean, one spec to rule them all (the glasgow haskell compiler is all that's being used these days) and all that. And Haskell supports all of the libraries that C does and everything. Has anyone tried Haskell game programming?
Last edited by a moderator:
