Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (697)
Games in Android Showcase (202)
games submitted by our members
Games in WIP (767)
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 ... 10
 on: 2016-10-22 18:48:40 
Started by KaiHH - Last post by KaiHH
The next version of JOML, which will be 1.9.0, will feature 'immutable' views/interfaces on all JOML classes.
This feature was proposed over a year ago and finally made its way into the code base.
For a detailed debate/examination of immutable views, have a look at the mentioned GitHub issue #52.

In summary, it allows an API to communicate/express the intent that a data structure, which it exposes or consumes, should/will not be modified by the consumer and/or by the provider. This is valuable in the way that a consumer of that API will know what to do when given a mutable or immutable data structure, which is most apparent when dealing with mutable instances such as Vector4f or Matrix4f, and with a client not knowing whether it can savely store a reference to this instance or (inefficiently) copy the data structure.
Likewise, it protects the API provider from unintentional modifications made by the API consumer.

// API provider:

private Vector4f internal;
public Vector4fc provideImmutable() {
  return internal;
public void consumeImmutable(Vector4fc constVector) {
  // ... constVector will not be modified ...

// API client:

Vector4fc providerVector = api.provideImmutable();
// providerVector will not be changed by API consumer
Vector4f clientVector = new Vector4f(...);

So, it's all about communicating and to some extent enforcing intention of how a data structure is to be used, and by whom. This in turn improves efficiency and reduces errors in programs due to unclear semantics/intentions.

The release will happen in a few days once final testing is done.

People interested in it, can already use it from as org.joml:joml:1.9.0-SNAPSHOT or from the GitHub repository. The API is stable and also completely backwards source-compatible, meaning that porting an unmodified application from earlier JOML versions to 1.9.0 will compile without changes.

 on: 2016-10-22 18:47:44 
Started by KaiHH - Last post by theagentd
I had a rather unique situation where I was using a "circular heightmap", a 1D heightmap that wraps around a circle with a certain resolution. I needed to find out what height index was closest to a certain point (= round(heightmapResolution * atan2(dy, dx) / (2*PI) + 0.5)), one of the rare cases where I actually had to work with angles instead of just vectors. This was being used for collision detection to figure out which part of the heightmap to check the object against, so performance was critical. However, any atan2() approximation I could find had too low precision, and in the case of my collision detection precision was so critical that the approximations caused missed collisions.

My point is that for any actual valid use of atan2() that you can't use vectors for instead, you need very good precision. That being said, if we could find such an approximation I would make very good use of it.

 on: 2016-10-22 18:09:01 
Started by KaiHH - Last post by Roquen
Yes.  The trick is range reduction since atan doesn't converge as fast.  So there are many more choice trade-offs.

 on: 2016-10-22 18:05:05 
Started by KaiHH - Last post by CommanderKeith
Is it possible to make an atan2 approximation using the sollya method you used to make this great sin approximation?

I see that atan2 is not continuous and has vertical asymptotes so would an approximation using this polynomial-fitting method be very good?

 on: 2016-10-22 15:59:12 
Started by KaiHH - Last post by Roquen
I forgot to note in the pastebin code that brute force error checking isn't needed.  Say for polynomial methods you can compute where the error should be zero and verify that within a couple of ULPs of these points that the sign of the error does change.  Likewise compute where the error should be maximum and find the peaks.  Much faster and exact error measures.

EDIT: Oh and that code/output should be printing 'abs error' and not 'rel error'.

 on: 2016-10-22 15:25:41 
Started by KaiHH - Last post by CommanderKeith
Very interesting.

I made some small additions to Roquen's code to do a little micro-benchmark of the different Math.sin approximation methods referenced in this and other threads between zero and +Math.PI. Thanks to Roquen, Kai, theagentd and Riven for contributing their different fast sin methods.

Here are the micro-benchmark results:

Math.sin nanos per operation: 92.64692352
original nanos per operation: 15.45626018
horner nanos per operation: 12.8026165
range nanos per operation: 9.38279252
newk nanos per operation: 9.22229814
sin_9 nanos per operation: 7.35209479
sin_theagentd_lookup nanos per operation: 9.73315193
sinHalf nanos per operation: 7.10601857
sinFull nanos per operation: 6.19737146

I have little confidence in my own benchmarking abilities, but I did notice that these results are similar to Riven's given here ( Riven's sinHalf and sinFull methods take about 7% of the time needed for the Math.sin function in his test and in mine here.
Riven's SinHalf lookup table method is the fastest. Roquen's interesting sin_9 method is only marginally slower but I suspect it has far greater accuracy. The speed of Roquen's newk method given it's level of accuracy is pretty incredible.

I wanted to include the error table that Roquen showed and include Riven's methods too, but I did something wrong with measuring the error of Riven's look up tables since it was negative, so I won't post that error output until I have time to investigate.

Here is the code that I threw together to do these benchmarks. Apologies for the poor organisation. You may have to run it with the -Xmx6000M VM option to avoid running out of memory or else change the line "int numTestValues = 100000000;" to something smaller.

A big thank you to Roquen, Kai, theagentd and Riven for their code.

 on: 2016-10-22 12:06:28 
Started by SteveSmith - Last post by SteveSmith
Here's next project to retro-fit a game into multiplayer using GMC, this time MazEvolution written by KevinWorkman.  It's a maze game where each player gets the same maze, and the first to get to the exit wins.  And then everyone gets a new maze.

Full source is at

 on: 2016-10-22 09:48:24 
Started by steveyg90 - Last post by steveyg90

That is their health bar :-)


 on: 2016-10-22 09:22:39 
Started by Apo - Last post by Apo
I had to fix several small bugs and I polished some menus.

Now I am really happy with the result and I can say that is the first version that feels "complete" for me.

Download the game and have fun. Wink

Now I can really start to port the game to android

 on: 2016-10-22 07:14:02 
Started by jakethesnake - Last post by jakethesnake
Ok, I've changed something and reloaded the game. My suspicion is that  glGetInterger(GL_VERSION_MAYOR) was the culprit. Why? I don't know. I've asked the guys at opengl forums, but will have to wait for a reply. Hope it works!

Pages: 1 2 [3] 4 5 ... 10
CommanderKeith (28 views)
2016-10-22 15:22:05

Roquen (35 views)
2016-10-22 01:57:43

Roquen (47 views)
2016-10-17 12:09:13

Roquen (50 views)
2016-10-17 12:07:20

Icecore (65 views)
2016-10-15 19:51:22

theagentd (328 views)
2016-10-04 17:29:37

theagentd (330 views)
2016-10-04 17:27:27

xTheGamerPlayz (603 views)
2016-09-26 21:26:27

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

steveyg90 (880 views)
2016-09-15 20:41:23
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!