Java-Gaming.org    
Featured games (78)
games approved by the League of Dukes
Games in Showcase (530)
games submitted by our members
Games in WIP (512)
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 15295 times)
0 Members and 2 Guests are viewing this topic.
Offline pixelapp

Junior Member




Pixelapp


« Posted 2013-05-04 09:04:50 »

Jmonkey engine http://jmonkeyengine.com/ is an astonishing piece of software. That would save you guys/gals lots of trouble and debugging.

In my opinion it is the flagship Java game engine.

Also, I recently switched from my own proprietary engine to JMonkeyEngine. I'll try to patch over the code from my own proprietary engine to JMonkeyEngine though.

So, why don't many or all of you use it?

Do you happen to not know about JMonkeyEngine?

Do you not know it was this good? http://jmonkeyengine.com/engine/

Leave your comments below.

Cloud games and fun.
Offline HeroesGraveDev

JGO Kernel


Medals: 214
Projects: 11
Exp: 2 years


If it wasn't Awesome, it wasn't me.


« Reply #1 - Posted 2013-05-04 09:13:25 »

If you use jMonkeyEngine you may as well just use Unity.

Offline Vermeer

JGO Coder


Medals: 16



« Reply #2 - Posted 2013-05-04 10:07:40 »

Before making my current project in LWJGL I did use JMonkey. With JMonkey it was easier and faster to code, also my game looked better. But....

I just did't feel I quite had control or understood how it was working. I wanted to explore graphics from the ground up and solve the problems and understand how my own code worked.

Maybe I should have got a grounding first before Jmonkey, but now I have a little Idea about what I'm doing I wouldn't want to go back to it!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 284
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #3 - Posted 2013-05-04 10:08:10 »

Devil's advocate: If you use Unity you may as well just use C++.

Cas Smiley

Offline HeroesGraveDev

JGO Kernel


Medals: 214
Projects: 11
Exp: 2 years


If it wasn't Awesome, it wasn't me.


« Reply #4 - Posted 2013-05-04 10:30:13 »

Devil's advocate: If you use Unity you may as well just use C++.

I don't get it. Huh
Isn't C++ a (huge) step in the opposite direction?

Offline kpars

JGO Ninja


Medals: 57
Projects: 4
Exp: 2 years


\o/ I develop things! \o/


« Reply #5 - Posted 2013-05-04 10:52:44 »

Devil's advocate: If you use Unity you may as well just use C++.

Cas Smiley

Then again, if I am not mistaken, Unity uses C# for all of its scripting. And in my experience, C# is VERY similar to Java.

"Living is easy with eyes closed, misunderstanding all you see." ¤ Kemoy Labs: http://www.kemoy.net/ ¤ My Site: http://www.jeviny.pw/
Offline princec

JGO Kernel


Medals: 284
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #6 - Posted 2013-05-04 10:57:32 »

My point was, you don't choose to use an alternative technology just because it's similar. Stick with what you know. This is a Java game development board. Saying "you may as well use Unity" because it does the same thing as JMonkeyEngine does is not really a relevant reason to not use JMonkeyEngine.

Cas Smiley

Online matheus23

JGO Kernel


Medals: 98
Projects: 3


You think about my Avatar right now!


« Reply #7 - Posted 2013-05-04 11:04:02 »

My point was, you don't choose to use an alternative technology just because it's similar. Stick with what you know. This is a Java game development board. Saying "you may as well use Unity" because it does the same thing as JMonkeyEngine does is not really a relevant reason to not use JMonkeyEngine.

The part about the board is quite important:
The JMonkeyEngine3 Community sits at the jmonkey forums.
(right at the very moment I went to that link I saw ags1 has posted something. There he went Smiley once he (or she?) was here)

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Offline HeroesGraveDev

JGO Kernel


Medals: 214
Projects: 11
Exp: 2 years


If it wasn't Awesome, it wasn't me.


« Reply #8 - Posted 2013-05-04 11:27:33 »

I was leaning more towards questioning why you'd choose Java over Unity if you were going to use jME.

Offline Cero
« Reply #9 - Posted 2013-05-04 12:05:22 »

