Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (498)
Games in Android Showcase (116)
games submitted by our members
Games in WIP (563)
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]
  ignore  |  Print  
  Why don't many of you use JMonkey Engine?  (Read 21760 times)
0 Members and 1 Guest are viewing this topic.
Offline gouessej
« Reply #30 - Posted 2013-05-05 21:11:45 »

What about planned obsolescence? Why should I buy a brand new PC to play with a "Space Invaders" 3D clone? Why should I do the same to play with a simple Quake-like without fancy effects? There is the same problem in other domains, what do people put into the word "modern"? The industry wants to force people not renew their hardware more often than needed which is not ecological, that's why I need to do something else than just using shaders everywhere without having a fallback. Even JMonkeyEngine 3 has a renderer supporting the fixed pipeline even though it is less used than the shader based one.

Good point - but JME does run on my old laptop (circa 2008 Mobility Radeon 3450), so it does have some backwards compatibility. and all the materials in JME have implementations for GLSL100 and GLSL150 (and nothing more recent) so it is hardly forcing you to use the latest hardware. It is easy however to add eye candy in JME that will quickly overload older machines.
JMonkeyEngine 3 (only its shader based renderers) doesn't run on my main computer bought in 2005 and the creator of a first person shooter using this engine complained about having to rewriting tons of build-in shaders. I understand that backward compatibility requires some efforts, I understand that some developers are not interested in supporting very low end hardware but in my case, my game is a lot less good than Quake 2 and I don't see why it should not work on an old Pentium 2 MMX with a crappy Matrox Millenium G200. I have nothing against shaders, I just think that we have to use them carefully and some famous game developers are a bit harsh with some mechanisms not requiring shaders because they are paid to encourage the abuse of shaders. JMonkeyEngine 3 has a pragmatic solution, 2 renderers in its JOGL 2.0 backend. Therefore, everyone is happy  Grin

Offline jmaasing

Junior Newbie





« Reply #31 - Posted 2013-05-05 21:50:30 »

Hi
- almost no JMonkeyEngine users are interested in my JogAmp backends and its core developers mainly see them as useless craps or a fallback (except one of them who is trying to port NEWT to iOS)

I had to register here at JGO just to say that maybe most users but not all, I've been looking forward to it and very much so since Java 7 came to Mac :-)
I haven't used Ardor3D since I couldn't find any good documentation but I've been using jME3 for a year and I think you summarized it very well.
Offline gouessej
« Reply #32 - Posted 2013-05-05 22:31:29 »

Hi
- almost no JMonkeyEngine users are interested in my JogAmp backends and its core developers mainly see them as useless craps or a fallback (except one of them who is trying to port NEWT to iOS)

I had to register here at JGO just to say that maybe most users but not all, I've been looking forward to it and very much so since Java 7 came to Mac :-)
Supporting Mac requires a huge effort and Sven makes a great job for this OS so that JOGL users can use it without too much troubles. I'm a bit sad to see that my backends are mostly seen as a fallback for Mac OS X whereas I have spent a lot of time in creating and/or maintaining them. JogAmp still suffers from the consequences of FUD campaigns launched when Oracle left the boat. We don't have Minecraft but tons of scientific applications use JogAmp.

I haven't used Ardor3D since I couldn't find any good documentation but I've been using jME3 for a year and I think you summarized it very well.
Ardor3D has lacked of documentation since its very beginning. There are still no Java documentation online. The tutorials are very basic but they are very well written, with lots of details and there are more than 40 examples in the repository. Ardor3D is really IDE agnostic. As soon as your IDE supports Maven, it works.

