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] 5 6 ... 10
 on: 2016-09-28 19:22:01 
Started by BurntPizza - Last post by FabulousFellini
Finally started my big boy job today!  I can 'almost' now say that I am a developer. 

 on: 2016-09-28 17:32:40 
Started by Ecumene - Last post by purenickery
Thanks for the in-depth reply! Here's some more information:

Based on the testing and timings that we've done, I figure it *has* to be something other than writing to the depth buffer itself that is causing the problem. Just to test it out (and I might end up keeping it this way), I had a free channel in my shadow frame buffer that I wasn't using, so I manually wrote the depth of all the objects to the free channel in the shadow buffer. Then, in the main rendering shader, I checked the depth against the channel in the shadow buffer and drew/didn't draw the pixel accordingly. On my laptop with integrated GPU, it ran at around 250 FPS this way, while with the standard depth buffer it ran at 30-40 FPS. On my PC with dedicated graphics it has no real impact compared to standard depth testing.

There is no way the code I scraped together is 5 times more efficient than the built in depth testing so I figure there has to be something else we were doing wrong  Huh

 on: 2016-09-28 17:15:22 
Started by Fishbreath - Last post by Fishbreath
Attention, entrants: you now have 77 days to go until the deadline!

OpenTafl is playing at its highest level ever, reasonably able to defeat decent players on 7x7 boards, but the 11x11 board still proves to be a lot of trouble. I hope to spend some more time on that later this month.

How's everyone else doing?

 on: 2016-09-28 17:13:34 
Started by Fishbreath - Last post by Fishbreath
OpenTafl v0.4.4.5b is the current stable version. It features four tafl puzzles: as far as I know, the largest assemblage of tafl puzzles in the modern era. (Which is a little sad, but I'm always working on expanding the stable.)

 on: 2016-09-28 17:09:41 
Started by BurntPizza - Last post by ra4king
Ridiculously proud to go to a school that's ranked 5th IN THE WORLD in Computer Science by the Wall Street Journal. This was just published by them.

 on: 2016-09-28 15:27:22 
Started by Baseball435 - Last post by SteveSmith
I have to say I think this is great.  I've recently got bored of my latest project, and have been scouring the web for any decent-looking mildy-active well-progressed open-source Java games, and this is the only one I've found that comes close, and Baseball should be applauded for open-sourcing it.  I'm not sure I'll be able to contribute much, but I look forward to having a play with it.

 on: 2016-09-28 15:20:20 
Started by xTheGamerPlayz - Last post by KevinWorkman
The thing that finally made it click for me was this article on variables:

And its follow-up on passing by value:

I highly recommend reading these (in order) for anybody who is still confused about passing by value.

 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.

 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=";hl=en_US&amp;start=" target="_blank">;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.

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

Android version available:

 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.

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

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

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

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

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

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

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

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

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

Nihilhis (741 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 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‑
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!