I guess izs just because most people here make 2D games, because the scope of a 3D game is just so much greater.
If I would consider making a 3D game, I would try out jme.

I was leaning more towards questioning why you'd choose Java over Unity if you were going to use jME.
Because Unity sucks hard.

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

« In padded room »



TUER


« Reply #10 - Posted 2013-05-04 12:35:40 »

Hi

Jmonkey engine http://jmonkeyengine.com/ is an astonishing piece of software. That would save you guys/gals lots of trouble and debugging.
At first, admit that your knowledge of JOGL is still at least a bit useful when using JMonkeyEngine 3. Secondly, in my humble opinion, JMonkeyEngine 3 is really better than JMonkeyEngine 2 but some users complained about the need of rewriting all build-in shaders because they weren't working as is on all targeted machines and "once bitten, twice shy": some of those who wasted tons of time and suffered a lot with JMonkeyEngine 2 don't want to give JMonkeyEngine 3 a chance. Keep in mind that a developer can waste a lot of time by using the wrong tool(s) or tools neither mature nor reliable enough. The main thing that saves developers lots of trouble and debugging is a real understanding of what happens under the hood. Whatever the tool is, if you don't understand it, you won't succeed.

In my opinion it is the flagship Java game engine.
It's not an opinion, it is a fact. JMonkeyEngine is the defacto flagship in the category "3D Java engine". However, there is no consensus in this domain, that's why there are still some credible alternatives to this engine. As far as I know, there were plans to add a nice 3D API in LibGDX some months ago. As LibGDX is very famous, if it succeeds in 3D, it will harm JMonkeyEngine.

Also, I recently switched from my own proprietary engine to JMonkeyEngine. I'll try to patch over the code from my own proprietary engine to JMonkeyEngine though.
Please contribute. I don't know whether it is what you meant.

So, why don't many or all of you use it?

Do you happen to not know about JMonkeyEngine?
We have different needs. Therefore, we choose different solutions. When I start a new relationship with a woman, I don't wonder why everyone isn't jealous, we have different preferences, there's nothing wrong. For example, people who aren't interested in looking at the source code of an engine to use it and who aren't bothered by relying mainly on EgonOlsen when they need help use JPCT (and/or JPCT-AE). I don't use JMonkeyEngine 3 despite its excellent integrated game development environment based on Netbeans RCP, its nice asset pipeline and shader based architecture, its excellent documentation, tutorials, ... for the following reasons:
- I wasted tons of time on JMonkeyEngine 2 and I don't want to do it again
- 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)
- JMonkeyEngine 3 is shader based and has a separate renderer for the fixed pipeline but the latter would need some more attention and I still want to support OpenGL 1.2
- JMonkeyEngine is nice for games but not very well for applications
- JMonkeyEngine 3 doesn't support key framed animations and this feature was already a bit broken in JMonkeyEngine 2 (I fixed it in another engine with Stranger's and Riven's help)
- using JMonkeyEngine 3 without Netbeans is possible but not documented
- JMonkeyEngine 3 doesn't support Maven, I still have to manually commit new versions of GlueGen, JOAL and JOGL
- JMonkeyEngine doesn't use JOGL 2.0 under Android
- JMonkeyEngine claims to support several bindings of OpenGL since its second version but the JOGL backends are often considered as second class citizens
- JMonkeyEngine 3 doesn't release the native memory used by direct NIO buffers when they become useless which leads to OutOfMemoryError
- JMonkeyEngine 3 supports only a very few 3D formats (Ogre3D and WaveFront OBJ), even fewer than JMonkeyEngine 2