I have forgotten to mention that Ardor3D is less high level than JMonkeyEngine 3 and has no support of sound. For example, there is no equivalent of the class StandardGame (JMonkeyEngine 2) or Application (JMonkeyEngine 3), there is no build-in state machine (you can use Fettle instead) but you can easily start by using a very simple example (that's what I did).

As far as I know, JMonkeyEngine 3 and Ardor3D do not provide some complete examples of rudimentary games whereas LibGDX does. It's even worse when you look for some more elaborated examples, open source projects. Wolkenstein (or something closer) uses JMonkeyEngine 1. Only a very few developers using them release their source code. TUER has been the very first "game" using Ardor3D with Java Web Start whose source code is available.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline JESTERRRRRR

Senior Member


Medals: 7
Exp: 1 year



« Reply #33 - Posted 2013-05-06 00:26:02 »

I looked at it and the features just scared me off. Its so professional looking as though designed for a 'AAA' game, not something I want to make. (AAA as in high quality GFX)
Offline HeroesGraveDev

JGO Kernel


Medals: 254
Projects: 11
Exp: 2 years


┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻


« Reply #34 - Posted 2013-05-06 00:44:03 »

The thing that would have scared me off (if I even considered using it) would be how my game would end up looking the same as all the other jME games.

I hate engines that result in games that all look the same.

Offline davedes
« Reply #35 - Posted 2013-05-06 00:56:56 »

The look of the game is dictated through art direction, 3D modeling, shader effects, etc. The reason most of the JMonkeyEngine games look the same is because they use standard shading models (like Phong instead of something more original) and sub-par placeholder artwork.

Offline sproingie

JGO Kernel


Medals: 202



« Reply #36 - Posted 2013-05-06 01:26:54 »

and I don't see why it should not work on an old Pentium 2 MMX with a crappy Matrox Millenium G200.

Should it also support a PC XT with a Hercules adaptor?  Look, I like graceful degradation as much as the next guy, and I'd prefer an engine didn't demand I write shaders where a high-level API would suffice, but you still have to draw the line somewhere. 

You can always run an ancient engine for your ancient hardware.  And if it doesn't exist, maybe there's a reason why.

Online Riven
« League of Dukes »

JGO Overlord


Medals: 800
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #37 - Posted 2013-05-06 10:30:00 »

Who put this thread in the chitchat board? Clueless

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline gouessej
« Reply #38 - Posted 2013-05-06 11:53:23 »

and I don't see why it should not work on an old Pentium 2 MMX with a crappy Matrox Millenium G200.

Should it also support a PC XT with a Hercules adaptor?  Look, I like graceful degradation as much as the next guy, and I'd prefer an engine didn't demand I write shaders where a high-level API would suffice, but you still have to draw the line somewhere.  

You can always run an ancient engine for your ancient hardware.  And if it doesn't exist, maybe there's a reason why.
I meant that there is a problem if you write a game that looks like Quake 2 but you absolutely need shaders (whereas Quake 2 didn't). Some people will say "why do I need an high end graphics card to play with this game?". I think supporting OpenGL 1.2 for this kind of game is still possible and I like engines that don't prevent me from doing that. I don't say that we should forget shaders. JMonkeyEngine 3 is a good compromise as its whole design is not constrained by the fact that one of its renderers still supports the fixed pipeline and its shader based architecture is very good. You get the best of the both world, don't you? If you make a game with "modern" fancy effects, it will be easier to justify an higher minimal hardware requirements than if your graphics are as poor and ugly as mine. If it's not justified, some people will say that's because of Java Sad

The thing that would have scared me off (if I even considered using it) would be how my game would end up looking the same as all the other jME games.

I hate engines that result in games that all look the same.
What do you mean exactly? I think that tons of games created with FPSCreator look the same because lots of people use the artworks provided with this editor but it is not the case with JMonkeyEngine 3 because it's just an engine, you can hardly make a game with the few models provided with the examples and you're free to write your own shaders. See an engine as a kind of toolkit, you still have tons of code to write.

Offline ReBirth
« Reply #39 - Posted 2013-05-06 11:54:50 »

Who put this thread in the chitchat board? Clueless
Isn't it only you who have that strongest privilege?

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline nehon

Junior Newbie


Medals: 2



« Reply #40 - Posted 2013-05-08 12:24:54 »

Hi, I'm nehon from the jMonkeyEngine dev core team.
It's hard for me to answer the topic, because I admit I'm totally biased toward JME, but I thought I could give some answers to some questions/comments.

About the Shader oriented renderer. That's the idea jme 3 was build upon. We do have a fixed pipeline fallback, but that's just that, a fallback. Nowadays even mobile devices support shaders, and I guess you can't build an engine with outdated technologies in mind. I'm not sure a lot of people are looking for an engine so that their game runs on hardware from year 2000, at least I hope it's not their main interest.

About the "I don't want my game to look the same as another JME game". I can't see how it could happen. Our test assets are just here to test really and most people use them as placeholders until they have real assets. You can make your game look what ever you want to, you have complete control on that with JME.

About the "It's frightening because it's done for AAA games". Well...first...thank you...we usually have this the other way around :p. but JME won't make your game looks good, you will (or not :p). You can make very basic games with JME.

About the "I want absolute control so I'd rather do my own engine". I understand that, and in a way that's what we do :p. But we try to make it accessible for less experienced developers, and also let more savvy developer have their fun and go deep into the engine. There are some very low level things you can't do with JME. Low level things you guys like to have your hands on.
But the beauty of it is that you have complete access to the code, and the right to fork the engine at your will. I doubt one could do such things with Unity.
There are some examples of companies that used JME for commercial games, with a forked version and that contributed back some of their changes.

About the "basic phong lighting shading". that's true. But users that might want to do their own lighting shader can do it very easily (providing they have the knowledge to do so). Also we recently introduced a more modular shader system. We are also planning to make a full deferred rendering system in later versions of the engine.

@gouessej, we don't consider your JOGL renderer as crap or even as a fallback. We dropped JOGL support some time ago because we didn't want to have to maintain one more renderer with no benefit to it.
Now, we recently had some issues with lwjgl+osx+java 7 and we considered JOGL again to have an alternative when these kind of issues arise. We're glad and grateful of all the work you're putting into it.

Now for the OP's question, "why not more JGO members use JME". Well I guess there are some that do. I hope so. But I also hope some use Ardor 3D, libgdx, JOGL, LWJGL or have their own JNI bridge to opengl or whatever. I think that's the very point of this community. We need some unbiased point of views, we need some competition, and we need people that know how things work under the hood.

IMO, this thread just proves there are plenty alternatives when you want to make a game with java...and that's a very good thing.
Offline gouessej
« Reply #41 - Posted 2013-05-08 13:32:23 »

About the Shader oriented renderer. That's the idea jme 3 was build upon. We do have a fixed pipeline fallback, but that's just that, a fallback.
That's what I meant. It's just a fallback, it isn't intended to provide all features of the shader based pipeline.

Nowadays even mobile devices support shaders, and I guess you can't build an engine with outdated technologies in mind. I'm not sure a lot of people are looking for an engine so that their game runs on hardware from year 2000, at least I hope it's not their main interest.
I'm not sure a lot of end users would understand that they need a recent Nvidia graphics card with a very reliable and up-to-date proprietary driver to play with a simple 2D shoot'em up... which is a bit the case with WebGL. The problem is similar with 3D engines in Java: if you don't use any fancy effects, the end users who own only laptops with crappy Intel chipsets won't understand why it doesn't work fast enough on their machines and will complain about that. The problems you can face with old hardware from year 2000 is similar to the problems you can face nowadays with an HTC Tattoo with very poor OpenGL performance. I don't expect from JMonkeyEngine 3 the same "lessons" than from the industry. A clone of Quake 2 shouldn't require OpenGL 2.1 whereas Quake 2 supports OpenGL 1.2.

About the "I don't want my game to look the same as another JME game". I can't see how it could happen. Our test assets are just here to test really and most people use them as placeholders until they have real assets. You can make your game look what ever you want to, you have complete control on that with JME.
That's why I meant. Some test assets are very beautiful but I wouldn't imagine someone creating a whole game with them.

About the "It's frightening because it's done for AAA games". Well...first...thank you...we usually have this the other way around :p. but JME won't make your game looks good, you will (or not :p). You can make very basic games with JME.
I agree with that too even though JMonkeyEngine can help a bit.

About the "I want absolute control so I'd rather do my own engine". I understand that, and in a way that's what we do :p. But we try to make it accessible for less experienced developers, and also let more savvy developer have their fun and go deep into the engine. There are some very low level things you can't do with JME. Low level things you guys like to have your hands on.
But JMonkeyEngine doesn't prevent you from doing these low level things anyway.

But the beauty of it is that you have complete access to the code, and the right to fork the engine at your will. I doubt one could do such things with Unity.
There are some examples of companies that used JME for commercial games, with a forked version and that contributed back some of their changes.
I remember a company that said it would contribute back its implementation of portal culling for JMonkeyEngine and it has never done it. Something similar happened several years ago in Ardor3D, for the renderer based on JOGL 2.0. I had to write it myself.

About the "basic phong lighting shading". that's true. But users that might want to do their own lighting shader can do it very easily (providing they have the knowledge to do so). Also we recently introduced a more modular shader system. We are also planning to make a full deferred rendering system in later versions of the engine.
This modular shader system seems cool but I think that something higher level could be done (that's in my todo list for JOGL).

@gouessej, we don't consider your JOGL renderer as crap or even as a fallback. We dropped JOGL support some time ago because we didn't want to have to maintain one more renderer with no benefit to it.
Now, we recently had some issues with lwjgl+osx+java 7 and we considered JOGL again to have an alternative when these kind of issues arise. We're glad and grateful of all the work you're putting into it.
JogAmp APIs are not only an alternative when its main competitor (LWJGL) doesn't make the job correctly and you still don't see the benefit of using it. You just confirm what I wrote, "my" renderer is seen as a second class citizen but now that Pixelapp uses it, it isn't useless. Thank you for your help. I still think that the main reason the JMonkeyEngine core team dropped JOGL support was the FUD campaign against our APIs. It's really difficult to defend our APIs from defamatory comments and any JOGL renderer becomes a first class citizen only when a customer says "use it or I won't pay for any support contract". That's the same capitalist way of thinking that leads you to surreptitiously encourage planned obsolescence by considering not a lot of people are interested in supporting earlier versions of OpenGL than 2.1. My computer has been bought in 2005, my ecological footprint is lower than the one of a geek who buys a new computer every 6 months.

Now for the OP's question, "why not more JGO members use JME". Well I guess there are some that do. I hope so. But I also hope some use Ardor 3D, libgdx, JOGL, LWJGL or have their own JNI bridge to opengl or whatever.
The last known custom bridges to OpenGL are in the previous major version of Java3D and in JavaFX 3D (same guys, same contestable choices, same design flaws).

I think that's the very point of this community. We need some unbiased point of views, we need some competition, and we need people that know how things work under the hood.
I'm not sure we need competition. The diversity can become a problem. Some engines have a very few active contributors. The possibility of forking is interesting when it leads you to explore new ways and to contribute back to the community but when it leads to create very similar technologies with a very few new features or none, it has a name, it's called effort duplication. HTML5 attracts more and more developers. If we want to survive, we'll have to do exactly the opposite of forking... that's what happened for JOGL who was born from the informal "merge" of several existing bindings (Jungle, GL4Java, Magician GL?, ...). Why do I have to port features and bug fixes from JMonkeyEngine to Ardor3D and vice versa? Why do I have do to the same sometimes for Xith3D and Java3D? Why do I have to fix a bug in an example of picking provided with JOGL 2.0 and to post something in this forum as the same mistake has been done in an example using the main competitor (LWJGL) of JOGL? Why do the contributors of these bindings have to implement similar features in their native windowing systems whereas we could work together? Yes we need people who know how things work under the hood but we don't need more engines than people to use them. My engine was almost useless as is, I was aware of that.

IMO, this thread just proves there are plenty alternatives when you want to make a game with java...and that's a very good thing.
Maybe this thread shows you a diversity that you wouldn't have imagined.

Offline nehon

Junior Newbie


Medals: 2



« Reply #42 - Posted 2013-05-08 15:41:59 »

JogAmp APIs are not only an alternative when its main competitor (LWJGL) doesn't make the job correctly and you still don't see the benefit of using it. You just confirm what I wrote, "my" renderer is seen as a second class citizen but now that Pixelapp uses it, it isn't useless. Thank you for your help. I still think that the main reason the JMonkeyEngine core team dropped JOGL support was the FUD campaign against our APIs. It's really difficult to defend our APIs from defamatory comments and any JOGL renderer becomes a first class citizen only when a customer says "use it or I won't pay for any support contract". That's the same capitalist way of thinking that leads you to surreptitiously encourage planned obsolescence by considering not a lot of people are interested in supporting earlier versions of OpenGL than 2.1. My computer has been bought in 2005, my ecological footprint is lower than the one of a geek who buys a new computer every 6 months.
Well...I don't know what to answer...as usual there's a bit of overreaction and aggression in your post.
JME is a free open source software, it feels strange and a bit far fetched to be "blamed" to be capitalist because we don't support opengl < 2.0.
Now I may take the guess that the ecological footprint is not the main criteria for people around here to pick or not an engine for their game.

Look, I don't want to start a flame war about "use this or that". I just wanted to state why things are how they are in JME. We totally take responsibility for our choices.

EDIT : uh? is gouessej's post has been removed?
Offline joakim199

Innocent Bystander





« Reply #43 - Posted 2013-08-13 09:25:29 »

Many of you say that its good to use Unity. But I have Ubuntu and Unity does not work on Ubuntu. But if its some program like Unity that works on Ubuntu I would like to hear.
Offline sproingie

JGO Kernel


Medals: 202



« Reply #44 - Posted 2013-08-13 16:09:17 »

Maybe Unity doesn't run under Unity, har har.  I'm told at least the runtime component works under Chrome Native Client, but again not Ubuntu specifically.  So maybe there is something to their weird futzing around with the 3d desktop in Ubuntu Unity that's screwing up Unity3d.

As for alternatives, maybe Torque?
Offline princec

JGO Kernel


Medals: 380
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #45 - Posted 2013-08-13 19:55:39 »

Unity does work on Ubuntu, but it will rather depend on your graphics drivers.

Cas Smiley

Offline Cero
« Reply #46 - Posted 2013-08-14 00:45:47 »

Many of you say that its good to use Unity.

I dunno... if anyone does I would like to hear it.
When I talked about Unity there wasn't really anyone coming forth like "WTF its great": http://www.java-gaming.org/topics/the-ignorance-of-the-android-industry-about-good-porting-solutions-like-libgdx/30144/msg/278006/view.html#msg278006

Offline davedes
« Reply #47 - Posted 2013-08-14 01:06:31 »

There are many reasons to use Unity. Most importantly, it's a lot cheaper to buy a license than it is to spend 1-2 years paying developers to build a 3D engine. Unity also includes a lot of features that make it appealing to bigger game developers, like:

- A complex 3D scene graph with occlusion culling, LOD support, and lots more
- Advertising & social integration
- Integration with new technology, like Oculus Rift, Hydra, and so forth
- Console distribution
- Lighting, shadows, water, terrain rendering, etc
- 3D physics
- Tight integration with art tools
- Incredible animation system

But it's somewhat out of the range of most hobbyist devs. It's also a little clunky to get used to if you are used to a purely-programming environment.

Pages: 1 [2]
  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.

radar3301 (12 views)
2014-09-21 23:33:17

BurntPizza (30 views)
2014-09-21 02:42:18

BurntPizza (20 views)
2014-09-21 01:30:30

moogie (20 views)
2014-09-21 00:26:15

UprightPath (28 views)
2014-09-20 20:14:06

BurntPizza (32 views)
2014-09-19 03:14:18

Dwinin (48 views)
2014-09-12 09:08:26

Norakomi (74 views)
2014-09-10 13:57:51

TehJavaDev (102 views)
2014-09-10 06:39:09

Tekkerue (50 views)
2014-09-09 02:24:56
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!