Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (714)
Games in Android Showcase (214)
games submitted by our members
Games in WIP (787)
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 / 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:

Quote
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.
2  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:

Pros

- 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.

Cons

- 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.
3  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="http://www.youtube.com/v/LK1Ain1JDlQ?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/LK1Ain1JDlQ?version=3&amp;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.
4  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.
5  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.
6  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.
7  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
ByteBuffer.allocateDirect
. 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).
8  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.
9  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):

gears-debug.apk
hellovulkan-debug.apk
lwjgl.aar
10  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, 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.
11  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.
12  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.
13  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.

http://homac.cakelab.org/projects/org.cakelab.nio/existing.html

Very interesting, some answers and corrections:

Quote
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.

Quote
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.

Quote
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.
14  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3 and Android Redux on: 2017-02-10 22:48:48
Hello VKSurfaceView!

<a href="http://www.youtube.com/v/XAGi07iSbe8?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/XAGi07iSbe8?version=3&amp;hl=en_US&amp;start=</a>
15  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.
16  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="http://www.youtube.com/v/wC3LbPgtVY0?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/wC3LbPgtVY0?version=3&amp;hl=en_US&amp;start=</a>

Nvidia Shield:

<a href="http://www.youtube.com/v/3v9jpelfX6g?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/3v9jpelfX6g?version=3&amp;hl=en_US&amp;start=</a>
17  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.
18  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.
19  Java Game APIs & Engines / Engines, Libraries and Tools / LWJGL3FX - A sneak peek on: 2017-01-21 01:32:14
This is an effort by @KaiHH and me to integrate LWJGL 3 with JavaFX.

Some of you may remember LWJGL-FX, which was a proof of concept to simply show how nice it would be to render OpenGL graphics within JavaFX. Technically it wasn't doing anything worthwhile, it was just trying to use the existing public JavaFX APIs in an efficient manner. Despite my efforts, the end-result was very inefficient in terms of both memory and CPU usage.

Some time before LWJGL 3.0.0 was released, I had written a Prism backend (the part of JavaFX that does the actual rendering) using LWJGL 3. It worked, but other stuff got in the way and I never had time to do anything with it. A few days ago I recruited KaiHH to help me do it right this time. The old code was ported to the latest LWJGL releases and we figured out a good approach for the integration. This is the first result.

The images below are screenshots of this JavaFX sample, modified so that the classic Gears OpenGL demo is rendered behind the main content. The drop shadow effect is enabled on the JavaFX image. The window is maximized in a 1920x1200 monitor. Minus the menu and taskbar, the OpenGL view is slightly larger than 1080p. The background color animates, that's why it isn't the same in all screenshots. Open the images in a new-tab for the full size.

V-sync enabled, 60 fps, 3.9% CPU



The following were launched with -Djavafx.animation.fullspeed=true. Despite the name, there's a hard cap at 1000Hz for the animation pulses. This means that there's a fixed overhead of 1ms and we cannot go lower than that (i.e. cannot go higher than 1000fps).

V-sync disabled, 1.0 + 0.41ms per frame



V-sync disabled, HUD disabled, 1.0 + 0.01ms per frame

20  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3 and Android Redux on: 2017-01-20 22:09:28
Don't let input get in the way of development for now - produce a "dud" backend for it that simply fails to connect any devices successfully or something. Then at least I could get on with testing EGL.

Alright, will let you know once we have working ARM builds.

@spasi would the work I did on android and arm build before help here?

Yes, your config here should be a good start. Have you tried doing the same for any other library? I guess the hardest would be GLFW and OpenAL-Soft. They have plenty of dependencies other than the basic C libraries, which may or may not be readily available in a cross-compile toolchain.
21  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3 and Android Redux on: 2017-01-20 11:47:21
If you had it working on Pi... would it be "headless"?

Afaict, there are about 5 functions that must be called to launch EGL in "headless" mode. This is a trivial issue, these functions can be added to LWJGL in an afternoon. Or even called via dyncall without bindings.

