Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (775)
Games in Android Showcase (230)
games submitted by our members
Games in WIP (856)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Rendering Method Suggestions?  (Read 2749 times)
0 Members and 1 Guest are viewing this topic.
Offline BlueChaos
« Posted 2014-06-26 00:58:16 »

I'm looking to make a java game and I've researched multiple methods on how to render it but I'm having trouble deciding what method to use. I'm looking for suggestions, experience, or opinions on how you would render the kind of game I'm looking to make. My main concern is performance but if performance can suffer a little for the sake of appearance, then I'm willing to let it pass.

The kind of finished result I'm looking for is an appearance similar to games such as Dragon Quest IX (This is just the first game I thought of that resembled what I want to make, the gameplay has nothing to do with why I gave this game as the example)
Specifically, I'm looking for:
  • A 3D appearance with a third person view towards the character at a ~45 degree angle
  • The illusion of depth that causes objects in the background to appear slightly smaller and slightly larger when in the foreground
  • Optional: The ability for the user/player to rotate the camera angle around the character

I've considered the following methods:
  • 2d using no external libraries and depth appearance calculation
  • 2d using Slick2D and depth appearance calculation
  • 3d using LWJGL VBOs
  • 3d using JMonkeyEngine

I'm sorry if I sound lazy, but I just want to have AS MUCH information on these methods as possible before I begin development.  Also, I have been programming in java and a few other languages for a few years, it's not something that's new to me, I've just never done game development in java only before. If you know of any more methods that you've used or even seen that could be better, I'd be happy to hear about it. Wink
Offline Longarmx
« Reply #1 - Posted 2014-06-26 01:02:14 »

If you want to actually be making a game in 3D, then I would use JMonkeyEngine. Everything else would require a lot of basic setup to get anything working. Also, using if you're concerned about performance, then Java2D (no external libraries) is not the way to go  Smiley

Offline Spacebeans
« Reply #2 - Posted 2014-06-26 01:13:24 »

Certainly JMonkey for 3D. Its allot easier to come from JMonkey to pure OpenGL (LWJGL) than Java2D/Slick2D. Also, Slick is dead. You can still use it, but Kev Glass has stopped developing it :/

If you're planning on getting the most performance out of OpenGL with no proir knowledge... In 3D, good luck Smiley There is a tonne more than just VBOs that you need to learn. Like in OpenGL 3.0 everything is reliant on shaders. Which involves Matrices, Vectors, Translation, Geometry, like... 80 things you could screw up. If I were you, I'd look into the 'Fixed Function Pipeline'. Basically the simplest OpenGL renderer there is, its easy, but craps out on preformance. The 'programmable pipeline' is the one with the cool GLSL shaders, and dynamic differed shading and stuff Smiley

