You are not logged in. Please login or register.
AudioGames.net Forum → Developers room → frameworks to develop audiogames
Uou!
first of all, thank you so much. I really didn't expected so any answers.
You all gave me a lot of things to think and try.
I agree about java. I tried to do something but tthe sound's api are horribles.
I'll give a look to all this frameworks. Many of them I've never listened before.
thank yu all!
what is the advantage of C# vs python for audio games?
In this vain, how does Ruby or Perl compare?
Ruby is something I could never figure out how to distribute. Perl is something that everyone I know universally hates; I personally gave up in disgust in about an hour and Python does all the same things.
The only big advantage of C# is that it is faster, but as I and others have pointed out before, there's no audiogame idea that would actually make you able to notice. To reiterate, when you start listing your performance problems, I'll start telling you about how you're using an array and shouldn't be or pointing you at libraries that can replace the slow components. A more minor advantage is size, but the sounds will dwarf everything anyway so it doesn't matter too much. I don't tink anyone here cares about SQL or Linq, being as these are the domain of business applications.
C# does have a couple killer disadvantages for me. The first and biggest is that there's no command line debugger. There used to be, but it was axed. It might be possible to use Cdb on it, but I've not played with this and it is certainly not simple. Debugging consequently requires living inside VS; I have already shared my opinion on that. Python is also slightly more cross-platform, but only slightly. The other advantages I could list are ideological and have to do with dynamic vs. static typing as well as my personal bent towards functional programming (Python's support for such isn't near Haskell, but it's pretty darn good-list comprehensions, filter, and all that are nicely done. It'd be more accurate to say that I prefer Python because of my tendency to use functions as first-class citizens, including assigning them to variables, but this is probably way beyond where we want to go).
I also would like to add a couple of words in support of python. You have access to every C library through ctypes, and there are high-level wrappers as well (like pygame). pretty much every popular gaming library has python bindings. In case of high performance requirements, one can utilize cython to write modules with python-like syntax which get compiled into C code. But as said above, if your audio game struggles with not enough performance, probably something wrong is with your program; blame an inefficient algorithm, not a particular programming language. Most of languages out here is *fast enough* for audio games.
Actually, Cython is a horrible thing for a certain type of application. If you're using it only for speed and not to bind C code you're fine. Otherwise, you *have* to use VS 2008 or VS 2010, which means that you cant' use all the latest features. CFFI also has problems with Py2exe, at least if you're concerned about authorization. Ctypes isn't hard, but it's pretty much the only option if you want it to work in all situations. Which sucks a lot. One of these days, I'll go fix CFFI so you can effectively close source; the info on the problem doesn't come from me, and it's not something I'm overly concerned about yet.
I'm also not specifically supporting Python. There are languages which are intrinsically less powerful (for the human definition, not the mathematical one). Python and C# are about equal as languages, but C# has some major accessibility issues with tools that MS really aught to fix. There are other options that are equally good, and half of this comes down to the static vs. dynamic typing war, a conflict in which both sides are basically completely right.
Actually, Cython is a horrible thing for a certain type of application. If you're using it only for speed and not to bind C code you're fine. Otherwise, you *have* to use VS 2008 or VS 2010, which means that you cant' use all the latest features.
I am using cython to bind c++ code and find it completely OK for the job. Limitation about using certain version of MS compiler comes from the fact, that you have to use the same version of compiler which was used to build windows python distribution, and, therefore, is not cython-specific. The same would apply if you used boost::python or any other library/tool to develop python extensions.
CFFI also has problems with Py2exe, at least if you're concerned about authorization.
Frankly speaking, if you are concerned about authorization - forget about python. It is practically impossible to hide your code from decompilation. Tricks with encrypting/changing bytecode were tried by big guys like dropbox, but were hacked right away by volunteers.
Ctypes isn't hard, but it's pretty much the only option if you want it to work in all situations. Which sucks a lot.
And is not an option if you want to wrap c++ code. You, of course, might write a C wrapper for c++ code and then call it from ctypes, but that's not always feasible, cause other options are available.
If you're wrapping C++ code without intermediate C layers, then you know what you're doing already and my comments are not aimed at you. You're also building a library that will be basically useless in any other language that needs a C API, but hey-your loss. perhaps you already have something in C++ that you're already having to limit yourself to VS 2008 for, but if not, don't go down that road.
But seriously, the compiler restriction is a huge deal, mostly because Microsoft has now given us all of C++11 and we can't access it if we're building Python extensions in any way. The controversies about C++11 aside, there are killer features in there that boost productivity a lot.
Someone needs to do a PEP to get the official windows builds updating with the MS compiler suite; MS seems to actually be deciding that updating C++ is now a worthwhile thing. VC++ 2014 is dropping stuff towards C++14, etc. It's kind of like saying that you have to build libraries for Python 3 in Python 2, or some similar nonsense.
As for authorization, we've had this conversation before on these forums: any authorization scheme can be cracked, need only be cracked once, and that's it. So using Python makes development months shorter and maybe gets you cracked one month earlier. But you can be smarter-there are other things besides bytecode shuffling. For example, full-on encryption of the pyc files with a modded interpreter, writing a small but crucial piece of the application in C and having that piece also be responsible for authorization, and whatever else your devious mind can come up with. Since C++ would only buy a couple months at most anyway, I don't see what the problem here is.
But really the question of authorization is this. Is there someone in the target audience who is both smart enough to crack it and who would care to crack it? I think not for Python-I could easily come up with a nonstandard method that's not worth your time. There are few programmers in this community who would have the knowledge to actually reverse bytecode shuffling for sourcecode extraction, and it maybe takes 2 days for me to move chunks of critical logic into C. Which I can do at the end of the project when it's ready for release and I've got something to actually worry about authorizing.
AudioGames.net Forum → Developers room → frameworks to develop audiogames
Generated in 0.017 seconds (48% PHP - 52% DB) with 11 queries
