Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (690)
Games in Android Showcase (201)
games submitted by our members
Games in WIP (764)
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] 3 4 ... 10
 11 
 on: 2016-09-28 05:20:08 
Started by Ecumene - Last post by theagentd
- The game runs slower the more we depth-test
= "the more overdraw we add"? That would of course be expected, as more pixels = more work, especially for a shitty integrated laptop GPU.

That being said, depth testing with 3D geometry usually improves performance as the depth test can run before the fragment shader, allowing the GPU to avoid running the fragment shader for occluded pixels. This depends on two things to work:

 - If the shader writes to gl_FragDepth, the shader implicitly has to run before the depth test as it determines the value used in the comparison. This has VERY significant performance implications.
 - If discard; is used, the early depth test's functionality is severely limited as it cannot update the value in the depth buffer until the shader has executed or it would write depth for discarded pixels. This again can have performance implications, but usually not as severe as an early depth test can still be run against previously drawn geometry, potentially avoiding shader execution, but this has to be much more conservative.

You should never write to gl_FragDepth if you can avoid it since it disables so many important optimizations. If your geometry is flat, then simply outputting the depth to the vertices will give you the same result but allow all the optimizations to work as expected. If you however for some reason need non-linear per-pixel depth, there are still things you can do to improve performance. If you are able to calculate the minimum depth (the depth value closest to the camera), you're able to output that as a conservative depth value in the vertex shader. You can then in the fragment shader specify how exactly you will modify the depth value of gl_FragDepth to allow the GPU to run a conservative depth test against the hardware computed depth (the one you outputted from the vertex shader). You always want to modify the depth in the OPPOSITE way that you're testing it. Example:

 - You use GL_LESS for depth testing and the depth is cleared to 1.0.
 - You output the MINIMUM depth that the polygon can possibly have from the vertex shader.
 - In the fragment shader, you specify that the depth value will always be GREATER than the hardware computed value using
layout (depth_greater) out float gl_FragDepth;
.

This will allow your GPU to run a conservative depth test using the hardware computed depth value, at least giving the GPU a chance (similar to when discard; is used) of culling things before running the fragment shader. This feature requires hardware compatibility though, but GL_ARB_conservative_depth is available on all OGL3 GPUs as an extension, even Intel, plus OGL2 Nvidia GPUs. Additionally, this can be queried in the GLSL shader and be enabled if available, and won't cause any damage if it isn't available at least (at least if you skip computing the minimum depth in vertex shader as well).

Clearing the screen to 0.0 would cause nothing to ever pass the depth test if you use standard GL_LESS depth testing. I'd strongly suggest using GL_LESS and clearing to 1.0 instead as that is the standard way of using a depth buffer, which in some cases could be faster in hardware.

If you could specify some more information about your use case, I could give you better advice and more information.

 12 
 on: 2016-09-28 04:44:24 
Started by sandrand - Last post by sandrand
Lee Kee Child is a free classic game for rocks&diamonds games lovers.

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

Lee Kee Child needs to collect diamonds for completing levels.
In some levels flies and butterflies will be chasing him. Possible to
kill enemies by dropping stones, diamonds or touch acid.
When the butterflies die, them turns into diamonds.

Features:
- 225 different levels
- hardware keyboard control support
- save / load functions
Have fun!

Android version available:
https://play.google.com/store/apps/details?id=leekeechild.org





 13 
 on: 2016-09-28 04:28:06 
Started by xTheGamerPlayz - Last post by aldacron
I can't count the number of times I've seen this discussion in different forums, complete with the line that's bound to confuse any newcomer (references in Java are passed by value). It's a confusing and roundabout way of saying that Java classes are 'reference types', built-in types are 'value types', and function arguments are 'passed by value'. The nature of the types needs to be distinguished from the nature of how the instances are handed off in function calls.

 14 
 on: 2016-09-28 03:34:35 
Started by ndnwarrior15 - Last post by ndnwarrior15
I've been working on improving the tilesets and upgrading Open GL from version 1 to 2. It renders smoother with 2 but I'm not quite finished writing the new renderer yet.

Here's my WIP of the new tileset though.


 15 
 on: 2016-09-28 03:24:37 
Started by ndnwarrior15 - Last post by ndnwarrior15
I changed my renderer class to use Open GL ES 2.X and the problem is still there! It's on a Samsung Galaxy S4 though I'm not sure if that matters or not. The phone will play other games fine without the bleeding problem so it must be something wrong with my code though I am at a loss for why.  Sad

