Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (739)
Games in Android Showcase (224)
games submitted by our members
Games in WIP (820)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1] 2 3 ... 36
1  Java Game APIs & Engines / Engines, Libraries and Tools / LWJGL 3.1.3 on: 2017-09-22 00:49:20
LWJGL 3.1.3 has been released!

Release notes
2  Discussions / General Discussions / Posting to not-so-old topics on: 2017-08-01 11:10:57
I have a request for @Riven: could we please relax the rule for not posting to old topics? I'm referring to the:

You cannot reply to this message, because it is very, very old.

lock that is applied to topics that haven't had a reply recently.

As an example, I wanted to contribute useful information to two topics today and both were locked. The first with a last reply on 27 Oct 2016 and the second on 17 Jan 2017. I don't think either topic is that old or long forgotten. Adding my reply to the existing topics is preferable to creating a new topic that references the old. Especially if the reply is a minor contribution to the discussion.

I'm not sure what the current time limit is, but can we maybe increase it to at least a year?
3  Discussions / General Discussions / Re: JGO Twitter List on: 2017-07-26 14:04:34
@LWJGL (managed by kappa, I mostly post about new releases)
4  Game Development / Shared Code / Re: Faster Than Light JSON Parser on: 2017-07-06 08:32:17
I'd also decide whether the class is going to be stateful, or not.
At the moment you're storing pos as state, but passing the byte[] & ParseListener around as parameters.

Go with one, or the other; doing both looks messy.
Given the aim is minimal weight & dependencies, I'd be inclined to make it stateless so everything can be static.
Either way, I doubt it'd have any noticeable impact upon performance.

This mix of functional/stateless parameter passing and internal state is by design. Because the JVM is the leakiest abstraction in modern software development. Possibly only rivaled by SQL query optimizers.

1. The problem starts with bytecode size. More bytecode in a method == harder for the JVM to optimize.
2. Once you start dealing with bytecode size, you need to extract repeating code and corner cases to other methods.
3. It all ends when you need to return two values from a method. You can't do that without state in Java.

There's a major difference between input/listener and pos. The former is external state, the latter private/internal. The JVM sees that it has full control over pos and is able to perform the full range of optimizations. It's also likely that the entire parser instance can be eliminated via escape analysis.
5  Discussions / Miscellaneous Topics / Re: Passion Projects and Life: Spreading Yourself Too Thin? on: 2017-06-30 22:38:37
I'm in a similar situation with work, family/kids, side-projects and LWJGL competing for my attention. Assigning days of the week (or hours of the day), to specific projects has been inefficient and does not work for me at all. I need long stretches of focusing on a task, for days or weeks in a row, to make meaningful progress. It's usually a few days of research without much coding, or just a little bit of prototyping, then a few more days of actual coding, then several days of validation and polishing. I'm not a good multi-tasker and switching to other projects, even for a day, breaks the flow.

So, another approach you might want to try is: schedule your work in batches. It can be anything from a week to 3 months, where all your free time goes to a single project only. It doesn't even have to be actual work. This week may be LWJGL week, next week might be family/friends week, the week after workout/fitness/personal-time week. Do one thing with your full attention and do it right.

A few more tips:

- +1 for having a reasonably strict schedule for the kids, especially bed time. It's good for them and it's good for you and your spouse.
- Make sure you sleep enough. Every person is different wrt how much sleep they need, but modern life usually means you're not getting enough. More sleep means less time for projects, but it's the quality that matters, not the quantity.
- If you're self-employed and can afford it, add your work to the project rotation. Putting the job on hold for a week may not be the end of the world and it can free up precious time for something a lot more satisfying. I've done this several times while working on LWJGL.
6  Discussions / General Discussions / Re: JCrete? on: 2017-06-29 13:12:07
I was there last year. It's unlike any other (un)conference you may have been to and definitely worth the trip.

The mornings are tightly packed with 5-6 sessions going on at once. Lots of diversity and many interesting topics to choose from (or host yourself). Then you get to visit some of the most beautiful locations in Greece and have amazing food. The most interesting discussions happen in small groups, while driving to a destination, or relaxed on a beach. I was actually having useful discussions up to 2' before boarding my return flight.

