Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (482)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (547)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2] 3 4 ... 9
  ignore  |  Print  
  Does really game development on Java suck? Why are we still here?  (Read 49517 times)
0 Members and 1 Guest are viewing this topic.
Offline Roquen
« Reply #30 - Posted 2012-03-19 13:59:02 »

Nah, I was referring to groups of 1-5 people that say, "Hey! I'm/we're gonna make-a game!"
Offline philfrei
« Reply #31 - Posted 2012-03-19 18: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?

Quote
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
Offline gimbal

JGO Knight


Medals: 25



« Reply #32 - Posted 2012-03-20 12: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 Smiley

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 Sad

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!
Legends of Yore - The Casual Retro Roguelike
Offline ra4king

JGO Kernel


Medals: 345
Projects: 2
Exp: 5 years


I'm the King!


« Reply #33 - Posted 2012-03-20 12: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 Grin

Offline gimbal

JGO Knight


Medals: 25



« Reply #34 - Posted 2012-03-20 12: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 Grin

I agree with you and myself  Grin
Offline badlogicgames
« Reply #35 - Posted 2012-03-21 14: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 Smiley

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.

http://www.badlogicgames.com - musings on Android and Java game development
Offline Z-Man
« Reply #36 - Posted 2012-03-22 02: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 Tongue 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 Wink

tl;dr Woo Java
Offline CaptainJester

JGO Knight


Medals: 12
Projects: 2
Exp: 14 years


Make it work; make it better.


« Reply #37 - Posted 2012-03-22 02: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 Tongue 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 Wink

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++.

Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #38 - Posted 2012-03-22 08: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 Smiley

Offline gimbal

JGO Knight


Medals: 25



« Reply #39 - Posted 2012-03-22 14:04:54 »

Mufasa: That is gamedev.net. You must never go there.

Cas Smiley

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!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #40 - Posted 2012-03-22 14:12:06 »

Oddly we're coming full circle attempting to manage our own memory in Java to get performance out of GPUs again now  Roll Eyes

Cas Smiley

Offline Z-Man
« Reply #41 - Posted 2012-03-22 14: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 Smiley
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.
Offline kaffiene
« Reply #42 - Posted 2012-03-25 10: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.
Offline kaffiene
« Reply #43 - Posted 2012-03-25 10: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.
Offline Roquen
« Reply #44 - Posted 2012-03-25 10:25:02 »

Quote
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.
Offline sproingie

JGO Kernel


Medals: 202



« Reply #45 - Posted 2012-03-25 18: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.
Offline gimbal

JGO Knight


Medals: 25



« Reply #46 - Posted 2012-03-26 08: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++?
Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #47 - Posted 2012-03-26 09: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 Smiley

Offline Roquen
« Reply #48 - Posted 2012-03-26 09: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.
Offline nsigma
« Reply #49 - Posted 2012-03-26 16: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!  Wink

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline sproingie

JGO Kernel


Medals: 202



« Reply #50 - Posted 2012-03-26 16: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.
Offline nsigma
« Reply #51 - Posted 2012-03-26 16: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  Smiley ).  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.

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline gouessej
« Reply #52 - Posted 2012-03-26 21:26:48 »

Actually, no. Usually, you only say that we are wrong. Admit that JNA is slower than JNI once for all.

Online Riven
« League of Dukes »

JGO Overlord


Medals: 781
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #53 - Posted 2012-03-26 21:59:27 »

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. Pointing

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline badlogicgames
« Reply #54 - Posted 2012-03-26 22:11:49 »

I suggest we leave it at that, as nobody wants a flamewar in this otherwise informative thread. Pointing

I beg to differ, it's on.

http://www.badlogicgames.com - musings on Android and Java game development
Offline sproingie

JGO Kernel


Medals: 202



« Reply #55 - Posted 2012-03-26 22:14:33 »

Did someone say Julien's name three times in a mirror?  Fess up!

Offline kaffiene
« Reply #56 - Posted 2012-03-27 00:56:00 »

Quote
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.
Offline kaffiene
« Reply #57 - Posted 2012-03-27 00: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)
Offline kaffiene
« Reply #58 - Posted 2012-03-27 01: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 Smiley

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?
Offline sproingie

JGO Kernel


Medals: 202



« Reply #59 - Posted 2012-03-27 02: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.

Pages: 1 [2] 3 4 ... 9
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

atombrot (26 views)
2014-08-20 03:29:53

Tekkerue (24 views)
2014-08-17 00:45:27

Tekkerue (23 views)
2014-08-17 00:22:17

Tekkerue (13 views)
2014-08-17 00:20:21

Tekkerue (20 views)
2014-08-17 00:12:11

Rayexar (59 views)
2014-08-11 20:49:23

BurntPizza (38 views)
2014-08-10 15:09:32

BurntPizza (30 views)
2014-08-08 20:01:56

Norakomi (37 views)
2014-08-07 13:49:38

BurntPizza (67 views)
2014-08-03 20:57:17
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!