Hi !
Featured games (88)
games approved by the League of Dukes
Games in Showcase (681)
Games in Android Showcase (196)
games submitted by our members
Games in WIP (744)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: 1 ... 7 8 [9] 10
 on: 2016-06-27 22:55:02 
Started by KaiHH - Last post by KaiHH
tl;dr: If you want your Android app to run twice as fast, put all your application classes in the package "com.badlogic.gdx" (or subpackages).

While trying to evaluate how fit JOML currently is for running on Android devices, I did some benchmarking. Using a fresh Android Studio installation I used an Android 6.0.1 device and a simple application containing some benchmarking of JOML methods.
90 ns. for a 4x4 matrix multiplication, I though, was not bad.
I also tested the math classes of the latest libGDX version with the arm64-v8a shared library against it. The shared library loaded just fine via System.loadLibary("gdx") and the native Matrix4.mul() method successfully called the native function. But its performance was nowhere near that of the pretty standard textbook Java-only solution in JOML. LibGDX performed at arount 1370 ns. per invocation.
Next I tried to optimize libGDX's Matrix4.mul() method. First, this meant getting rid of the very slow JNI invocation, which internally also made calls to expensive VM runtime routines. The actual matrix multiplication arithmetic was the least of the runtime cost.
So, I translated JOML's matrix multiplication to float[] accesses that libGDX uses.

Then I ran the benchmark again.

Result: 47 ns. for the new Java-only libGDX Matrix4.mul() method.
I thought: Nice, so on Android arithmetic and memory-accesses on float[] elements is actually twice as fast compared to using primitive float fields like JOML does.
So, I stripped JOML's Matrix4f off everything except mul(), also used a float[16] array instead of the float fields, and finally used the same mul() method in JOML's class which I already used for libGDX's Matrix4.mul().
I expected that now JOML would perform exactly as fast as libGDX's new Java-only mul() method.

That was not the case. Still around 90 ns.

That could not be, I thought.
Whatever I tried, changing the access patterns of the float[16] array in the mul() method from row to column major. Nothing worked. JOML's Matrix4f class now literally looked exactly like my modified libGDX Matrix4 class. Something was fishy here.

Out of curiosity, I just refactored/moved JOML's Matrix4f class into the com.badlogic.gdx.math package, rebuilt everything, wiped the app completely from the device (as always after each test) and reran the benchmark.

48 ns.... wtf.

Moving libGDX's Matrix4 class into any other package other than a subpackage of com.badlogic.gdx also degraded the performance of its mul() method from 49 ns. to 90 ns.

Result: If you want your application to run fast on an Android 6.0.1, just put your application classes in the com.badlogic.gdx package.

...I'll look into Android's sources to see whether they actually have a codepath for classes in the 'com.badlogic.gdx' package...

 on: 2016-06-27 21:55:53 
Started by TritonDreyja - Last post by TritonDreyja
Nice videos but I think they can be shorter....

The videos aren't shorter because they aren't productions, they're raw footage that isn't trying to please anyone honestly. If they're done with the video they can exit it.

When I get to making a trailer, I'll focus more on length Smiley

EDIT: Basically saying that I'd prefer to spend more time on making the game than chopping the dev videos

 on: 2016-06-27 21:35:04 
Started by Hydroque - Last post by Hydroque
A black hole won't do, but a device that transports the light somewhere will be perfect. If light doesn't bounce off something in abundant quantities, then something is non-existant. I wonder what that would look like.





Whichever one is black. I haven't ever remembered Tongue

 on: 2016-06-27 19:58:38 
Started by TritonDreyja - Last post by ags1
Nice videos but I think they can be shorter....

 on: 2016-06-27 18:30:15 
Started by luckybit - Last post by FabulousFellini
Ok I foudn the answer by myself:
avoid using AffineTrasnform and rotate the coordinates before drawing and the rotate back, this is faster
g.rotate(theta, x, y);


When I do this in my game I think I also had to use translate() to translate the x and y positions so it rotated around the correct coordinates.

 on: 2016-06-27 17:57:37 
Started by luckybit - Last post by Riven
@KaiHH: text book case of premature optimisation Pointing

It makes the code less simple (simplicity is important) and won't have significant impact on performance.

 on: 2016-06-27 15:36:13 
Started by SteveSmith - Last post by SteveSmith
Cool, it's good to know that the game is now playable. Smiley  Preloading the models and graphics is next on my list.

 on: 2016-06-27 13:32:12 
Started by TritonDreyja - Last post by TritonDreyja
For video I either use windows movie maker or Sony Vegas.
For standalone sound editing I use Audacity but Vegas is pretty damn good for sound editing on it's own too.
All visuals are done in

 on: 2016-06-27 12:46:48 
Started by BurntPizza - Last post by theagentd
If you were shrewd you'd basically implement Unity's shader language... thereby having access to thousands of free and awesome shaders and a huge amount of amassed expertise...

Cas Smiley
Well, that's why I started that discussion thread about this BEFORE I started coding it... That being said, I'm not entirely sure it'd work considering I'm aiming for emulating Vulkan's descriptor sets in OpenGL.

@theagentd You should definitely consider emitting the #line directives which allow you to get correct line numbers while debugging shaders.
That's a good idea. Hmm, it's a bit difficult though considering that $importset could be multiple lines in a different FILE... Hmm, actually the set-file structs and uniform buffers are verified completely when they're parsed into memory before compiling shaders, so the chance that there's a problem in there which passes into a shader when imported is fairly low. It might just be good enough to have it show the $importset line as the problem in those rare cases.

 on: 2016-06-27 12:42:20 
Started by Hydroque - Last post by Ecumene
some sort of light eating device.

So a black hole? Or a just a dark surface xD

Pages: 1 ... 7 8 [9] 10
CopyableCougar4 (56 views)
2016-06-25 16:56:52

Hydroque (90 views)
2016-06-22 02:17:53

SwampChicken (91 views)
2016-06-20 13:22:57

SwampChicken (93 views)
2016-06-20 13:22:49

SwampChicken (86 views)
2016-06-20 13:22:26

Hydroque (132 views)
2016-06-15 08:22:50

Hydroque (125 views)
2016-06-13 06:40:55

DarkCart (242 views)
2016-05-29 02:30:33

Hydroque (207 views)
2016-05-26 14:45:46

Mac70 (190 views)
2016-05-24 21:16:33
Making a Dynamic Plugin System
by Hydroque
2016-06-25 00:13:25

Java Data structures
by BinaryMonkL
2016-06-13 21:22:09

Java Data structures
by BinaryMonkL
2016-06-13 21:20:42

FPS Camera Tutorial
by Hydroque
2016-05-22 05:40:58

Website offering 3D Models specifically for games for free
by vusman
2016-05-18 17:23:09

Website offering 3D Models specifically for games for free
by vusman
2016-05-09 08:50:56

Website offering 3D Models specifically for games for free
by vusman
2016-05-06 11:10:21

Website offering 3D Models specifically for games for free
by vusman
2016-04-29 12:56:17 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!