No matter what, don't miss the trip to Balos!
7  Discussions / General Discussions / Re: Compressing chunk of tile data? on: 2017-06-28 07:16:23
On the topic of compression, but not necessarily applicable to this use-case, I've been meaning to add a few different implementations to LWJGL. Specifically, I'm interested in compression algorithms that make unusual space/speed trade-offs. For example, Zstandard and LZFSE. Suggestions for other algorithms are welcome. I'm eagerly looking for an rANS-based implementation, like cbloom's Kraken, that is open source.
8  Game Development / Newbie & Debugging Questions / Re: STB Font library with chinese characters on: 2017-06-21 19:34:47
But since it isn't a letter-based system there are THOUSANDS of characters to choose from; i.e. how can I fit them all onto a texture?

Storing every chinese character is generally a waste of memory. The usual approach is to have a caching scheme, i.e. a texture + associated stb packing that gets updated on the fly as new glyphs are required.

The chinese characters stored in unicode are ALL OVER THE PLACE. Which is annoying because with STB you just declare a start and an end, and it fills the middle in with letters. But I need to define a lot of ranges spanning thousands of numbers to store them. I am not quite sure what to do.

Have you tried stbtt_PackFontRanges?
9  Java Game APIs & Engines / Engines, Libraries and Tools / LWJGL 3.1.2 on: 2017-05-15 17:28:18
LWJGL 3.1.2 has been released!

Release notes
10  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3FX - A sneak peek on: 2017-05-04 15:43:36
I would recommend JFXGL, for now at least. Jeff has made good progress.
11  Game Development / Networking & Multiplayer / Re: Best - and currently active - networking lib? on: 2017-04-30 20:08:44
Aeron for IPC and server/server communication, Netty for client/server communication. Also, Vert.x if you're looking for a higher level solution (based on Netty).

Aeron is designed for extremely low latency and destroys every other library in that metric. Many frameworks have started adopting it as their backend. Random examples: Akka Arterty, Onyx, Deeplearning4j. It is highly tunable and has a simple and very focused API. But being a pure transport layer, it doesn't provide any higher level features. Yet. There are plans for more features (by the same creators), either built-in or in new libraries that work closely with Aeron. The next Aeron release is getting persistence and there's Aeron#211 that will make it great for games. Aeron has native support for SBE, but you can use any serialization framework that works on NIO buffers.
12  Discussions / General Discussions / Re: Project Panama - the JNI Replacement (slidedeck) on: 2017-04-05 07:55:32
I don't care about the API at all. I will use it even if it's 10 times harder to use than JNI, as long as it eliminates the performance overhead. We can hide the ugliness in libraries like LWJGL.

My real worries:

1) No matter how good Panama is, there is a strong dependency to Project Valhalla and value types. If that gets delayed (and it very much looks like it will), Panama won't see the light of day, or will have crippled performance. Panama is simple compared to value types. The latter requires serious research and engineering work and there are a lot of open questions. Afaik their priority is on the Java side of things and haven't even touched the fixed/native layout issues yet. Which is expected tbh, there are very few people inside Oracle that actually care about native interop.

2) I doubt we'll be able to use the full power of Panama in user code (custom intrinsics etc). My expectation is that it will be highly restricted for JVM internals (security concerns, Jigsaw bullshit, etc) and we'll again be stuck waiting for Oracle to release the right set of public APIs. What I would prefer instead is that Oracle lays the JVM foundations and the community builds everything else.

3) I'm afraid it's going to be too late for Panama when it is released. Panama, AOT, value types, it will all be great, but when? Even Jigsaw hasn't been released yet (and most people I know hate it already). Meanwhile, projects like Scala Native and Kotlin Native will get the job done.
13  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Nuklear "nk_begin" method causing random SIGBUS after a while. on: 2017-03-19 14:59:08
Change the Font class to hold a reference to the font data buffer (the one loaded with ioResourceToByteBuffer and passed to stbtt_InitFont). The documentation for stb_truetype briefly mentions this:

The system uses the raw data found in the .ttf file without changing it and without building auxiliary data structures. This is a bit inefficient on little-endian systems (the data is big-endian), but assuming you're caching the bitmaps or glyph shapes this shouldn't be a big deal.
14  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3FX - A sneak peek on: 2017-03-11 08:36:56
There's now an alternative implementation available, JFXGL. It was created by Jeff Martin. Compared to ours:


- It uses GLFW for context management and as the windowing system.
- You have full control of the render loop (the fixed 1ms per frame overhead mentioned above does not apply).
- Doesn't have the -Djava.ext.dirs issue.
- You can use it right now.


- It handles JavaFX graphics only, other features are not supported (pickers, popups, etc.).

We've shared our code with Jeff and his code is obviously also available, so both approaches will likely improve soon.
15  Game Development / Performance Tuning / Re: ArrayList$Itr and Escape Analysis on: 2017-03-06 14:06:42
Stop wasting your time with traditional profilers. Treat them like antivirus software; they lie all the time and they are not made to help you. Yes, they're that bad.

Can somebody settle this once and for all...

JVisualVM reports that I'm generating megabytes worth of iterators every frame. This is bothering because there are other things I'd rather have room to create megabytes of every frame. However I've heard anecdotally that it is only the presence of JVisualVM's profiling that actually causes these iterators to be picked up because it turns off the escape analysis feature in the JVM.

This is true, merely the presence of an attached profiler will disable escape analysis and many other optimizations. The simplest way to identify whether EA is kicking in or not is to use JITWatch. It's my favorite performance analysis tool these days. It doesn't require a debug VM or the disasm DLL (though disasm is highly recommended for low-level tuning). Here's a demo of the EA reporting:

<a href=";hl=en_US&amp;start=" target="_blank">;hl=en_US&amp;start=</a>

A debug VM will tell you why a particular allocation has not been eliminated. This is useful, but not critical for performance tuning, assuming you're familiar with the basics. Once you identify a problematic allocation, it takes a bit of refactoring to solve the problem and it's rarely an unfixable situation. Like everything else in Java, bytecode size, call depth and associated inlining decisions play the most critical role.
16  Game Development / Newbie & Debugging Questions / Re: [LWJGL3/OpenGL] New window mode versus VAO on: 2017-02-27 08:13:46
What I meant was knowing where to find, read, and learn the information you told me about changes. Is that in the build configurator?

Any changes that affect users are mentioned in the release notes. See the 3.1.1 notes for this particular issue.

Should I just be using all the files given to me in those configurator zips? I got 21 jars from my standard set in the configurator, but I only used 7 before. I didn't seem to need them all, but perhaps I'm wrong?

After you select the bindings you need and download the bundle, you're supposed to use all classes jars and natives jars for the platform you're running on. It's very unlikely that you're going to need all bindings. The configurator remembers your previous selection for a given browser, or you can use the Save/Load functionality when moving between browsers/computers.
17  Java Game APIs & Engines / Engines, Libraries and Tools / Re: lwjgl3 compile-native \windows\build.xml:89: apply returned: 2 on: 2017-02-26 10:57:10
I can't find the error in the log. Could you please try "ant clean compile-templates compile-native"? If that doesn't work, post the log again but without verbose Ant output.

Btw, I will update the Nuklear bindings soon anyway.
18  Game Development / Newbie & Debugging Questions / Re: [LWJGL3/OpenGL] New window mode versus VAO on: 2017-02-26 07:15:39
STB has switched at least one thing:  
stbtt_PackBegin(pc, bitmap, BITMAP_W, BITMAP_H, 0, 1, null);

That now wants a long where it wanted a null.

This was a bugfix. Pass NULL (0L) instead of null.

I also have errors from GLFW. It seems to be related to this window creation stuff. This happens in the window creation method I have.
Exception in thread "main" java.lang.UnsatisfiedLinkError: Failed to locate library: lwjgl_opengl.dll

Starting with LWJGL 3.1.1, the OpenGL and OpenGL ES bindings require a JNI shared library to work. You need to include lwjgl-opengl-natives-<platform>.jar in your project.

I don't know how to best stay abreast of what may be changing in these support libraries such that I can understand what is happening here when I replace them with new stuff. Don't think I'm missing a library, had 7 before, have 7 now, all the same names.

The simplest solution is to always use the LWJGL build configurator when updating to a new version.
19  Java Game APIs & Engines / OpenGL Development / Re: ByteBuffers and Memory on: 2017-02-24 08:10:28
First of all, please read the Memory FAQ.