Ardor3D is more appropriate in my particular case because :
- it is generally more reliable than JMonkeyEngine even though it has less features and less documentation
- Renanse has taken me seriously for years (whereas he refused my help to add a JOGL backend into JMonkeyEngine in 2007)
- this is the only 3D engine in Java with an excellent support of the 2 main OpenGL bindings (no second class citizen this time)
- its JOGL 2.0 backend is homogeneous, it supports both OpenGL and partially OpenGL-ES, you don't need to write 3 versions of your game when you target desktop and embedded environments
- Ardor3D 1 doesn't force you to use shaders
- it supports more 3D formats (Collada, WaveFront OBJ, MD2, MD3 soon?)
- its use is possible and documented both with Eclipse and Netbeans
- it uses Maven
- I have added the possibility of overriding the renderer in order to use unsafe code to release the native memory of direct NIO buffers into it
- it's a professional engine, its source code is very clean, its design is excellent, it's used by the NASA, even Oracle used it in Prism several years ago
- it works very well in scientific applications (for example Energy3D), it has a nice but perfectible support of multiple screens
- it has an excellent support of SWT and Swing
- its hardware skinning is more mature than those of JMonkeyEngine 3
- Renanse's experience acquired by years of investment in JMonkeyEngine has been very useful to avoid doing the same mistakes in Ardor3D
- there is a deep separation between its APIs that rely on AWT and the others
- porting features from JMonkeyEngine 2 & 3 to Ardor3D is not very difficult for me
- it almost always benefits of the latest enhancements in JOGL 2.0 before all other engines (that's my fault  Grin)

It would be better if JMonkeyEngine and Ardor3D contributors could work together on the same engine but both have become so different. I'm responsible of engine support at the JogAmp Foundation, I won't stop maintaining JogAmp JMonkeyEngine 3 backend and enhancements for Ardor3D will be ported later to JMonkeyEngine when it is possible but Ardor3D is my flagship and I will go on investing a lot of time in adding tons of features in it. Ardor3D community really takes care of my efforts, the thread about JOGL 2.0 support has been seen more than 24000 times.

Both Ardor3D and JMonkeyEngine have their pros and cons. Just use the one that fits the best your own needs. I don't use a tool because it is "trendy", I use it because it helps me in getting the job done. Minecraft doesn't use JOGL, is it the end of the world? No.

Do you not know it was this good? http://jmonkeyengine.com/engine/

Leave your comments below.
The term "good" is really subjective, it's a matter of opinion. Personally, I use tons of APIs, I'm open minded enough to port and fix bugs in those I don't use in my projects and which I wouldn't recommend (for example Java3D and Xith3D) and I don't try to convince people to use all of them (except JogAmp  Grin). Comparing 2 sets of low level bindings is easier than comparing 2 high level APIs. When your API is mainly a binding of an existing one written in another language, it can't be extremely different than another binding except in the implementation of the bridge between the strict binding and the rest of Java standard APIs whereas 2 engines can implement similar services very differently.

The part about the board is quite important:
The JMonkeyEngine3 Community sits at the jmonkey forums.
(right at the very moment I went to that link I saw ags1 has posted something. There he went Smiley once he (or she?) was here)
You're right, some of us are on both forums.

Maybe I should have got a grounding first before Jmonkey, but now I have a little Idea about what I'm doing I wouldn't want to go back to it!
Why? Your knowledge of a set of low level bindings is still useful when using JMonkeyEngine.

Offline ReBirth
« Reply #11 - Posted 2013-05-04 15:09:41 »

My reason is I'm not on 3D yet. Not be confused by Unity which is also good for 2D, I don't see any 2D games made out by JME.

Quote
JMonkeyEngine 3 doesn't support Maven
Better than "only support Maven". Oh man I don't like mvn.

Offline alaslipknot
« Reply #12 - Posted 2013-05-04 15:19:39 »

isn't obvious  Shocked ??
(ignore the languages) 
    Q - why you don't use GameMaker instead of JME  ?
    A - because JME will give you more freedom and more coding than a GameMaker

    Q- why you use Java2D,Lwjgl,LibGdx,etc...  instead of JME
    A- because Java2D,Lwjgl,LibGdx,etc... will give you more freedom and more coding than JME

so in my opinion i think that the real answer (from a programmer perspective or at least someone who want to be a programmer) is that we don't use a full build engine simply because we want to code more and better .

Am trying ...
hoping that it works
Offline davedes
« Reply #13 - Posted 2013-05-04 16:21:10 »

JME is a good choice if you want to make a 3D game -- probably a more powerful choice than LibGDX in its current state. It now ports to Android.

Re: Unity -- it supports more than Unity Free, but if you have a Unity Pro license, your time would be much better spent using that to create a game.

Offline tberthel
« Reply #14 - Posted 2013-05-04 17:20:52 »

I don't use it because it does not work on J2ME and HTML5 via GWT would be hard to add.

I use a 3D engine that I can use on Android, J2ME, J2SE, HTML5, and Avian.

Offline pixelapp

Junior Member




Pixelapp


« Reply #15 - Posted 2013-05-04 21:37:49 »

If you use jMonkeyEngine you may as well just use Unity.

There is a problem there. I can not contribute to Unity because they don't use Java.

Cloud games and fun.
Offline pixelapp

Junior Member




Pixelapp


« Reply #16 - Posted 2013-05-04 21:39:57 »

I just did't feel I quite had control or understood how it was working. I wanted to explore graphics from the ground up and solve the problems and understand how my own code worked.

That's exactly why I invented my proprietary engine before using other people' engine.  Grin

Cloud games and fun.
Offline pixelapp

Junior Member




Pixelapp


« Reply #17 - Posted 2013-05-04 21:45:28 »

I guess izs just because most people here make 2D games, because the scope of a 3D game is just so much greater.
If I would consider making a 3D game, I would try out jme.

I was leaning more towards questioning why you'd choose Java over Unity if you were going to use jME.
Because Unity sucks hard.

Yep, if I could have any of my first choice engine, Unity would be one of my least favorite. Given that they all used Java.

Cloud games and fun.
Offline pixelapp

Junior Member




Pixelapp


« Reply #18 - Posted 2013-05-04 21:57:46 »

@gouessej I'd love to publish my first JmonkeyEngine game with a JOGL backend. Any ideas on how to do that?

Cloud games and fun.
Offline gouessej

« In padded room »



TUER


« Reply #19 - Posted 2013-05-04 23:57:10 »

BTW gouessej, terrific comparison between the two engines.  I do hope Ardor at least supports or has plans for a 100% shader-based pipeline, though I would agree it defeats the purpose of an engine if doing basic stuff means having to go bare metal with your own shaders.
Yes, it's planned for its second major version. There are already some build-in shaders in the first one but it doesn't go as far as JMonkeyEngine 3 yet. Ardor3D JOGL backend uses some more shaders under the hood when OpenGL-ES is in use.

@gouessej I'd love to publish my first JmonkeyEngine game with a JOGL backend. Any ideas on how to do that?
It should work:
1  
2  
appSettings.setRenderer("JOGL");
appSettings.setAudioRenderer("JOAL");

Offline pixelapp

Junior Member




Pixelapp


« Reply #20 - Posted 2013-05-05 00:08:13 »

Oh, wow  Shocked. I'm crying tears of joy. I thought I had to abandon JOGL while using JMonkeyEngine  Grin.

Cloud games and fun.
Offline gouessej

« In padded room »



TUER


« Reply #21 - Posted 2013-05-05 10:33:35 »

Oh, wow  Shocked. I'm crying tears of joy. I thought I had to abandon JOGL while using JMonkeyEngine  Grin.
pixelapp, I already spoke a lot about my ports of several engines on the official JogAmp forum. There is almost no major scenegraph not supporting JOGL 2.0. I just have to admit that the backend of a scenegraph that has a user base in steady decrease is not frequently updated (Xith3D), Java3D is mainly maintained by Harvey, the creator of Nifty GUI is now able to port his code by himself, some other contributors can maintain the JOGL backend of LibGDX (Xerxes already fixed some bugs in it), there are only a very few remaining bugs in the JOGL backend of JMonkeyEngine 3 (a freeze when using AWT/Swing and something broken when using compressed textures) and of course the JOGL 2.0 renderer of Ardor3D is very actively maintained and updated weekly.

You can modify the settings of JMonkeyEngine 3 by following these steps:
1  
2  
3  
4  
5  
6  
AppSettings settings = new AppSettings(true);
settings.setRenderer("JOGL");
settings.setAudioRenderer("JOAL");
Application app = new Application();
app.setSettings(settings);
app.start();

Offline pixelapp

Junior Member




Pixelapp


« Reply #22 - Posted 2013-05-05 18:54:18 »

Good, your code works. But now I'm getting:

java.lang.ClassNotFoundException: com.jme3.system.jogl.JoglDisplay

I think I'm missing the the jme3_jogl.jar but I don't see it anywhere. I can find the actual .java classes online, but the jar its what I'm supposed to find and I don't see them.

Cloud games and fun.
Offline pixelapp

Junior Member




Pixelapp


« Reply #23 - Posted 2013-05-05 19:17:04 »

I can see the class is located here:

https://code.google.com/p/jmonkeyengine/source/browse/#svn%2Ftrunk%2Fengine%2Fsrc%2Fjogl%2Fcom%2Fjme3%2Frenderer%2Fjogl

but I could use the .jar, though.

Cloud games and fun.
Offline gouessej

« In padded room »



TUER


« Reply #24 - Posted 2013-05-05 21:51:36 »

Maybe the other contributors did nothing to put the JOGL backend into the released JAR. If this is the case, I'm a bit disappointed. You can use the version of the trunk, it works very well.

I have forgotten to talk about another difference between JMonkeyEngine 3 and Ardor3D. The former has some support of BIH whereas the latter has no equivalent of this feature.

Offline ags1

JGO Knight


Medals: 29
Projects: 2
Exp: 5 years


Make code not war!


« Reply #25 - Posted 2013-05-05 22:37:13 »

My point was, you don't choose to use an alternative technology just because it's similar. Stick with what you know. This is a Java game development board. Saying "you may as well use Unity" because it does the same thing as JMonkeyEngine does is not really a relevant reason to not use JMonkeyEngine.

The part about the board is quite important:
The JMonkeyEngine3 Community sits at the jmonkey forums.
(right at the very moment I went to that link I saw ags1 has posted something. There he went Smiley once he (or she?) was here)

She :-)

