Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (714)
Games in Android Showcase (214)
games submitted by our members
Games in WIP (787)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 ... 4 5 [6] 7 8 ... 10
 51 
 on: 2017-03-23 21:58:17 
Started by EnderNinja7 - Last post by theagentd
As everyone's already said, display lists are deprecated since many years back. Vertex buffer objects is the way to go nowadays.

There's a reason why voxels are generally kept pretty big. Storing volume information requires huge amounts of memory usually. Consider a simple case where you want a 500 voxel view distance and you have a maximum height of 200 voxels. To allow the player to look around properly, you'd need to have all voxels within a 500 radius circle around the player loaded in. This is essentially a 1000x1000x200 volume of voxels, or two hundred MILLION voxels. Storing each voxel as an object will use at least 8 bytes per voxel (even an empty Java object uses 8 bytes), so you're already talking about 1000*1000*200*8 bytes, which is equal to 1.5GBs of memory right there. Let's say you want smaller voxels, so you cut each voxel into 8 smaller voxels. Well, now you have 8 times as many voxels, so that's 12GBs of memory you have now. There are a lot of tricks for reducing the memory usage of voxel worlds, and this should be your first focus (after you got basic rendering working).

Tessellation isn't really something you can use for voxel worlds effectively to get smaller voxels. Due to how most voxel world rendering techniques work, both the smallest and biggest piece of geometry you can render is a single voxel's face. The nature of voxel worlds makes it very hard to combine multiple voxels into a single surface without handling a lot of special cases, so it's an optimization that is rarely done. Tessellation allows you to dynamically divide one triangle or quad into more triangles or quads. This isn't really what you want to do in your voxel world, because it would require you to merge voxels ahead of time, then dynamically subdivide them again to get the original voxels back, which like I said is really hard to do. This means that tessellation doesn't really fill much of a function in voxel worlds. If none of what I just said makes sense to you, you should consider reading up more on tessellation and what it's actually used for nowadays, what its advantages and disadvantages are, etc.

Realistic physics can be a big challenge to do for big worlds. Again, memory usage can be a big issue, but performance is a more likely problem here as well. If you're hellbent on having physics, I'd recommend taking a look at the Bullet physics engine, as that's your best bet at achieving realistic physics. Still, it's definitely not an easy task.

Indeed, shaders are a must for the OpenGL 3 pipeline, because you literally need to have a shader program to be able to render anything at all. That is unless you use the compatibility profile, which is basically just the ability to use the older stuff that they removed from OpenGL 3 in OpenGL 3, which means... that it's not really OpenGL 3 in the first place. It sounds like you need to get some basic rendering working in the OpenGL 3 pipeline before you should start with your voxel world. Don't worry though; rendering a voxel world isn't that complicated once you actually got your first couple of triangles rendered properly.

If you want to target consoles, then Java is definitely the wrong platform for you. Although there are ways to run Java games on consoles, there's currently no known way of achieving hardware acceleration for the graphics (or OpenGL at all), so they're essentially limited to simple 2D graphics. You need to look elsewhere if you want to run your games on consoles, probably the Unity engine and Unreal engine. If you just want to run your game on phones and tablets (as well as PC), then Java is a great choice. LibGDX is the go-to library for that, but LWJGL is seeing initial support for Android right now. Exciting times!

I don't want to be negative, but you may want to take a step back and try to figure out what is actually achievable for you at your current skill level. It's good that you're trying to learn more to achieve your goals, so don't let me discourage you from continuing, but maybe consider starting with the basics and working yourself up from there at least.

 52 
 on: 2017-03-23 21:26:56 
Started by Vierarmig - Last post by Vierarmig
<a href="http://www.youtube.com/v/y-O8p0M_2PE?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/y-O8p0M_2PE?version=3&amp;hl=en_US&amp;start=</a>
https://youtu.be/y-O8p0M_2PE

<a href="http://www.youtube.com/v/qYZc10dXfQM?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/qYZc10dXfQM?version=3&amp;hl=en_US&amp;start=</a>

 53 
 on: 2017-03-23 18:47:58 
Started by EnderNinja7 - Last post by Longor1996
Display Lists (Minecraft too)

