Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (711)
Games in Android Showcase (213)
games submitted by our members
Games in WIP (785)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1] 2 3 ... 120
1  Game Development / Newbie & Debugging Questions / Re: [LWJGL3/OpenGL] New window mode versus VAO on: 2017-02-24 12:33:28
The latest nightly build of LWJGL should include the 3.3 beta version of GLFW. I use it right now. =P
2  Game Development / Game Mechanics / Re: Simulating orbital gravity with a prediction of trajectory (Multiple attractors) on: 2017-02-23 19:43:56
I assume that what you're looking for is: given the data of a body, figure out what its position will be after N seconds given that it is attracted by these K other bodies. This is actually an unsolved mathematical problem: https://en.wikipedia.org/wiki/N-body_problem
Quote
To this purpose the two-body problem has been completely solved and is discussed below; as is the famous restricted 3-Body Problem.

The only real way of "solving" this with more than 2/3 bodies is to simulate the whole thing. There are no known formulas or algorithms that don't involve integrating with a certain time step (AKA simulating).
3  Game Development / Newbie & Debugging Questions / Re: mt object wouldnt load image on: 2017-02-21 14:06:53
You should never ever silently swallow an exception like that. You're probably getting an error telling you what the problem is.
4  Game Development / Newbie & Debugging Questions / Re: mt object wouldnt load image on: 2017-02-21 10:54:26
MediaTracker is a very outdated way of loading images. I strongly recommend using ImageIO.read() instead!
5  Games Center / WIP games, tools & toy projects / Re: FFP Software Rendered - GFX/Game Progress on: 2017-02-20 11:51:24
Can't think of any particular example, but I'd say the user should be able to access all functionalities of the engine, and to access them without having to go through a long process of invoking ten methods and using objects with confusing names just for one purpose... Do I even make sense at all?
No. Wink Are you referring to LWJGL specifically or just OpenGL?
6  Discussions / Miscellaneous Topics / Re: What I did today on: 2017-02-19 15:17:38
Nice job)
I also may recommend try put draw in to DisplayList
– yes I know it deprecated – but you don’t lose anything trying)
Good idea, but testing that would require half a rewrite of my model renderer ingame, so I'd have to write an artifical test for it... Also, the amount of optimization the drivers do will vary a lot between vendors, so I'm not sure the information would be that valuable.

RYG did an easy to understand breakdown of out-of-order optimization of some code by PhysX author Pierre Terdiman,
https://gist.github.com/rygorous/fdd41f45b24472649aaeb5b55bbe6e26?ts=4
Hmm. Is there any way could write code that would take advantage of that info in Java? Some pattern that helps Hotspot do the same thing I mean.
7  Discussions / Miscellaneous Topics / Re: What I did today on: 2017-02-18 16:05:05
Try the average of the 3 verts as the sort key.

Cas Smiley
It's the exact same thing. The average is (i1 + i2 + i3) / 3, so I'm just sorting based on <average>*3.
8  Discussions / Miscellaneous Topics / Re: What I did today on: 2017-02-18 15:22:46
I seem to recall years and years ago getting perfectly decent performance optimisation just by the simple expedient of sorting triangles in order of their average vertex index number. And that's O(n log n) perf on average. It's not quite as fancy but it gets like 90% of the win for bugger all effort and the best bit is that it can be done in realtime with dynamic meshes. Food for thought. (Why not try it and compare?)

Cas Smiley
Actually, the first thing I did was sort based on the lowest index number. It couldn't compare to Tom's algorithm. Hmm... I'm gonna try something similar though.


EDIT: So I tried something really simple:

1. Sort triangles based on (i0 + i1 + i2).
2. Reorder vertices in the order they are used by the triangles (= the pre-transform cache coherency optimization, step 3 in my previous long post).
3. Repeat until the result gets stable.

The result was actually pretty good, but still not as good as Tom Forsyth's algorithm.

Quote
Simple algorithm after 86 iterations: invocations: 38544 --> 26902 --> 14308 (62.878788% reduction, 54.71454% more than optimal)
Tom Forsyth's algorithm: 38544 --> 26902 --> 11904 (69.115814% reduction, 28.719727% more than optimal)

EDIT 2: According to Forsyth, his algorithm can be implemented in linear time.