Here are some super good tutorials (Really, read them, they're the best information on OpenGL outside of textbooks)
http://opengl-tutorial.org/
http://nehe.gamedev.net/tutorial/lessons_01__05/22004/
https://www.youtube.com/watch?v=ss3AnSxJ2X8&list=PLEETnX-uPtBXP_B2yupUKlflXBznWIlL5
^^ Pure openGL tutorial, and probably one of the best out there for 3.0 beginners.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline LiquidNitrogen
« Reply #3 - Posted 2014-06-26 01:13:56 »

The ability to smoothly scale sprites in modern 2d graphics would make it quite easy to set up a 3d positioning system, drawing 2d sprites with the appearance of depth as you describe, you could even have fairly flexible control of camera positioning and rotation, requiring some basic trig calculations. Adding scenery to such a system would probably be very difficult, and over all would generally look rough unless you were aiming for an abstract design. It could be possible with some creativity, but getting the look you want is probably easier with proper 3d rendering.
Offline BlueChaos
« Reply #4 - Posted 2014-06-26 02:01:32 »

I have seen that JMonkeyEngine is the preferred Jame Game Engine, but I haven't been able to find too much information on how it's performance handles. I know that performance is subjective based on the user's computer specs but obviously I'd like the game to be as smooth as possible. I had first imagined that running a game with a large amount of 3d models (large meaning 200+, most of the 200 being non-animated scenery like trees, the res), even if they are all low-poly models, would cause a low frame-rate. Although after doing some more research on this, I found that it can depend more on the objects behind the model, if the model has animations.

So my question now is, at what point should performance become a concern when using JMonkeyEngine?

I haven't completely decided on JMonkeyEngine yet so if anyone has anymore ideas or information on rendering, I'd still love to hear it.
Offline BurntPizza

« JGO Bitwise Duke »


Medals: 486
Exp: 7 years



« Reply #5 - Posted 2014-06-26 02:05:05 »

I'm guessing that, as a rule of thumb, if a library/engine is in at least fairly wide use, it performs well enough. If it didn't, then someone would have made a better successor to it. Evolution!

Of course performance depends on the code you write too, i.e. don't bubblesort all game objects every frame, etc.
Offline JESTERRRRRR
« Reply #6 - Posted 2014-06-26 05:19:05 »

I use JME a lot, and yes it is extremely good, and I recommend it highly if you want to get on with your game and make serious progress. Performance wise, I can't really fault it, judging from looking at screenshots of Dragon Quest IX I dont think you'd have a problem, and it would be easy to just render certain segments as you attach models to nodes, and just tell it not to draw them depending on area.

One word of warning though: lights. If you're planning on just using ambient lighting, great. If you're planning on using lightmaps that are baked into the texture, also good. But the lights in JME... for each light, the entire scene is rendered again.. so 10 lights = render the same model 10 times - regardless of if you have a light with a tiny radius.

You could also consider JPCT - its slightly harder to get fancy graphical effects, but still its simple and robust 3d. Also it does not have the above light problem, limits each surface to 8 lights which it choses (but then again it uses vertex lighting which is not as pretty - depends what you want ultimately, can make it look better if you're willing to do some shader work).
Offline BlueChaos
« Reply #7 - Posted 2014-06-27 00:54:24 »

I'm guessing that, as a rule of thumb, if a library/engine is in at least fairly wide use, it performs well enough. If it didn't, then someone would have made a better successor to it. Evolution!

Of course performance depends on the code you write too, i.e. don't bubblesort all game objects every frame, etc.

I can understand that but there are of course some engines that are better for one thing and others that are better for something else. I've just never seen JME used for anything performance heavy.

One word of warning though: lights. If you're planning on just using ambient lighting, great. If you're planning on using lightmaps that are baked into the texture, also good. But the lights in JME... for each light, the entire scene is rendered again.. so 10 lights = render the same model 10 times - regardless of if you have a light with a tiny radius.

I assume this goes for same type lighting as well... 2 ambient lights render the model/scene twice. Also, JME wouldn't calculate the lighting - or even load the model itself - if that object isn't in view correct?
Offline JESTERRRRRR
« Reply #8 - Posted 2014-06-27 02:45:09 »

Well, yes to your first, but you would never have 2 ambient lights as it would be pointless. Not sure about the second. You would load the model, then if you attach it to the rootNode so it will be drawn, I believe it would be culled if it was not in view yes (don't quote me on that). I don't think you'll have any problems to be honest. You add models to Nodes, and then you can add lights to these nodes, so the lights only affect models added to that node. This will help you limit what lights effect, and combined with lightmaps if you are in a position to do that works perfectly.
Offline BlueChaos
« Reply #9 - Posted 2014-06-27 17:04:21 »

Well, yes to your first, but you would never have 2 ambient lights as it would be pointless. Not sure about the second. You would load the model, then if you attach it to the rootNode so it will be drawn, I believe it would be culled if it was not in view yes (don't quote me on that). I don't think you'll have any problems to be honest. You add models to Nodes, and then you can add lights to these nodes, so the lights only affect models added to that node. This will help you limit what lights effect, and combined with lightmaps if you are in a position to do that works perfectly.

Thanks, I'll give JME a try and experiment with a few things.
Pages: [1]
  ignore  |  Print  
 
 

 
hadezbladez (15 views)
2018-11-16 13:46:03

hadezbladez (20 views)
2018-11-16 13:41:33

hadezbladez (6 views)
2018-11-16 13:35:35

hadezbladez (6 views)
2018-11-16 13:32:03

EgonOlsen (1881 views)
2018-06-10 19:43:48

EgonOlsen (1904 views)
2018-06-10 19:43:44

EgonOlsen (1261 views)
2018-06-10 19:43:20

DesertCoockie (1707 views)
2018-05-13 18:23:11

nelsongames (1392 views)
2018-04-24 18:15:36

nelsongames (2007 views)
2018-04-24 18:14:32
Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46
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!