Minecraft does NOT use DisplayLists... it uses vertex arrays/buffers for everything for over two years by now. As elect said, they are deprecated, use vertex arrays/buffers.

 54 
 on: 2017-03-23 15:07:14 
Started by lifesuxtr - Last post by lifesuxtr
1. Get rid of the entire concept of states. Design and code all your GUI screens. And change your frame's content pane appropriately.
2. Setting your frame's size and packing it are two different things. The latter sizes your frame based on its children's size. Ditch the packing and use layout managers to size your components. Generally speaking, a component should only defines its preferred size and handle cases where its smaller or bigger than that its preferred size.
3. Don't use Canvas. It cannot be used with JLayeredPane, which is necessary for a HUD.

thanks for advices but if im not gonna use canvas what im gonna use ?

 55 
 on: 2017-03-23 08:38:54 
Started by EnderNinja7 - Last post by elect
Display lists are deprecated, skip them

 56 
 on: 2017-03-23 07:28:59 
Started by EnderNinja7 - Last post by EnderNinja7
I am working on a voxel engine. When I saw all the other voxel engines here I saw that most of the projects were rendered using Display Lists (Minecraft too) . Is there a reason for this? According to AlwaysGeeky https://sites.google.com/site/letsmakeavoxelengine/home/display-lists-or-vertex-buffers :-

Quote
-Vertex buffers allow us to group up our data into a big array and then send it all to the graphics card together (each frame).
-Display lists are special lists of render calls that are stored on the GPU itself and rendered each frame when the list is rendered, but we dont have to send this data to the GPU every frame.

So which one is the best for my requirements (details are given below)

My voxel engine would have :-

Small voxels (I might have to use tessellation)

Realistic physics and lighting (Shaders are a must)

Target - PC, Consoles (hopefully)

Also if Display lists are better can you link a tutorial for that as I am used to OpenGL 3.0 above pipeline ?

 57 
 on: 2017-03-23 04:18:12 
Started by EnderNinja7 - Last post by EnderNinja7
I can use your setup for characters and NPCs. I don't think I should use this for land as :-

1. My voxels are VERY small compared to Minecraft/Cubeworld/Other projects here. It is about this size:-
https://drive.google.com/file/d/0B-37T28tGwC7Z3lneWJxSnhNeU0/view?usp=sharing

2. Since there are very small voxels, there would be a lot of instances as compared to the standard textured voxel engine ( The chunk size is being debated on). And according to KaiHH :-
Quote
You do not need matrices at all. They're overkill for what you are doing. Just assign each visible cube a 3-component vector denoting its position.
After all I only need positions for the land cubes.

Thanks.

 58 
 on: 2017-03-22 23:18:54 
Started by homac - Last post by gouessej
You don't talk about GlueGen.

 59 
 on: 2017-03-22 21:58:12 
Started by jorge - Last post by jorge
Solved.

 60 
 on: 2017-03-22 21:47:14 
Started by homac - Last post by homac
My approach has significantly changed, since I'm no longer aiming to support dynamic code generation. Instead I'm going to provide plugins for IDEs to trigger code generation for selected types, similar in its methodology to for example generating getter and setter methods for selected members of a class.

See update here: http://homac.cakelab.org/projects/org.cakelab.nio/current.html

(probably TL;TR)

Pages: 1 ... 4 5 [6] 7 8 ... 10
 
CopyableCougar4 (92 views)
2017-03-24 15:39:42

theagentd (76 views)
2017-03-24 15:32:08

Rule (137 views)
2017-03-19 12:43:22

Rule (124 views)
2017-03-19 12:42:17

Rule (129 views)
2017-03-19 12:36:21

theagentd (142 views)
2017-03-16 05:07:07

theagentd (140 views)
2017-03-15 22:37:06

theagentd (123 views)
2017-03-15 22:32:18

theagentd (117 views)
2017-03-15 22:31:11

ral0r2 (153 views)
2017-03-03 11:52:41
List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05

SF/X Libraries
by SkyAphid
2017-03-02 06:38:56

SF/X Libraries
by SkyAphid
2017-03-02 06:38:32

SF/X Libraries
by SkyAphid
2017-03-02 06:38:05

SF/X Libraries
by SkyAphid
2017-03-02 06:37:51
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!