EDIT 3: Note that all the invocations counts are reported by the hardware of my Nvidia GPU. The numbers may be very different on AMD and Intel GPUs.
9  Discussions / Miscellaneous Topics / Re: What I did today on: 2017-02-18 13:44:48
You never fail to amaze me, agent. Never thought that index ordering could have such an impact. This topic is now definitely on my (long) list of TODOs. Are games nowadays always optimizing this? And....since you implement so much stuff, why don't you share your repository or your code?  Pointing
Thanks. =P

I'd imagine most games do something to optimize this since the gains can be so huge. In my case, it was really going from the worst possible case to almost optimal reuse, so my gains were a bit exaggerated.

Here's the code for my triangle order optimizer: http://www.java-gaming.org/?action=pastebin&id=1508 My implementation is O(n^2), so not entirely optimal according to the original paper. Still, it's fast enough for my uses. A 12 848 triangle mesh took 260ms to optimize for me, so good enough for an offline tool. There's some low-hanging fruit in there to optimize.

Here's the pre-vertex cache optimizer code. http://www.java-gaming.org/?action=pastebin&id=1509 Very simple, there's probably much better algorithms out there, but I couldn't measure significant gains from running this anyway.

Note: You should always run the triangle order optimizer FIRST, then run the pre-vertex cache optimizer. The triangle order optimizer messes up the vertex order, which the pre-vertex cache optimizer fixes without changing the triangle order.
10  Discussions / Miscellaneous Topics / Re: What I did today on: 2017-02-17 16:40:02
Today, I wrote a mesh optimizer in Java to be used on the output of my Blender export plugin.

I'm not too proficient in Python and it's just so goddamn slow at everything, so instead of completely ruining the fast export times I've managed to get so far, I opted for writing a simple optimizer that takes in a model file, optimizes it, then writes it out again. This is done in 3 steps:

1. In the first step, I simply eliminate all duplicated vertices and leave just one of each, then reference the same one with an index buffer. The mesh I output from Blender is mostly unoptimized with lots of duplicated vertices, and this step reduces the vertex count by about 75% percent. This saves a lot of memory on the harddrive and reduces loadtimes a lot, but it actually does not improve performance very much. For example, in one of the submeshes of the giant robots of Robot Farm, the vertex count goes from 38544 --> 9248, a 76% reduction, but the number of vertex shader invocations only drop from 38544 --> 26902, a 30% drop. This leads to the next step...

2. In the next step, the triangles in the mesh is reordered to improve the effectiveness of the hardware vertex cache. As some people might remember, I've done a lot of experiments on the hardware vertex caches of Nvidia, AMD and Intel GPUs, and basically concluded that Nvidia's is f**king weird, AMD's is kinda weird and Intel's is the only sane one. In the end, I concluded that optimizing the meshes for each graphics vendor was too much work, so I simply went with a mainstream algorithm. I ended up implementing Tom Forsyth's simple algorithm, and it works really well. This algorithm simply reorders the triangles in the mesh (by reordering the indices in the index buffer) to increase the chance that vertices are reused as much as possible without specializing it too much to a specific cache size. It's pretty much a general-purpose optimization that should be better than nothing. Anyway, this step further reduced the vertex shader invocation count from 26902 --> 11847, which together with step 1 was a total reduction of 70%! Now, optimally, the number of invocations should be equal to the number of vertices in the mesh, which would mean that there is perfect reuse of vertices and no vertex had to be transformed more than once, but it may not be possible to achieve this. In the end, for this particular mesh the number of invocations is 28% more than optimal, which is acceptable to me.

