Roquen
|
 |
«
Reply #30 - Posted
2012-03-19 14:59:02 » |
|
Nah, I was referring to groups of 1-5 people that say, "Hey! I'm/we're gonna make-a game!"
|
|
|
|
|
|
philfrei
|
|
«
Reply #31 - Posted
2012-03-19 19:53:53 » |
|
Re: success of "Draw Something" -- currently making $100k a day. Is this a game that couldn't be written in Java? (I guess, yes, to the extent that it is for iPad, etc., but otherwise?) Is there an existing "game engine" that could have been used to make it? The studio, which has been in operation for about four years, had previously struggled to make any traction on the App Store with previous attempts such as Cupcake Corner, a bakery simulation, and Puppy World, a Nintendogs-like game.
Their previous games: derivatives. Might have been made by existing game engines? Game engine = GLUT? |
"Greetings my friends! We are all interested in the future, for that is where you and I are going to spend the rest of our lives!" -- The Amazing Criswell
|
|
|
|
gimbal
|
|
«
Reply #32 - Posted
2012-03-20 13:03:37 » |
|
To me its actually more of a challenge to use Java, especially because so many people do not. I know (Visual) C++ and I can use it to create games that run on all Windows platforms, but a few years back I actually ported some code from C++ to Java to play around with it (we're talking 2D platformer type of stuff). And I was hooked. My results were pretty staggering (to myself). - I did the same with only half the code - what took me a month to get right using C++ (including debugging and plugging memory leaks) took me only a week to do using Java; now that I figured out how to properly use the debugger features it is development bliss. That also says something about my C++ skills of course, which were decent but in no way as developed as my grip on Java  This is quite a few years ago and I already knew that the client side of Java was too underdeveloped to make it a good platform to RUN games on. With good hope I witnessed how Sun started all kinds of projects to remedy that. JOGL, hardware acceleration in Java2D, project Darkstar, even that 3D user interface of which the name escapes me right now. Unfortunately it never became anything that actually moved the platform forward  Nowadays game development using Java is "nice", but I don't see it developing into anything more. Perhaps its time for a new book with LWJGL as the base and a nice picture of Minecraft on the cover, focused on indie game development. |
|
|
|
|
Games published by our own members! Check 'em out!
|
|
|
ra4king
|
|
«
Reply #33 - Posted
2012-03-20 13:31:07 » |
|
Perhaps its time for a new book with LWJGL as the base and a nice picture of Minecraft on the cover, focused on indie game development.
Greatest idea I've read in a while  |
|
|
|
|
gimbal
|
|
«
Reply #34 - Posted
2012-03-20 13:33:35 » |
|
Perhaps its time for a new book with LWJGL as the base and a nice picture of Minecraft on the cover, focused on indie game development.
Greatest idea I've read in a while I agree with you and myself |
|
|
|
|
|
badlogicgames
|
|
«
Reply #35 - Posted
2012-03-21 15:25:26 » |
|
While I am pretty impressed at the fact it works at all I can't help but notice just how lamentably slow it is. And there's your problem right there. And still... iOS. We need an AOT compiler, period. Excelsior might have something up their sleeves... Cas Avian can compile AOT, it runs on non-jailbroken iOS devices. I actually started using it to port libgdx to iOS. Caveat: only ARM6 support at the moment, that means no native floating point. There seems to be some work done on an ARM7 emitter. However, at the moment i think the best bet on iOS is to use IKVM and Mono(Touch). I've done some experiments a while back on the desktop and that works fine, the PlayN guys seem to go that route on iOS at the moment. Benefit: better debugging tools over Avian, which does not implement any kind of debugging protocol. |
|
|
|
|
Z-Man
|
|
«
Reply #36 - Posted
2012-03-22 03:29:29 » |
|
I don't know much about C++, mostly because I started on Java and have been reluctant to switch, but it seems that actually getting started as an indie dev is easier in Java. Simply because there is a nice built in library with lots of code already written and built in, and deploying is *kind of* easier in Java. If you want to ignore the whole "Applets suck, WebStart sucks, having to package a JVM sucks" thing, the cross platform deployment is nice  The main things that have kept me away from C++ are: The lack of a central GUI/Graphics library, memory management, cross platform is a little trickier. Also I've yet to find a C++Gaming.org  tl;dr Woo Java |
|
|
|
|
|
CaptainJester
|
|
«
Reply #37 - Posted
2012-03-22 03:39:07 » |
|
I don't know much about C++, mostly because I started on Java and have been reluctant to switch, but it seems that actually getting started as an indie dev is easier in Java. Simply because there is a nice built in library with lots of code already written and built in, and deploying is *kind of* easier in Java. If you want to ignore the whole "Applets suck, WebStart sucks, having to package a JVM sucks" thing, the cross platform deployment is nice The main things that have kept me away from C++ are: The lack of a central GUI/Graphics library, memory management, cross platform is a little trickier. Also I've yet to find a C++Gaming.org tl;dr Woo Java As much as I don't want to send people away from here, gamdev.net is the central place for C/C++. |
|
|
|
|
princec
|
|
«
Reply #38 - Posted
2012-03-22 09:35:17 » |
|
Mufasa: One day Simba, you will be king of all the Internet. Everything the light touches shall be yours. Simba: What is that dark place over there? Mufasa: That is gamedev.net. You must never go there. Cas |
|
|
|
|
gimbal
|
|
«
Reply #39 - Posted
2012-03-22 15:04:54 » |
|
Mufasa: That is gamedev.net. You must never go there. Cas Meh, it isn't/wasn't THAT bad. I've had some helpful sessions there during my CPP days. But like any other "big" forum, there is a larger portion of the type of the self-proclaimed "saints of development"; you know, the kind that do not have to provide arguments because there is no way they can be wrong. > The lack of a central GUI/Graphics library, memory management WxWidgets is quite good and cross-platform and is still maintained. Memory management is of course a good reason to flock to Java or a .NET flavor; perhaps even the best reason. With proper code design it isn't THAT hard to do, but it still a major dent in productivity to have to micromanage stuff at the code level. Some people thrive on that though, but perhaps that is sparked by the necessity to do it - I used to be like that myself when I was coding C++ and I miraculously lost it when I received the blessing that is Java. |
|
|
|
|
Games published by our own members! Check 'em out!
|
|
|
princec
|
|
«
Reply #40 - Posted
2012-03-22 15:12:06 » |
|
Oddly we're coming full circle attempting to manage our own memory in Java to get performance out of GPUs again now  Cas |
|
|
|
|
Z-Man
|
|
«
Reply #41 - Posted
2012-03-22 15:33:53 » |
|
Mufasa: One day Simba, you will be king of all the Internet. Everything the light touches shall be yours. Simba: What is that dark place over there? Mufasa: That is gamedev.net. You must never go there. Cas bahahah xD As much as I don't want to send people away from here, gamdev.net is the central place for C/C++.
I'll have to look into gamedev.net, thanks CaptianJester. As for sending people away. It's not likely I'll be defecting to C++ or GameDev.net x) WxWidgets is quite good and cross-platform and is still maintained. Memory management is of course a good reason to flock to Java or a .NET flavor; perhaps even the best reason. With proper code design it isn't THAT hard to do, but it still a major dent in productivity to have to micromanage stuff at the code level. Some people thrive on that though, but perhaps that is sparked by the necessity to do it - I used to be like that myself when I was coding C++ and I miraculously lost it when I received the blessing that is Java.
Huh, I'll look into wxWidgets. Thanks. |
|
|
|
|
|
kaffiene
|
|
«
Reply #42 - Posted
2012-03-25 12:09:49 » |
|
Regardless - the problem is that the entire toolchain, from a AAA studio's point of view, is missing. From one end - actual developers with game development skills who can do Java - through to the content pipeline integration - right to the deployment, there are simply massive hurdles at every step. Given that the actual coding development is maybe only 10% of the budget of a AAA title why the hell would they want to switch to Java to shave off 2-3 % points off that cost only to a) lose it all working around the totally novel experience of deploying Java on a console b) end up with a game that runs 1/10th the speed they need it to c) have to recode all their content pipeline stuff from scratch because none of it is compatible with a Java-centric world?
This is the core issue, IMO. I've done commercial game development in C++ and the big difference is that you can just buy thirdparty systems for everything which work with C++. Not so with Java. It would be perfectly possible to do so with Java but C++ got there first and everything is designed to work with it. Existing studios see little value in completely retooling to use an unproved (to them) language. Not having a good story targeting PS3/Xbox doesn't help either. None of this is inheirently a Java issue, it's more to do with game developer studios expectations and beliefs. |
|
|
|
|
|
kaffiene
|
|
«
Reply #43 - Posted
2012-03-25 12:16:00 » |
|
WxWidgets is quite good and cross-platform and is still maintained. Memory management is of course a good reason to flock to Java or a .NET flavor; perhaps even the best reason. With proper code design it isn't THAT hard to do, but it still a major dent in productivity to have to micromanage stuff at the code level. Some people thrive on that though, but perhaps that is sparked by the necessity to do it - I used to be like that myself when I was coding C++ and I miraculously lost it when I received the blessing that is Java.
WxWindows is the spawn of the devil. I've used a great number of GUI systems in my life and WxWindows is hands down the worst. Any system that makes heavy use of #define macros to do real programming needs a special level of hell all of it's own. |
|
|
|
|
|
Roquen
|
|
«
Reply #44 - Posted
2012-03-25 12:25:02 » |
|
None of this is inheirently a Java issue, it's more to do with game developer studios expectations and beliefs.
Although it's certainly true that C++ only programmers assume Java is worse that it actually is and conversely that Java only programmers are certain that it's better than actually is. There are very real (and huge) downsides to using Java for a large budget game projects esp. if they are attempt to be cutting edge. |
|
|
|
|
sproingie
|
|
«
Reply #45 - Posted
2012-03-25 20:18:26 » |
|
The ironic thing is that the main reason I use Java, other than its robustness (no pointer BS to deal with, no typos showing up only as segfaults), is for the vast number of third party libraries available for it. But code libraries and apps in the asset pipeline aren't exactly the same thing are they.
It's also safe to say that for games that really need to squeeze the utmost out of the platform, that the Java runtime imposes some pretty severe limitations that you can only get around by "writing C in Java". JNI is a non-starter, it has overhead of the likes of COM, so it's a price that devs are only willing to pay once (namely for DirectX). You can statically compile, but then it's back to the high marginal cost of switching your toolchain just to switch source languages.
|
|
|
|
|
|
gimbal
|
|
«
Reply #46 - Posted
2012-03-26 10:13:23 » |
|
WxWindows is the spawn of the devil. I've used a great number of GUI systems in my life and WxWindows is hands down the worst. Any system that makes heavy use of #define macros to do real programming needs a special level of hell all of it's own.
Hm agreed, but in my experience most cross-platform C++ APIs work like that in one way or another with the exception of a small number of very clean ones (often ones that are quite young - WxWidgets is already quite old). But now I'm curious: you know a better alternative for C++? |
|
|
|
|
|
princec
|
|
«
Reply #47 - Posted
2012-03-26 11:00:10 » |
|
If JNI wasn't so obscure and difficult to use properly, I should think that the C++ library integration problem would largely "go away". IMO the whole design of JNI - whilst admirably ensuring that C++ code talks to "an arbitrary implementation of a JVM" correctly - was/is utter bollocks, there being for most of Java's history only one JVM implementation that mattered, and native code being native code anyway, why did it have to be compatible with arbitrary JVMs in the first place? No, I think they should have shortcut the entire thing and just made it trivial to call into and out of native code from C++ and we'd be years ahead. Cas |
|
|
|
|
Roquen
|
|
«
Reply #48 - Posted
2012-03-26 11:51:54 » |
|
Yeah they should have gone with a simple native stack ABI and called it done. FYI eons ago I did a interpreted only JVM that was fully compliant at the VM level (minus identityHashCode and per object synchronization, both of which are stupid). Without JNI the memory footprint was around 3-5K for both intel & ARM, including a stack based ABI. With JNI it shot up to around 25K if memory serves...and JNI interface was insanely slower.
|
|
|
|
|
|
nsigma
|
|
«
Reply #49 - Posted
2012-03-26 18:31:13 » |
|
If JNI wasn't so obscure and difficult to use properly, I should think that the C++ library integration problem would largely "go away". IMO the whole design of JNI - whilst admirably ensuring that C++ code talks to "an arbitrary implementation of a JVM" correctly - was/is utter bollocks, there being for most of Java's history only one JVM implementation that mattered, and native code being native code anyway, why did it have to be compatible with arbitrary JVMs in the first place?
Your first point I agree with, though I do see the benefits of having a defined standard across all JVM, particularly heading forward. With regards to JNI, I'm definitely converted to the benefits of JNA, BridJ, etc. Far easier development and deployment, with negligible* extra overhead. I am intrigued by what "calls between Java and Native without JNI boilerplate" means for JDK 9. I'm assuming (possibly wrongly) that this means the equivalent of JNA / BridJ within the JVM. Best wishes, Neil * IMO negligible because 99% of the time if you're doing so much back and forth between Java and native code that this becomes an issue, you're not doing it right! PS. I'll be ignoring Julien's obligatory anti-JNA rant! |
|
|
|
|
sproingie
|
|
«
Reply #50 - Posted
2012-03-26 18:38:09 » |
|
JNA has even more call overhead than JNI, it's just not as baroque at the source level. I'd not heard of BridJ before, but it sure looks interesting.
|
|
|
|
|
|
nsigma
|
|
«
Reply #51 - Posted
2012-03-26 18:57:20 » |
|
JNA has even more call overhead than JNI.
Er, I know, that's what I said! However, in practice I find the call overhead swamped by other factors anyway (like actual calculations!) which is as it should be unless you're doing something unusual (or stupid ). JNA is improving too - I recently helped get a callback fix into it which sped up calls into the JVM quite substantially. One of the JAudioLibs libraries in my sig is a binding to the JACK audio library using JNA. Low-latency audio running at realtime priority, and JNA copes admirably. |
|
|
|
|
gouessej
|
|
«
Reply #52 - Posted
2012-03-26 23:26:48 » |
|
JNA has even more call overhead than JNI.
Er, I know, that's what I said! Actually, no. Usually, you only say that we are wrong. Admit that JNA is slower than JNI once for all. |
|
|
|
|
Riven
|
|
«
Reply #53 - Posted
2012-03-26 23:59:27 » |
|
JNA has even more call overhead than JNI.
Er, I know, that's what I said! Actually, no. Usually, you only say that we are wrong. Admit that JNA is slower than JNI once for all. I am intrigued by what "calls between Java and Native without JNI boilerplate" means for JDK 9. I'm assuming (possibly wrongly) that this means the equivalent of JNA / BridJ within the JVM.
I'm reasonably sure that nsigma wasn't addressing performance in his statement. I suggest we leave it at that, as nobody wants a flamewar in this otherwise informative thread.  |
|
|
|
|
badlogicgames
|
|
«
Reply #54 - Posted
2012-03-27 00:11:49 » |
|
I suggest we leave it at that, as nobody wants a flamewar in this otherwise informative thread. I beg to differ, it's on. |
|
|
|
|
sproingie
|
|
«
Reply #55 - Posted
2012-03-27 00:14:33 » |
|
Did someone say Julien's name three times in a mirror? Fess up!
|
|
|
|
|
|
kaffiene
|
|
«
Reply #56 - Posted
2012-03-27 02:56:00 » |
|
None of this is inheirently a Java issue, it's more to do with game developer studios expectations and beliefs.
Although it's certainly true that C++ only programmers assume Java is worse that it actually is and conversely that Java only programmers are certain that it's better than actually is. There are very real (and huge) downsides to using Java for a large budget game projects esp. if they are attempt to be cutting edge. Memory usage is definitely worse than C/C++. Execution speed is a little slower (although, for AAA much of the heavy lifting is done by the Gfx Card - language doesn't matter there). If you have to be able to use CPU specific features that forces JNI which isn't the fastest thing around. For most games I think only memory footprint is likely to be a deal-breaker. |
|
|
|
|
|
kaffiene
|
|
«
Reply #57 - Posted
2012-03-27 02:58:35 » |
|
WxWindows is the spawn of the devil. I've used a great number of GUI systems in my life and WxWindows is hands down the worst. Any system that makes heavy use of #define macros to do real programming needs a special level of hell all of it's own.
Hm agreed, but in my experience most cross-platform C++ APIs work like that in one way or another with the exception of a small number of very clean ones (often ones that are quite young - WxWidgets is already quite old). But now I'm curious: you know a better alternative for C++? The last time I had to do a GUI in C++, I wrote an OpenGL library that basically mimicked Swing :o) |
|
|
|
|
|
kaffiene
|
|
«
Reply #58 - Posted
2012-03-27 03:01:49 » |
|
If JNI wasn't so obscure and difficult to use properly, I should think that the C++ library integration problem would largely "go away". IMO the whole design of JNI - whilst admirably ensuring that C++ code talks to "an arbitrary implementation of a JVM" correctly - was/is utter bollocks, there being for most of Java's history only one JVM implementation that mattered, and native code being native code anyway, why did it have to be compatible with arbitrary JVMs in the first place? No, I think they should have shortcut the entire thing and just made it trivial to call into and out of native code from C++ and we'd be years ahead. Cas I was under the impression that the GCC Java compiler had some way of interfacing directly with C/C++ code. I believe that the compiled Java binary object was pretty much the the same as the output for C or C++. Did GCJ ever amount to anything? |
|
|
|
|
|
sproingie
|
|
«
Reply #59 - Posted
2012-03-27 04:15:51 » |
|
GCJ is a static compiler for Java, so its interface is like any other native code. And it's safe to say that no, it never amounted to anything. The code it generates is slow, and the memory footprint is large, and the gc is basically broken. It has faster startup, that's about it.
|
|
|
|
|
|
