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   
  Show Posts
Pages: [1] 2 3 ... 36
1  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
2  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.
3  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.
4  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.
5  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.
6  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>
7  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.
8  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>
9  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.
10  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.
11  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

12  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.
13  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.
14  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.
15  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.
16  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.
17  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
18  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.
19  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.
20  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;
21  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.
22  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.
23  Java Game APIs & Engines / Engines, Libraries and Tools / LWJGL 3 - Assimp bindings on: 2016-11-27 09:43:35
The latest LWJGL snapshot (3.1.1 build 5) includes bindings to Assimp, a library to import and export various well-known 3D model formats in a uniform manner. It also features various post processing tools, including frequently-needed operations such as computing normal and tangent vectors, ACMR optimization, etc.

The build that comes with LWJGL includes all supported file formats (about 40 of them), so the shared libraries are bigger than usual. Assimp supports cmake, so you can easily create a custom build that includes only the formats you need, making it much smaller. You can then drop it in LWJGL and it will work just fine.

The bindings were contributed by SHC, many thanks to him!
24  Java Game APIs & Engines / Engines, Libraries and Tools / LWJGL 3.1.0 on: 2016-10-30 21:59:30
LWJGL 3.1.0 has been released!

Release notes
Download
25  Game Development / Newbie & Debugging Questions / Re: [LWJGL] 3 - Working with contexts on: 2016-10-27 12:12:59
Reckon the way to do this is to just forget the business about passing the context, set all "images" in main thread?

Doing everything on the main thread is a legitimate solution. Reasons for using secondary thread(s) include: a) decoupling the event loop from rendering and b) decoupling loading OpenGL assets from rendering (asynchronous loading of models, textures etc).

For the specific issue you're having with the window not responding, I would recommend simplifying your code and posting a sample that reproduces the freeze.
26  Game Development / Newbie & Debugging Questions / Re: [LWJGL] 3 - Working with contexts on: 2016-10-27 07:42:45
Setting java.library.path or org.lwjgl.librarypath is not required. These two settings are still supported and used internally, but you shouldn't need them unless you're doing some customization (e.g. creating a platform-specific installer for your application).

LWJGL has something called the SharedLibraryLoader which takes care of extracting the native libraries from the natives JARs and loading them automatically. The only thing you need to do is add the JARs to the classpath. So, if for example you're making a GLFW+OpenGL application and are running on Windows, you'll have to set the classpath to include:

lwjgl.jar
lwjgl-natives-windows.jar
lwjgl-opengl.jar
lwjgl-glfw.jar
lwjgl-glfw-natives-windows.jar

That's it. From the command line it's simple; if you have all LWJGL JARs in a subfolder called "lwjgl", you can do:

java -cp lwjgl/*;<other stuff here> my.application.Main

and it should just work. In Eclipse, or any other IDE, configure your project to include all the LWJGL JARs in the classpath.
27  Game Development / Newbie & Debugging Questions / Re: [LWJGL] 3 - Working with contexts on: 2016-10-26 18:02:39
LWJGL 3.1.0 is modular, meaning that each binding is now a separate artifact. The build configurator on the site can be used to include only the bindings you're going to use.

Setting up your project in Eclipse should be as simple as adding the JARs you downloaded to the project classpath.
28  Game Development / Newbie & Debugging Questions / Re: [LWJGL] 3 - Working with contexts on: 2016-10-26 14:29:31
That's a bug in 3.0.0. Please upgrade to the latest nightly build (which also happens to be a release candidate for 3.1.0).
29  Game Development / Newbie & Debugging Questions / Re: [LWJGL] 3 - Working with contexts on: 2016-10-26 10:49:07
The design of GLFW requires that all event handling happens on the main thread. So a loop that looks like:

1  
2  
3  
4  
5  
while ( !glfwWindowShouldClose(window) ) {
    glfwPollEvents();

    // ...
}


should go on the main thread.

Rendering can happen on any thread, main or secondary. You can do rendering on a secondary thread by passing the window handle to that thread and calling glfwMakeContextCurrent(window). This makes the OpenGL context associated with that window current in the secondary thread. GL.createCapabilities() will work after that and you can use the LWJGL OpenGL bindings to do rendering.
30  Java Game APIs & Engines / Engines, Libraries and Tools / Re: JOML 1.8.0 Release on: 2016-10-24 12:30:08
Actually, no. You have to force this module to be exported, I had to use this even though I don't package my software as a module:
Quote
--add-exports jdk.unsupported/jdk.internal.ref=ALL-UNNAMED

My guess is that you depend on Cleaner, which has been completely removed from sun.misc and moved to jdk.internal.ref. It has nothing to do with sun.misc.Unsafe.
Pages: [1] 2 3 ... 36
 
numerical (72 views)
2017-02-21 07:32:16

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

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

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

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

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

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

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

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

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