3. Now, the meshes are optimized for the vertex cache and need a minimal number of vertex shader invocations, but there is one last thing that can be optimized. Inspecting the actual index buffer generated after step 2 reordered the triangles, it's pretty damn random.
Quote
..., 6031, 5989, 5991, 5992, 5993, 5991, 6032, 5992, 5994, 5995, 5996, 5994, 6033, 5995, 8387, 8388, 8389, 8387, 8409, 8388, 8390, 8391, 8392, 8390...
There's a lot of good reuse happening here, but also very huge jumps in which vertex each triangle uses. It essentially reads a completely random vertex from the vertex buffer each execution. This is bad for the GPU, as the vertex data from the VBO is read in with a certain cache line size depending on the GPU. In short, if you reference vertex 1000 and 1001, there's a big chance that the memory read for the data of vertex 1000 will cause the data for vertex 1001 to also be loaded into the cache. Therefore, it is a good idea to try to minimize the "distance" between each subsequent index in the index buffer to increase the chance of the input data of the vertex shader already being in the cache. I did this by simply reordering the vertices in the data to so that they are in the order that the index buffer references them. This does not change the triangle order; it simply changes where the vertices of each triangle lies in memory. Here's an excerpt from the output index buffer:
Quote
..., 2571, 2565, 2571, 2568, 2566, 2567, 2572, 2571, 2566, 2572, 2572, 2567, 2573, 2571, 2574, 2568, 2569, 2568, 2574, 2569, 2575, 2570, 2569, 2574, 2575, 2575, 2576, 2570, 2571, 2572, ...
Much better! This works super well with the optimized triangle order from step 2, as the algorithm tries to place all uses of a given vertex in one place so that it can be reused, so there's a very low risk of a very old vertex being referenced again. To measure the effectiveness of this step, I measured the average "index distance", which is the average
abs(currentIndex - previousIndex)
over the entire index buffer. The average index distance went from 42.82251 --> 5.490958, a very significant improvement to cache coherency!

All in all, here are the final results for the mesh:
Quote
Eliminating duplicate vertices...
Optimizing for post-transform vertex cache...
Optimizing for pre-transform vertex cache...
Vertex count: 38544 --> 9248 (76.00664% reduction)
Invocations: 38544 --> 26902 --> 11847 (69.2637% reduction, 28.103378% more than optimal)
Average index distance: 42.82251 --> 5.490958

Placing 500 of those high-poly robots with no LOD or anything in a test program, my FPS went from 12 to 32 when I switched to the optimized mesh, a ~62.5% reduction in frame time, which matches very well with the ~~70% invocation reduction when you add postprocessing and everything else taking up a bit of time in the first place.
11  Game Development / Newbie & Debugging Questions / Re: [LWJGL3/OpenGL] New window mode versus VAO on: 2017-02-16 22:59:32
I'm assuming you're doing this with shared contexts, basically trying to pass on the old objects to the new context before destroying the old one. Sadly, not all OpenGL objects are shared. Anything that by itself doesn't contain any actual data is not shared between contexts. In other words, things like textures and buffers are shared because they contain data, but FBOs and VAOs are not because they only contain references to other objects.

There are lots of functions in GLFW to change the setup of the window without recreating it. You can go fullscreen, disable the decoration to make a window borderless, etc. See glfwSetWindowMonitor() and glfwSetWindowAttrib().
12  Games Center / WIP games, tools & toy projects / Re: Robot Farm on: 2017-02-16 18:24:45
WHOOOOOOOO
13  Discussions / Miscellaneous Topics / Re: What I did today on: 2017-02-16 13:14:20
These last few days, I've worked on improving the RF graphics, since that's one of the main criticisms we got for it.

We don't really draw our houses in RF; we just draw the walls on the ground and leave the rest to the user's imagination. Now, some time ago I added a day/night-cycle, where the ambient light changes over the course of the day, with nice orange mornings and sunsets, and really dark nights. It's really nice, but didn't really have much impact due to the lack of shadows. I realized that I could really easily draw some sun shadows using the same shader and system as for point lights, allowing for a full day/night-cycle with the sun casting long shadows from the buildings, which even have faked roofs casting shadows now, which helps conveying the actual size and shape of the house even though we don't draw it.

I also added cloud shadows that slowly float over the screen and change shape, and added a cloudiness parameter that allows the clouds to be slowly faded in and out, allowing for transitions from a sunny day to a cloudy day over a couple of minutes of playtime, with really good results. I had to make a few compromises on the clouds though, as I really needed bicubic filtering to get them to look good. Still, I'm happy with the results.

Today I added "raytraced" god rays based on said clouds. It's pretty crazy heavy, but done at 1/16th the normal tile resolution so it's not too slow. They're accurate and follow the shape of the clouds as they float by. The intensity of the clouds are faded in based on the cloudiness parameter, so on clear days the god rays will essentially disappear to avoid turning the entire screen white, while on cloudy days the intensity ramps up so that a tiny hole in the cloud cover will cast a glorious pillar of light to the ground.

Here's a pic showing off all the new features:

14  Game Development / Newbie & Debugging Questions / Re: FBO Blending on: 2017-02-13 08:02:21
You'll need to describe your problem better. Show us some screenshots of the problem and most important of all tell us exactly what result you're expecting.
15  Java Game APIs & Engines / Java 2D / Re: Blu-Play: An introduction to developers on: 2017-02-13 00:10:53
Still, PS4 should logically be a great deal faster than the PS3, so I wouldn't rule out the possibility. In any case, it's always bad practice to rule anything out before having tried. That's the whole reason why no one here has ever heard of BD-J before - because everyone wrote it off, claiming it couldn't do anything. But I'm proving everyone wrong now, when I release "Ukko's Journey".
That's probably not true... The PS3 CPU was a really weird beast. It had 1 fast main 3.2GHz CPU core, and then 7 extremely specialized computing cores of which 1 was reserved for the OS, leaving 6 for games to utilize. However, the PS3's GPU was extremely slow, so the SPUs were used to compensate for that. At the end of the PS3's lifetime they even started doing shading and postprocessing on the CPU just to free the GPU from some work, but I digress. The PS4 has a 1.6GHz octa-core CPU, which uses GDDR5 memory (GPU memory) even for the CPU. This means that a single core on the PS4 cannot beat the beefy main core of the PS3, and in addition it has RAM that is worse for CPU computations. I doubt you're gonna be able to do fancy threading on BD-J to utilize all the PS4's cores, and when comparing single-threaded performance I'm afraid the PS3 is actually gonna be the fastest.


Since my engine is a software renderer I believe it can run on BD-J
Now that would be really cool to see! =P
16  Java Game APIs & Engines / Java 2D / Re: Blu-Play: An introduction to developers on: 2017-02-12 15:35:28
From what I can tell, they implemented a software OpenGL renderer over Java2D. That's simply not even close to good enough for 3D games.
17  Java Game APIs & Engines / Engines, Libraries and Tools / Re: GLFW Key Event Bouncing on: 2017-02-11 10:37:19
GLFW includes GLFW_REPEAT which is for repeat keys. It could be a bug in GLFW. Consider opening a ticket on their repo on Github.
18  Java Game APIs & Engines / Java 2D / Re: Blu-Play: An introduction to developers on: 2017-02-11 10:16:39
This is limited to Java2D? Any OpenGL/OpenAL?
19  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Ongoing project: Type-Safe access to ByteBuffers on: 2017-02-05 15:14:47
And talking about intrusiveness .. having another build step is intrusive as well .. don't you think?
Not if I can use the runtime compilation of the helper classes for debugging, then seamlessly switch to the prebuilt one for actual releases.
20  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Ongoing project: Type-Safe access to ByteBuffers on: 2017-02-05 14:27:35
How does your code work? Does it actually generate a new implementation of the class when you first load() it? What kind of overhead are we talking about? Garbage? Can I control the ordering of elements? I can see this being useful for uniform buffers for example, while being a bit less intrusive compared to MappedObjects, which require a Java agent.

More questions:
 - It's very rare to read back a data structure from OpenGL at least. For writing it should only need a setX() function, as it can figure out the type of it from the argument to it. A write-only structure should then only need a setX() function for each parameter, minimizing the boilerplate code you have to write for the code generation to work. Similarly, you could have a read-only data structure which only has a getX() function, with the types gathered from the return types of those functions. Also, since MyData won't need to contain
float x, y;
with these changes, there won't be any wasted memory.
 - It'd be useful to have a way to precompile said classes so that no reflection is needed to use this.

Also, you can place your code in a code block on this forum, see the hashtag button when writing your posts.
21  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Ongoing project: Type-Safe access to ByteBuffers on: 2017-02-05 13:17:22
Do you have an example of the workflow? I'm interested.
22  Discussions / Miscellaneous Topics / Re: What I did today on: 2017-02-01 23:31:35
i had a twist on PBR + rendering to cubemaps to keep the background in sync.


Is that image-based lighting or just plain cube map reflections? I'd love if you logged onto Skype some time too; got a few things to talk with you about. =P
23  Game Development / Newbie & Debugging Questions / Re: Obfuscating assets on: 2017-02-01 12:31:38
There are still some very good reasons for making your own file formats. Having to go through ImageIO and BufferedImage to load a texture means a lot of copies and garbage generated. In addition, generating mipmaps can also take some time, so making your own binary image format with precomputed mipmaps is a pretty good idea.
24  Game Development / Newbie & Debugging Questions / Re: Obfuscating assets on: 2017-02-01 10:18:57
Make your own texture/model format?
25  Java Game APIs & Engines / OpenGL Development / Re: [Solved]Calculating Depth Values on: 2017-01-31 23:39:39
Ah, ok. Yeah, that formula looks correct.
26  Java Game APIs & Engines / OpenGL Development / Re: [Solved]Calculating Depth Values on: 2017-01-31 10:34:27
That's not how all depth values are calculated.