I'm going to try a few different things but am really out in the dark at this point. Would appreciate any insights from one of you Open GL ES gurus.

 16 
 on: 2016-09-28 03:15:02 
Started by Ecumene - Last post by Ecumene
In the render method we do two things
 1. Render all entities to an FBO
 2. Scale FBO and draw it to the screen

In the FBO, depth testing is enabled and the resolution is very low
entityBuffer = new FrameBuffer(Format.RGBA8888, (int) camera.viewportWidth, (int) camera.viewportHeight, true);


When drawing to the FBO, there seems to be a pretty big performance difference on what we depth test.
 - The game runs slower the more we depth-test
 - The depth buffer is cleared with 0.0 every frame
 - The framebuffer IS bound, and when we render it depth-testing is disabled
 - We're using
gl_FragDepth
in a shader that renders every entity to the framebuffer to set the depth, disabling it does nothing performance wise

It seems like when I enable the depth buffer while drawing a large group of objects it becomes very slow on my laptop, but my PC with it's dedicated video card does fine.

Is there any way to speed up depth testing? It seems like that's what is slowing the game down

 17 
 on: 2016-09-28 02:28:13 
Started by Scourge - Last post by theagentd
I don't have any performance problems at the moment but I'm thinking about the problem with further development. As example if I implement bump mapping and material maps (specular maps, gloss maps, etc), it will multiply the amount of shaders for each combination. Thinking even further, when I get at the stage where I want to implement my idea of skeletal animations, it would lead to even more shaders. Being at that stage, it would be a lot of work to add more light types or making other improvements because I would have to change tons of shaders.
I'm using deferred shading, so for me the bottleneck is almost always the write to the massive G-buffer (4 render targets!). Due to this, I can get away with always doing normal mapping and reading all 4 optional texture maps I support. The texture units and ALU cores are simply idle otherwise waiting for the ROP writes, so doing some extra reads from empty 4x4 textures won't affect performance at all. Doing small too small draw calls in general is also very bad for GPU performance, small being something like under ~100 triangles or so.

Normal mapping doesn't actually have that much of an overhead, so you should probably be able to get away with just using an pass-through 4x4 texture and always using it.

 18 
 on: 2016-09-27 22:22:38 
Started by Hydroque - Last post by Catharsis
A lot of my bullet points are about the GUI. Although, the real meat lays in editing using effects. I'd be happy with any app that allows for editing brightness of pixels from x to y.
If you got that down, then that would be amazing to release to the community.

Once I finish up all the backend goodness prepping for a larger launch I'll likely consider putting out a free utility app that does basic effects like this to up sell / promote the full deal.

 19 
 on: 2016-09-27 21:19:23 
Started by ags1 - Last post by ags1
Just some images of generated terrain. These are non-vector graphics, which a first for Vangard:




 20 
 on: 2016-09-27 18:06:05 
Started by Scourge - Last post by Scourge
Thank you for your reply.

I don't have any performance problems at the moment but I'm thinking about the problem with further development. As example if I implement bump mapping and material maps (specular maps, gloss maps, etc), it will multiply the amount of shaders for each combination. Thinking even further, when I get at the stage where I want to implement my idea of skeletal animations, it would lead to even more shaders. Being at that stage, it would be a lot of work to add more light types or making other improvements because I would have to change tons of shaders.

A preprocessor for handling includes or even dynamic shader code generation would be a good solution - but at the moment I would rather gather more experience with shaders first before implementing something like that. Therefore I'm asking what would be better and if it might be performant enough I might even keep it that way.

I appreciate your input regarding if statements, that means I wouldn't have a lot of performance problems thanks to sorting my objects to render (which also got frustum culled).

I would like to have some inputs on my other idea by just using 1px fake graphics, if that's not asking too much.

Pages: 1 [2] 3 4 ... 10
 
xTheGamerPlayz (97 views)
2016-09-26 21:26:27

Wave Propagation (294 views)
2016-09-20 13:29:55

steveyg90 (407 views)
2016-09-15 20:41:23

steveyg90 (407 views)
2016-09-15 20:13:52

steveyg90 (447 views)
2016-09-14 14:44:42

steveyg90 (471 views)
2016-09-14 14:42:13

theagentd (477 views)
2016-09-12 16:57:14

theagentd (409 views)
2016-09-12 14:18:31

theagentd (303 views)
2016-09-12 14:14:46

Nihilhis (737 views)
2016-09-01 13:36:54
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!