As far as Eve goes the only thing they use C++ for is the rendering engine with a python wrapper around it. Similar to what Panda3D did. Everything else is pritty much Python. At least that is what I gathered from the CEO's speech.
As of late Mono has come a very long way. It is very solid to work in IMHO. But I am not positive about the the Game Development Library support out there. To my knowledge a lot of C# game dev libs should just work with it.
But you might want to take a look into PyPy. Python is such a fantastic language it should not leave your development without a fight.
Next language for game development?
I know this is pretty obvious, but why not just use C++0x? Sure it's not finished, but it should be good enough for any small projects. It's a much needed C++ face-lift.
Quote:Original post by swiftcoderQuote:Original post by OrangyTangGood question, and I had pretty much tossed out LWJGL after the last time I looked at gamedev in Java. At the time it felt like a dead-end option compared to 'official' opengl support, and with the recent JoGL/Java2D/SWT/JavaFX integration, that opinion is only reinforced.
Can't Scala seamlessly call regular Java classes? In which case what's wrong with LWJGL?
I think you're a little behind - Sun dropped Jogl recently and all of the developers have either been laid off or quit, so it's now no longer any more official than LWJGL. And of the two LWJGL is the one with the most released commercial games using it.
Add to that that JavaFX is using it's own private fork of Jogl, and that Jogl is in an awkward position in terms of support (Jogl 1 is unsupported with many long-standing bugs, whereas Jogl 2 is not backwards compatible, unfinished and alpha-quality at the moment). With AWT and Applet support LWJGL has the same amount of integration into existing apis as Jogl as well.
I think you should probably give LWJGL another try (and I should probably get around to trying Scala at some point. [grin] ).
Quote:Original post by blewisjrPyPy and Unladen Swallow are both very interesting, and both close to prime time, but I am not sure they are quite there. Each has fantastic performance in some key areas (math and string operations come to mind), and less than stellar performance in most others.
But you might want to take a look into PyPy. Python is such a fantastic language it should not leave your development without a fight.
Quote:Original post by DaeMuch needed, but i am not sure they take it nearly far enough. C++0x feels like a badly fitting set of bandages to cover C++'s deficiencies, and the necessity to keep backwards compatibility pretty much makes sure it will stay that way - C++0x doesn't really bring anything to the table that hasn't been available in D for some years...
I know this is pretty obvious, but why not just use C++0x? Sure it's not finished, but it should be good enough for any small projects. It's a much needed C++ face-lift.
Quote:Original post by OrangyTangWell, shucks. I wasn't aware that the status of Java openGl had changed yet again - what in hell is Java2D running on then?
I think you're a little behind - Sun dropped Jogl recently and all of the developers have either been laid off or quit, so it's now no longer any more official than LWJGL. And of the two LWJGL is the one with the most released commercial games using it.
Quote:With AWT and Applet support LWJGL has the same amount of integration into existing apis as Jogl as well.The primary advantage of JoGL to my mind, was the ability to embed Swing *within* OpenGL (i.e. render a full Swing GUI to an FBO), as well as the reverse. As I understand it, LWJGL supports the latter but not the former, although I would be happy to be corrected...
Edit: There are however workarounds, which might make it workable for me - Although it looks like Swing has to be un-accelerated in this case, so the performance penalty is likely to be pretty high.
[Edited by - swiftcoder on December 5, 2009 10:08:38 AM]
Have you considered OOC? http://ooc-lang.org
I don't know much of it, but it seems to be a nice mixture between low-level and high-level languages.
I don't know much of it, but it seems to be a nice mixture between low-level and high-level languages.
Quote:Original post by swiftcoder
I appreciate this sentiment, but I have my doubts. Pure-functional languages have been the 'next big thing' since god knows when, and they just keep missing the mark by a little. They are great for writing parsers/compilers, transactional servers, etc. but game development I am not sure on.
Oh don't get me wrong, I have my doubts too. It's one of those things that looks great on paper, and it *could* materialize if all the stars line up right, and for that matter it should materialize. But just like Duke Nukem Forever, who really knows?
Tim Sweeney has recently started pushing functional programming languages pretty hard. The main thing holding it back is that there's nobody willing to take the leap and just jump in heads first and try to do anything serious on a game with it. Hopefully Tim changes that, as he certainly has the backing to make it happen, even if it doesn't work out.
http://www.google.com/url?sa=t&source=web&ct=res&cd=4&ved=0CBEQFjAD&url=http%3A%2F%2Fwww.cs.princeton.edu%2F~dpw%2Fpopl%2F06%2FTim-POPL.ppt&rct=j&q=tim+sweeney+functional&ei=b6QaS9efJovgMYy38OoC&usg=AFQjCNH1lYwuSG7QJy3ShTC6uRB2biG-ag
There has to be collaboration from the industry if it's going to evolve into a language useful for game development. It looks like he's the right person to make that happen, although if it ultimately doesn't end up materializing, I wouldn't be that surprised.
But you know, Moore's Law is only going to take us so far. Eventually all this additional levels of abstraction (see, for example, LINQ) are going to catch up to us and developers will have to look at alternate ways of writing fast code. Parallelization is the future, even if it means an entirely different computer architecture that allows developers to more easily write parallel code. In that respect, imperative languages are practically at a dead-end with nowhere to go. You will never, ever be able to take full advantage of a highly parallel machine using an imperative language. And once Moore's Law catches up to us, parallel is going to be the only place to turn to for more performance.
So basically what I'm saying is, eventually game developers will be using a language that can be automatically parallelized. Currently the most likely candidate for that is a purely functional language, and among purely functional languages, Haskell is the most likely candidate. But we could be talking about 20 years from now, which is plenty of time for a brand new language to come along.
Quote:Original post by swiftcoder
Well, shucks. I wasn't aware that the status of Java openGl had changed yet again - what in hell is Java2D running on then?
J2D has always had it's own backends, unrelated to Jogl. IIRC these days they've got both a D3D and OpenGL backend, although which one will be used depends on your OS and hardware config.
Quote:The primary advantage of JoGL to my mind, was the ability to embed Swing *within* OpenGL (i.e. render a full Swing GUI to an FBO), as well as the reverse. As I understand it, LWJGL supports the latter but not the former, although I would be happy to be corrected...
Edit: There are however workarounds, which might make it workable for me - Although it looks like Swing has to be un-accelerated in this case, so the performance penalty is likely to be pretty high.
I believe performance is actually not bad, but personally I'd use a proper OpenGL gui toolkit rather than trying to crowbar Swing into somewhere it's not designed. Off the top of my head there's TWL and Nifty GUI, both under active development.
Quote:Original post by bronxbomber92That one looks to fall in roughly the same category as Google Go: systems programming with high-level features, and similarly new and as-yet not adopted widely. Still worth keeping an eye on though, so thanks for the link!
Have you considered OOC? http://ooc-lang.org I don't know much of it, but it seems to be a nice mixture between low-level and high-level languages.
Quote:Original post by cache_hitI basically agree, but I am not so sure that pure functional languages are the most likely route. Definitely the future needs different languages, but I have a gut feeling that we are going to end up with some ungodly hybrid of Google Go attached to OpenCL/CUDA [smile]
So basically what I'm saying is, eventually game developers will be using a language that can be automatically parallelized.
Quote:Original post by OrangyTangFor the (generally light) in-game GUI needs I agree with you. However, for tool development I am fond of the concept of heavy-weight GUI toolkits pulled into the 3D world (as with Qt or Awesomium in C++). Among other things, access to the standard GUI design tools and plugin systems makes larger tasks vastly easier.
I believe performance is actually not bad, but personally I'd use a proper OpenGL gui toolkit rather than trying to crowbar Swing into somewhere it's not designed.
My perfect setup:
Client: Python/Python Stackless with Ogre3d bindings for the client. Then all graphics execute in C++ speed and the client logic in short and easy understandable Python code.
Servers: Erlang, brings concurrency, fault-tolerance and distribution.
Client: Python/Python Stackless with Ogre3d bindings for the client. Then all graphics execute in C++ speed and the client logic in short and easy understandable Python code.
Servers: Erlang, brings concurrency, fault-tolerance and distribution.
Quote:Original post by flodihnUnfortunately, if I bring a C++ rendering engine in, then a lot of my code has to be C++ as well, as I am implementing a lot of (essential) graphics features. This is roughly the setup I am using now, and I would like to move away from the C++.
Client: Python/Python Stackless with Ogre3d bindings for the client. Then all graphics execute in C++ speed and the client logic in short and easy understandable Python code.
Quote:Servers: Erlang, brings concurrency, fault-tolerance and distribution.I don't want different languages on the client and server. I know it is a common route to take (probably inspired by web architectures), but with languages like Scala and C#, there really isn't a need to do this, and my opinion is that using one language throughout reduces maintenance by a good deal.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