With orthographic projection, the depth values are indeed linearly distributed. For a given Z-value, it's a simple matter of calculating (Z-min)/(max-min) * 2^depthBits, where depthBits is 24 in your case. If you're using OpenGL, you should just load the 0.0-1.0 float to the depth buffer, as OpenGL will do the quantizing to 16/24/32 bits for you.

With perspective projection, the depth precision is not linearly distributed. They're essentially logarithmically distributed over the view frustum, giving significantly more precision near the camera and much lower precision far away.

27  Discussions / Miscellaneous Topics / Re: What I did today on: 2017-01-28 20:46:17
What's the point of Vulkan if it really is that hard to get anything out of it?

My Games Programming tutor mentioned some 4th year students were making their project using Vulkan
It's not hard to get "anything" out of it. I already have gotten *something* out of it. The reason I'm stuck is because I'm trying to design a swapchain manager that works with a dedicated GLFW thread and dedicated Vulkan thread. The swapchain feature of Vulkan is actually really powerful. In OpenGL you just have the default framebuffer (FBO 0) which you can bind to render to the main screen. This framebuffer is in turn backed by (usually) 2-3 different images to achieve standard double/triple buffering, but these images are hidden and can only be rendered to.

In Vulkan, you create a swapchain which in turn creates the images for you, but the key here is that you actually get access to the actual images. You can use them as compute shader write-only textures, write to them from the CPU (nice for software rendering/emulation!), copy to and from them, even use them as textures if you're feeling nuts. If you want to render to them, you need to bind them to a framebuffer manually. The cool thing about this is that we can even gain a bit of extra performance here by being able to exactly control what happens with the images.

Some hardware requires images to be converted to specific layouts for different usages. They may use different layouts for render targets, for textures and for presenting to the screen. In OpenGL, the driver has to guess what you're trying to do and do these layout transitions implicitly. In Vulkan, you just tell it exactly what to do, which means that you can save a lot of work there. For example, after presenting an image you can skip the layout transition if you know you'll always clear/overwrite the old contents. Also, with the fancy render pass system in Vulkan, this means that you can include the copy to the screen as a subpass, which can help improve performance, especially on mobile/tiled GPUs.
28  Discussions / Miscellaneous Topics / Re: What I did today on: 2017-01-28 19:15:10
I present to you a cube made with Vulkan.



( made with Unity 5.6 beta  Roll Eyes )
Cheating! Here I am still trying to get a solid swapchain system working...
29  Games Center / WIP games, tools & toy projects / Re: Robot Farm on: 2017-01-26 07:14:25
Thanks a lot, it's looking pretty good at the moment.  Wink
30  Games Center / WIP games, tools & toy projects / Re: Robot Farm on: 2017-01-25 17:57:41
Yeeeyyyyyyy
Pages: [1] 2 3 ... 120
 
numerical (364 views)
2017-02-21 07:32:16

numerical (366 views)
2017-02-21 07:31:46

theagentd (476 views)
2017-02-18 13:42:33

theagentd (474 views)
2017-02-18 13:35:16

h.pernpeintner (1640 views)
2017-01-24 22:39:11

h.pernpeintner (1628 views)
2017-01-24 22:38:32

Galdo (2196 views)
2017-01-12 13:44:09

Archive (2155 views)
2017-01-02 05:31:41

0AndrewShepherd0 (2695 views)
2016-12-16 03:58:39

0AndrewShepherd0 (2355 views)
2016-12-15 21:50:57
List of Learning Resources
by elect
2016-09-09 09:47:55

List of Learning Resources
by elect
2016-09-08 09:47:20

List of Learning Resources
by elect
2016-09-08 09:46:51

List of Learning Resources
by elect
2016-09-08 09:46:27

List of Learning Resources
by elect
2016-09-08 09:45:41

List of Learning Resources
by elect
2016-09-08 08:39:20

List of Learning Resources
by elect
2016-09-08 08:38:19

Rendering resources
by Roquen
2016-08-08 05:55:21
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!