The main problem is, as I said in the LWJGL forums, handling input without X. Keyboard, mouse, controllers, touch, we'll need something to handle all that. We cannot use GLFW, it supports 3 backends (X11, Wayland, Mir) and even though Wayland is supposed to be a lightweight solution (and works on RPi afaik), I think you'd want to avoid that too. So we'll have to go low-level. This is probably not that big of a deal, I mean, the main problem is identifying the APIs we need bindings for. Once we know how it's done, adding the bindings to LWJGL is going to be quick.

Which brings me to; I don't own an RPi and I don't know when/if I'll have time to do the above research. The easiest thing for me would be to get a list of APIs to add to LWJGL, from someone that knows what's necessary.
22  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3 and Android Redux on: 2017-01-19 22:06:44
Err, no OpenGL module in that list?

I'm strictly talking about non-JNI code that needs to be built for Android. JNI code, especially in LWJGL, is trivial and can be easily built on any toolchain. Also, APIs like Vulkan have no dedicated JNI code in LWJGL; dlopen, dlsym and you're good to go.

Just a quick note... most RPis out there will be running a 32-bit Linux OS rather than a 64-bit one that the chips are able to run. Not quite sure what the implications are but I bet that means having to support a 32bit ABI for ARM.

Yes, noticed that in the quick look I had. There seems to be ongoing effort to support 64bit, but who knows when that'll be ready (RPi 3 only too). In any case, it is my understanding that Android binaries require a special toolchain that is not Linux compatible (correct me if I'm wrong please), so we'll need a different ABI for RPis anyway.
23  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3 and Android Redux on: 2017-01-19 20:17:10
Hey @Catharsis, here's a plan for what needs to be done:

1) Decide which ABI(s) we're going to support. I'd be happy with arm64-v8a and nothing else.
2) Cross-compile LWJGL natives to the target ABI(s).

This is the part I need more help with. The LWJGL build process uses Travis CI for the Linux binaries. The source code for each project is under the LWJGL-CI account on GitHub. Each repository has two branches (one for Linux x64 and one for macOS) with an appropriate .travis.yml script that performs the corresponding build. We'll need the same thing for Android (and Raspberry Pi builds later). Basically, a new branch must be created (e.g. master-android-arm64-v8a), which is exactly the same as the other two, except the contents of .travis.yml. The difficulty lies in getting Travis CI to cross-compile for our target ABI.

3) Change LWJGL so that it supports the new platform/ABI. (should be easy)
4) Test, fix, test, etc. (someone with Android dev experience: please contribute any information you might have!)
5) Deploy the new platform/ABI to Maven and the LWJGL site. (should be easy)

If this gets hard, we can focus on some LWJGL modules and skip the rest. At a minimum, we'll need:

- LWJGL core
- dyncall (the core depends on it)
- GLFW

Good to have:

- jemalloc
- OpenAL for audio

When building the core, unnecessary bindings can be disabled in /config/build-bindings.xml.

We should probably move this discussion to GitHub or the LWJGL on Slack.
24  Game Development / Newbie & Debugging Questions / Re: LWJGL glGenVertexArrays jvm crash on: 2017-01-12 14:10:28
on some systems

Sounds like you might be calling glGenVertexArrays without checking if OpenGL 3.0 is available.
25  Java Game APIs & Engines / Engines, Libraries and Tools / LWJGL 3.1.1 on: 2016-12-27 19:49:44
LWJGL 3.1.1 has been released!

Release notes
Download
26  Game Development / Newbie & Debugging Questions / Re: LWJGL2 using LWJGL3's image loading on: 2016-12-21 12:18:38
The class incompatibilities can be solved by using a separate ClassLoader for LWJGL 3.

The native library name is not a problem either. You can rename it in the jar and use -Dorg.lwjgl.libname to specify the new name.

But then you get into some wankery with System.loadLibrary that I didn't have the patience to solve. For something like this, I'd use a separate JVM and an IPC solution to transfer data.
27  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3 and Android Redux on: 2016-12-20 20:38:28
Hey, quick reply (I had a minor operation today and am in a bit of pain atm):

I still haven't done any work on ARM/Android, but I have new information to share. @KaiHH has been working hard to make JOML perform nicely on Android (it's being used in Samsung's GearVR SDK) and I asked him to do a bit of testing for me. Turns out that, indeed, starting with Android N and the OpenJDK-based SDK, the current LWJGL design might be viable. Unsafe seems to be a lot faster at least.