I post on the JME forum with JME-specific issues as that is where all the JME users are. I post on the Java-Gaming forum when I have more general stuff. The JME forums are not very sociable, while Java-Gaming is.

Don't forget you get a great set of samples with JME, showing how to do most anything, and you also get the full sources. In terms of learning OpenGL and game development, that makes all the difference to me. I can start with a working shader app, tear it it down and rebuild it - which is a far better way to learn than a blank page of '100% my own code'.

JME is unabashedly 'shader-centric' - and that is a good thing. That is just the way modern 3D games are written, why would it do anything else? On the other hand, they provide a rich basis for your own shader code, with everything from lighting to post-processing handled.

Offline Agro
« Reply #26 - Posted 2013-05-05 22:51:35 »

FlasCC is going to own Unity in all ways. Smiley

it allows games to be written in C/c++, and everyone already practically has flash installed on their computers. I tried the unreal engine on flascc, and for a browser on linux, framerate was amazing.

Offline gouessej

« In padded room »



TUER


« Reply #27 - Posted 2013-05-05 22:52:20 »

She :-)
I'm almost sure you're the only woman here.

JME is unabashedly 'shader-centric' - and that is a good thing. That is just the way modern 3D games are written, why would it do anything else? On the other hand, they provide a rich basis for your own shader code, with everything from lighting to post-processing handled.
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.

Offline ags1

JGO Knight


Medals: 29
Projects: 2
Exp: 5 years


Make code not war!


« Reply #28 - Posted 2013-05-05 23:02:22 »

She :-)
I'm almost sure you're the only woman here.

JME is unabashedly 'shader-centric' - and that is a good thing. That is just the way modern 3D games are written, why would it do anything else? On the other hand, they provide a rich basis for your own shader code, with everything from lighting to post-processing handled.
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.

Offline Cero
« Reply #29 - Posted 2013-05-05 23:08:19 »

@offtopic
Bonbon-chan is female too Tongue

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.

xsi3rr4x (72 views)
2014-04-15 18:08:23

BurntPizza (68 views)
2014-04-15 03:46:01

UprightPath (79 views)
2014-04-14 17:39:50

UprightPath (65 views)
2014-04-14 17:35:47

Porlus (80 views)
2014-04-14 15:48:38

tom_mai78101 (104 views)
2014-04-10 04:04:31

BurntPizza (164 views)
2014-04-08 23:06:04

tom_mai78101 (260 views)
2014-04-05 13:34:39

trollwarrior1 (210 views)
2014-04-04 12:06:45

CJLetsGame (220 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
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!