Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (710)
Games in Android Showcase (212)
games submitted by our members
Games in WIP (784)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 ... 6 7 [8] 9 10
 71 
 on: 2017-02-17 16:08:23 
Started by Optimo - Last post by Optimo
I'm nearing completion of a distribution-worthy copy of my game. I can install it on my machine (Windows 7) and another machine (Windows 10) and run it successfully, however, I appear to need read/write privileges.

The only way my game will run properly is if I run as administrator. If not, I can never save anything from the game. I would think I should be able to run the game and save things without running as administrator. Is that wrong? Can anyone advise on the appropriate way to tackle this issue? I can give more information if needed.

 72 
 on: 2017-02-17 15:06:35 
Started by Catharsis - Last post by kappa
The main thing would be if it supports the Hotspots JIT on ARM.

There is the OpenJDK 9 Android Port but seems like it only supports the Zero Interpreter on ARM. Not sure if the speed hit will make it unusable but might get round some of ART specific issues raised by Spasi. They also have a similar port to iOS.

 73 
 on: 2017-02-17 14:58:12 
Started by Catharsis - Last post by princec
Zulu basically runs atop Linux. It's armhf native code, which means with the tiniest bit of glue it should be invokable as a standard embedded JVM using JNI and the Android NDK. Presumably headless.

Cas Smiley

 74 
 on: 2017-02-17 14:47:23 
Started by Catharsis - Last post by kappa
Licensing wank :/
Ah right, looking at the pricing for the licence, it seems pretty expensive and not worth it for distributing games even if it did work on android.

Zulu Embedded does look nice, but can't find any information about it running on Android.

 75 
 on: 2017-02-17 12:31:40 
Started by Catharsis - Last post by princec
Licensing wank :/

Hence Zulu, which is nice GPL2 code and probably a lot less bother in general.

Cas Smiley

 76 
 on: 2017-02-17 12:20:45 
Started by Catharsis - Last post by kappa
What about OpenJDK (Zulu) on Android?

Cas Smiley
or what about Java SE Embedded, they already have ARM builds, if it can be made to run on Android devices, performance should be much better than ART's.

 77 
 on: 2017-02-17 11:27:58 
Started by James van Dalen - Last post by 65K
I use a custom made batch renderer for z-ordering:
https://github.com/voodoosoft/gameroots

It does not work with libgdx tiled maps now, but maybe it can give inspiration.

 78 
 on: 2017-02-17 11:19:19 
Started by Catharsis - Last post by princec
What about OpenJDK (Zulu) on Android?

Cas Smiley

 79 
 on: 2017-02-17 11:01:20 
Started by Catharsis - Last post by Spasi
Disclaimer: I'm an Android noob and it's entirely possible that I missed something important.

Here are my performance findings on Android. All tests were done on a Nexus 6P running Android N 7.1.1. The app was deployed as a signed APK, release variant, minimum platform 25. Metrics were printed with Android's Log and retrieved using logcat:

A general remark first. ART's JIT compilation is underwhelming. I'd say roughly equivalent to a Java client VM from a decade ago. Which I have a hard time believing given how experienced Google is with VMs and JITs (V8 is more than impressive). My first instinct while doing tests was that the app was always running in 100% interpreter mode. But no matter what I tried, it didn't get any better. I even left the app installed overnight, maybe the offline ART AOT would do some magic, but nothing improved. I really hope I'm missing something simple. The hardware feels pretty powerful and I don't think doing basic optimizations would waste that much battery.

- The first problem that affects LWJGL is that ART is not able to treat static final fields that are initialized at runtime as constants. This affects primitives (e.g. compiling away normal and debug mode checks that are behind static final booleans) and calls to interfaces with a single implementation instantiated at runtime (static final AnInterface FOO = new AnImpl()). Hotspot is easily able to de-virtualize such calls and fully inline them. This is critical for LWJGL performance in several cases.

- The above issue can be mitigated using ProGuard optimization passes. Which, again, takes us back a decade or more. It cannot even be done once for LWJGL, it needs to run on every build of the user's app, making builds horribly slow. The performance improvement is substantial though. ProGuard is able to inline and devirtualize a lot of code. The worse your JIT is, the more difference this makes.

- ART does not perform escape analysis. This I was expecting, but think it's worth mentioning. No EA means LWJGL users must be careful with allocations. The MemoryStack should not be used in tight loops, struct buffers should be accessed with the flyweight pattern, etc. This, again, means writing Java 1.4 era code, preallocating and reusing buffer instances etc.

- LWJGL depends on Unsafe and intrinsics for many things. For Vulkan in particular, that is an API heavy on structs, LWJGL uses Unsafe to access all struct members. The good news is that Android 7 supports the full Java 8 Unsafe API and has proper intrinsics. Measuring simple reads/writes produces appropriate results for the underlying hardware. The first problem is inlining: properly encapsulating Unsafe sacrifices a lot of performance without ProGuard. The second problem is a bug on Aarch64: it's impossible to access > 32bit memory addresses with Unsafe, the address is getting masked out at 32bits. This won't affect most app allocations, but all libraries are mapped to a >32bit address and any memory provided by them will be in that range.

- Android has another internal API similar to Unsafe, libcore.io.Memory. This class is also intrinsified and doesn't suffer from the same bug. Unfortunately, it's about 4x slower than Unsafe in my tests.

- The java.nio buffer implementation on Android is bad. Too many allocations, too much overhead, they use libcore.io.Memory instead of Unsafe. Accessing anything via a buffer is 10x slower than the equivalent Unsafe access.

To sum up, it feels like Java on Android is meant to be used for client UI code only. Anything performance sensitive should be moved to JNI and native code. Making Java+LWJGL a decent alternative will take some work and I'm not sure if it can be done within the official repo or better moved to a fork. E.g. one solution to the last point is writing a custom buffer API, which means the entire LWJGL API needs to change. Actually, getting rid of NIO was something that I briefly consider doing when I started lwjgl3 (it would benefit desktop apps as well), but decided it was more important to keep compatibility with the lwjgl2 bindings.

 80 
 on: 2017-02-17 10:31:59 
Started by James van Dalen - Last post by CoDi^R
MapObjects are rendered in the order they are added. In my opinion, libGDX' existing tile map renderers are, out of the box, simply unusable if objects need to consider any order of rendering.

My advise would be: override TiledMapRenderer.renderObjects(). Keep the MapObject array, or use some sensible (spatial) data structure to store all objects on the map. Each frame, iterate objects, perform view culling, extract the objects visible on the screen to a second array. Sort this array by object.position.y. Render visible objects top to bottom.

Pages: 1 ... 6 7 [8] 9 10
 
numerical (3 views)
2017-02-21 07:32:16

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

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

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

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

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

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

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

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

0AndrewShepherd0 (2303 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!