At the end of this function, the LWJGL memory util class is used to free the image data from memory, which is what causes confusion. Why does this Buffer's memory need to be freed manually?

It needs to be freed manually because its an allocation made by the native library, not by the JVM. More specifically, the only buffer instances that are automatically garbage collected are instances allocated via
. Most LWJGL bindings create resources that similarly need to be cleaned up manually.

Also, the above code should not be calling memFree(). The stb_image library has a dedicated function for freeing images, stbi_image_free(). It happens to work correctly because stbi_image_free() is a simple call to free() and the stb bindings are configured to use the same memory allocator as LWJGL.

Should I also be doing this with the Buffer objects being created in my first code sample?

No. It entirely depends on how the buffer object has been allocated (see the FAQ above).

Most buffers returned by API calls are allocated externally and should not be freed by the user. They are usually freed by the library, automatically or with another API call. When that's not the case, there's usually documentation that mentions it.

Also, why use the MemoryStack class in the try statement? What would be the consequences of creating standard IntBuffers without the aid of this utility?

The MemoryStack class is a performance optimization. The FAQ has more details. There's no actual allocation made, so it's much faster for short lived buffers. The drawback is that you have limited stack space (configured statically with Configuration.STACK_SIZE, defaults to 64kb) and the allocation is not available after the stack has been popped (done automatically at the end of the try-with-resources block).
20  Game Development / Newbie & Debugging Questions / Re: LWJGL 3.1 + NIFTY GUI or other GUI Library on: 2017-02-22 07:56:30
LWJGL does not have a complete, integrated solution that you could label a Swing/JavaFX replacement. What it does have is bindings to libraries that solve parts of the equation:

- Windowing system and input: GLFW
- Dialogs: nativefiledialogs (nfd) or tinyfd
- UI components: nuklear
- UI layout: Yoga (in 3.1.2 snapshots)
- Vector graphics (canvas/Java2D-style): NanoVG
- Image IO: stb_image
- Font rendering: stb_truetype

It's obviously quite a bit of work to learn and integrate some or all of the above, but it's entirely possible. They are all lightweight solutions and there are no interop issues with OpenGL.
21  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3 and Android Redux on: 2017-02-20 16:21:29
The example Android Studio project is now available at LWJGL/android-test. The README includes build instructions.

For those that simply want to try it out, you can find arm64-v8a binaries here (warning: unsigned, built on my workstation):

22  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3 and Android Redux on: 2017-02-17 11:01:20
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, 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 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.
23  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3 and Android Redux on: 2017-02-14 19:09:48
The amazing part of LWJGL being on Android is that now there is an option for low level graphics that is separate of the SDK / firmware conundrum of how previous SDK graphics APIs are managed. IE As the Vulkan spec continues to be modified we don't have to wait for platform 25, 26 ... X to get these new features enabled like previous Java SDK efforts being locked to the firmware. Granted there are still firmware locked drivers, but if it's an advancement of the Vulkan API itself that isn't dependent on driver updates then these new features will always be available at platform 24.

Yes, totally agree. But it would be nice if this decoupling benefit could be extended to developers that target OpenGL ES and earlier API levels.

However this is not an issue as since day 1 with GLES on Android 1.0 onward one simply locks the orientation for game / graphics apps. Very few intense graphics apps don't lock the orientation and and leave the orientation restart process enabled.

Good point.

I can perhaps see the difficulty of enabling various debug layers of Vulkan and getting all the necessary output perhaps if it's not being logged per se, but that is a separate issue.

That's actually very easy; the NDK includes precompiled layer libraries that you can simply drop in your project. Vulkan validation works just fine.

I don't think there are any more Java / graphics champions involved to a meaningful degree on the Android team. If there is collaboration though it will be embraced warmly!

It doesn't have to be Java developers. Anyone that writes a Vulkan app, either in Java or C, will face the same issues.

Actually, I couldn't find a Vulkan sample in the official repo that handles surface destruction properly. I could just as easily call this "not my problem" and actually I don't plan adding VKSurfaceView to lwjgl3. But it'd be very nice if we could provide a sample project that handles some of the complexity and exposes an API that's familiar to anyone that has used GLSurfaceView.