I've got tons of devices with each generation of GPU and would be glad to test, refine, and work on any necessary optimizations.

That's great, will be very helpful.

So since I only have a cursory overview of LWJGL3 from poking through the source code I'd be curious to hear what you think will be the pain points? How are you handling JDK9 removal of sun.misc.Unsafe?

LWJGL 3 depends on Unsafe and escape analysis for extreme performance. Workarounds may be possible, but at the expense of clean code.

JDK 9 does not remove sun.misc.Unsafe and it's available to all modules (there's a new, much more powerful, Unsafe in 9 that is available only inside the JDK). As of this commit LWJGL 3 also works on JDK 9 b148+, which introduced a lot of significant changes to the module system.
28  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL uses wrong graphics card on: 2016-12-12 21:23:03
The AMD equivalent:

1  
int AmdPowerXpressRequestHighPerformance = 1;
29  Discussions / General Discussions / Re: Animation Model format - LWJGL 3.1 on: 2016-12-06 18:36:49
1. What can be considered the best format to work with animations using opengl?

There are many formats that can do the job. My personal favorite was dotXSI, but Autodesk bought and killed Softimage 3D, so...

The hardest part is setting up a decent pipeline between your artists and your engine. The actual format used to get data out of your DCC app is not very important.

2. There is any Java library to work / load this models?

LWJGL recently added assimp bindings (currently available in the nightly builds). Here's a tutorial on how to import Blender animations using assimp.
30  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - Assimp bindings on: 2016-11-30 12:41:32
Good job guys!

This is awesome!

But you kinda made elect's work on jAssimp obsolete...?

Well, let's say it's good to have alternatives, because each solution has its pro and vs

A binding is relatively fast to implement and is almost change independent

but a pure port has three main advantages, you are under the optimization of the jvm, your whole memory is being managed by the garbage collector and it is available for all those who don't use lwjgl 3.1.1 build5 +. On the other side, of course, it's slower to implement and you need to keep it up with the cpp version, although most of the changes are being done on the last formats

I personally didn't know jAssimp was being worked on. I, too, would love to be able to use a Java library given the choice, especially one written in Kotlin (my language of choice these days). Where it makes sense. IMHO it makes zero sense in this case. There's only one advantage to using a Java library for loading 3D scenes:

- The API is nicer.

OK, so what? Is this the bottleneck when developing a graphics app or game? How much time you'll spend writing your model loading code? The disadvantages:

- You have to write a ton of code to create a replica of something that already exists.
- You have to spend countless hours designing the API and fixing bugs in your implementation.
- You have to do a ton of work to maintain it after it's done.
- If you do add new features, you're doing a disservice to the open source community. If you contributed to the original project instead, all downstream users would benefit.
- Hotspot is magic and GC is magic and we love them both, but doing IO and loading resources is exactly the workload where there's absolutely no benefit to using a JIT and managed memory. All resources associated with a native loader are gone when you're done, but with a Java implementation the JVM has loaded a lot of Java code, has wasted a lot of time optimizing it... and then it's just stays there. Besides, do you really think it's easy to beat a native implementation (in both CPU time and especially memory overhead) with pure Java? Not saying it's impossible, but is this the best use of a developer's time?

Finally, I'd like to address the comment on availability. You don't have to "use LWJGL" to use LWJGL's assimp bindings. The library is now modular, you can choose to use the set of bindings you need and nothing else. If that means assimp only, then yes, that works fine.
Pages: [1] 2 3 ... 36
 
Rule (71 views)
2017-03-19 12:43:22

Rule (62 views)
2017-03-19 12:42:17

Rule (73 views)
2017-03-19 12:36:21

theagentd (83 views)
2017-03-16 05:07:07

theagentd (84 views)
2017-03-15 22:37:06

theagentd (80 views)
2017-03-15 22:32:18

theagentd (78 views)
2017-03-15 22:31:11

ral0r2 (133 views)
2017-03-03 11:52:41

ral0r2 (132 views)
2017-03-03 11:42:24

Archive (316 views)
2017-02-27 19:41:49
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
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!