If the repo can be created sooner than later along with a wiki entry where instructions will go then I can proceed with the mini-flyers.
I'll also gladly contribute the screen shot walk through of setting things up similar to what I did for my GL demos /  source code setup.

Will try to get it ready asap.
24  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3 and Android Redux on: 2017-02-13 09:38:43
Hey Catharsis,

I'll work on this a bit more, mainly to clean up the code. There are two issues:

We currently require Android N and platform 24+. Which corresponds to too low a percentage of Android users. Making it work on earlier versions should be possible, but I have neither the energy nor the incentive to do it myself. Not sure if it's even worth doing, given the performance characteristics (I'll write another post with the details).

There's also the issue of better handling buffer/device lost events, which are fairly common with Vulkan on Android. You may notice it in the above video, when the orientation changes, there's a full destroy and recreation of the whole thing. Moving out of the app and back in again also requires a "soft-reset", but I think I've handled that one sufficiently.

The issue is complicated by the fact that I've written VKSurfaceView similarly to GLSurfaceView; everything runs on a separate thread and the UI events arrive asynchronously. If you're familiar with GLSurfaceView's implementation... it's not trivial and I don't have the necessary experience (or time) to make it robust. If I fail, I'll probably make another version that runs on the UI thread and maybe Android engineers can help with properly fixing the concurrent version.

Once that's done, I'll update the lwjgl3 android branch and will create another repo with an Android Studio sample project and some instructions.

Other than that, I won't have time for much else. I'm fairly busy at work and I'm also becoming a father for the 2nd time (today or tomorrow). I'm also not really comfortable with announcing what is essentially a work-in-progress. And it's not like LWJGL needs that much branding/marketing. People that need to go low-level can easily find it, there aren't many options out there. I certainly don't want to give the illusion that it's a library for the average developer. Especially wrt Vulkan.

I'll pm you links to LWJGL's logo in various formats.
25  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Ongoing project: Type-Safe access to ByteBuffers on: 2017-02-11 15:00:00
I've reviewed existing approaches related to this topic.

Very interesting, some answers and corrections:

Offsets or member variables are stored in static final members of the struct class, which will be most likely treated as constants by the JIT compiler and as such inserted in the code (text cache not data cache) (TODO: proof)

This is correct and can be easily proven using -XX:+PrintAssembly. The work done by Layout in the static init blocks has been designed to achieve exactly this.

An associated class derived from StructBuffer is used to attach a byte buffer to instances of Struct classes. Instances of Struct classes are backed by a buffer, always.

This is all wrong:

- The ByteBuffer container field in both Struct and StructBuffer is optional. In fact, when writing "idiomatic" LWJGL 3 code, it almost always goes unused and is quite often eliminated entirely via escape analysis (nothing is written to it and no code reads from it).

- A StructBuffer is a packed array of struct values, there are no instances of Struct classes. One option is to access the array data with the flyweight pattern. The other option is to retrieve Struct class instances as you iterate over the array but, again due to how one writes LWJGL 3 code, those allocations are eliminated via escape analysis. You can use a tool like JITWatch to verify this.

- There are multiple ways to allocate either a Struct or a StructBuffer: a) backed by a ByteBuffer (which itself can be allocated in multiple ways) b) using malloc/calloc/etc c) using the MemoryStack. The choice depends on the amount of code the user is willing to write and the amount of memory management they afford to worry about. Only the first option utilizes the container field, for obvious GC reasons.

It very much looks like this is derived work from the author of LibStruct (see below) but was discarded in LWJGL 3 for yet unknown reason.

3 reasons:

a) LibStruct does a great job and should interoperate just fine with LWJGL 3.
b) LWJGL 3 does bindings only, improving user code is not one of its goals. We have specific struct types that must be supported and static code generation is the simplest solution.
c) Project Panama is also going to expose struct fields using methods (unless they do something with value types, but I doubt it). When LWJGL (4?) gets ported to Panama, hopefully existing code won't require significant changes.
26  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3 and Android Redux on: 2017-02-10 22:48:48
Hello VKSurfaceView!

<a href=";hl=en_US&amp;start=" target="_blank">;hl=en_US&amp;start=</a>
27  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3 and Android Redux on: 2017-02-05 19:23:55
Everything is available in the android branch. Please note that we're force pushing regularly to clean up the commit history and whenever we sync with master.

If you clone the branch and run "ant compile-templates arr", it should produce a bin/android/lwjgl.aar file. Drop it in an Android project and it should just work. That's all there is to it right now. Next steps are: adding Android extensions that might be missing (in EGL, GLES and Vulkan), testing Vulkan, adding non-JNI natives (OpenAL-Soft, jemalloc, etc) and doing performance testing/tuning.
28  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3 and Android Redux on: 2017-02-03 18:25:11
The glxgears demo, ported to GLES 3 with lwjgl3 and JOML, running on...

Nexus 6P:

<a href=";hl=en_US&amp;start=" target="_blank">;hl=en_US&amp;start=</a>

Nvidia Shield:

<a href=";hl=en_US&amp;start=" target="_blank">;hl=en_US&amp;start=</a>
29  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3FX - A sneak peek on: 2017-01-31 14:56:07
We have decided to prioritize the Android/ARM builds over this. Other than limited time, this project has several difficulties:

- Needs quite a bit of work to be production ready.
- We're not sure if it's worth doing lots of unpaid work for something that Oracle ought to support out of the box and if there will actually be people that want to use an unofficial backend.
- We're not sure about licensing issues and if Oracle is going to come after us. Which is why the code isn't public yet.

Anyway, current status:

It's still at a proof-of-concept stage but works very well. As you could probably tell by the measurements above, it's a pure GPU solution with no CPU copies. In fact, there are not even GPU copies, other than the compositing JavaFX does anyway. We render directly to the texture backing the GL viewport, without disrupting JavaFX's context state. Issues and pending work:

- It currently works on Windows and Linux. We must add support for CGL and EGL + real OpenGL ES. The plan is to add a cross-platform API for GL context management to lwjgl3. What ContextAttribs did in lwjgl2, but probably closer to GLFW's hint-based API and implementation.
- We'll need some kind of API that configures the FBO associated with the GL viewport.
- Overriding the default Prism implementation requires the backend code to be loaded via -Djava.ext.dirs. Won't be friendly to novice users.
- Prism is not documented and does not have a stable API. This means that new JDK versions will likely break our implementation. We'll need multiple versions and have maintenance overhead. The current implementation is compatible with JavaFX 8 only. Java 9 has also dropped -Djava.ext.dirs, we'll probably need module workarounds to run there.
- Long-term: Prism looks like it's been hacked until it worked. It's really quite a bad code base to work in. We'd really like to do a cleanup where possible. Being able to do everything in Java will help a lot.
- Longer-term: It'd be fun to add a Vulkan backend for improved performance.
30  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3 and Android Redux on: 2017-01-31 14:15:49
@KaiHH did the first successful build of lwjgl-core + bindings last night. We now have an android branch and I plan to start working on it asap. One dependency has also been built on Travis-CI.

The good news is that it's looking easier than we thought. The not-so-good news is that we're talking about Android builds. The Android NDK is supported out of the box on Travis-CI, but afaict we'll have to configure a cross-compile toolchain manually for generic Linux-ARM builds. Any help on that front would be much appreciated.
Pages: [1] 2 3 ... 36
Ecumene (55 views)
2017-09-30 02:57:34

theagentd (78 views)
2017-09-26 18:23:31

cybrmynd (186 views)
2017-08-02 12:28:51

cybrmynd (184 views)
2017-08-02 12:19:43

cybrmynd (191 views)
2017-08-02 12:18:09

Sralse (201 views)
2017-07-25 17:13:48

Archive (757 views)
2017-04-27 17:45:51

buddyBro (891 views)
2017-04-05 03:38:00

CopyableCougar4 (1440 views)
2017-03-24 15:39:42

theagentd (1323 views)
2017-03-24 15:32:08
List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05

SF/X Libraries
by SkyAphid
2017-03-02 06:38:56

SF/X Libraries
by SkyAphid
2017-03-02 06:38:32

SF/X Libraries
by SkyAphid
2017-03-02 06:38:05

SF/X Libraries
by SkyAphid
2017-03-02 06:37:51 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!