Java-Gaming.org Hi !
Featured games (88)
games approved by the League of Dukes
Games in Showcase (681)
Games in Android Showcase (196)
games submitted by our members
Games in WIP (744)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1] 2 3 ... 34
1  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - LMDB bindings on: 2016-06-17 19:24:42
Progress update:



Needs a lot more work, but all tests and demos run fine.

The resulting binaries are roughly 2x the original lwjgl.dll size, because the CRT is statically linked in every module. It shouldn't be a problem if only a subset of them is used. Some may be merged into the core library, they're tiny without the CRT. For example JAWT and jemalloc add about 1kb to lwjgl.dll, but are 83kb and 84kb standalone (note: this is just for the JNI functions, not the libraries themselves). The corresponding modules will still be optional.
2  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - LMDB bindings on: 2016-06-07 15:30:22
I think you're being a little defensive about my observations, Spasi! I'm quite aware of the 3.0.1 goals already.

I guessed so, I'm just trying to address your concerns in a way that will be understandable to everyone reading. I fully appreciate your input btw!

It's a pity to de-motivate the project lead like that.

Don't worry, there's no demotivation going on. Cas has strong opinions and gives honest advice. It's always helpful.
3  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - LMDB bindings on: 2016-06-07 15:21:46
it appears to be largely driven by you and your own personal needs and as such seems to me to have become a giant git repository with all of your open source work in it.

Let's be fair here.

LWJGL 2 bindings that we ought to have in LWJGL 3:

- OpenAL
- OpenCL
- OpenGL
- OpenGL ES
- EGL

Bindings that were absolutely necessary in LWJGL 3:

- GLFW (Display + input API replacement)
- Vulkan (a good match for LWJGL and also the most user requested API)
- dyncall (FFI + dynamically generated native-to-Java callbacks)
- Basic system calls

Bindings requested by users:

- JAWT
- LibOVR (Oculus SDK)
- NanoVG
- SSE(3)
- Misc system calls

Bindings that I added without anyone asking, but everyone agreed were extremely useful:

- jemalloc
- stb (image IO, font rendering, vorbis decoding, etc)

Bindings that I added without anyone asking, are not that exciting, but try to solve real problems LWJGL users face:

- NativeFileDialog
- Nuklear
- libstem_gamepad (in a branch, failed experiment, to satisfy concerns about GLFW's gamepad support)

Bindings that I added without anyone asking, either from curiosity or because I needed them for personal work:

- xxHash (tiny & fast non-cryptographic hash functions)
- LMDB (post 3.0.0)
- ODBC (mostly complete branch)
- hwloc (incomplete branch)

I hope it's obvious that the majority of the work I did was driven by user needs. The only personal binding that made it to 3.0.0 is negligible compared to the rest.

What it definitely isn't, modular or not, is a lightweight Java games/graphics library! It's no longer a lightweight project as it covers everything from GUIs to compute to audio to in-memory databases to hacking the Java language to get structs in.

I would argue that it is indeed lightweight because it doesn't do anything. None of the APIs or functionality provided by LWJGL has been designed or written by LWJGL developers. The only thing the LWJGL core provides is a half-decent way to interact with native APIs and data from Java/JVM.

Also, why is any of the above an issue if #100 allows you to download LWJGL core, GLFW, OpenGL and OpenAL and nothing else?

It's not Java any more as it now contains multiple binary libraries. It's not a single library now but a whole multitude of libraries.

I don't get this. Why does it matter how many binaries there are? Deployment issues are a thing of the past with the SharedLibraryLoader. LWJGL 2 also had two native binaries (lwjgl + OpenAL Soft), now there are 2 more (GLFW and the optional jemalloc). How's that less Java than before?

What LWJGL 3 is now is a vast collection of bindings, most of which are irrelevant to most people. What this means is that maintenance effort is going to be simply non-existent on it, and once you (eventually) grow tired of it, and you will, it'll just stagnate and get bitrot and become a large legacy which will distract people from otherwise creating separate efforts to solve specific issues.

There is a very critical difference. Once Elias stopped working on LWJGL we were screwed, because there was no one with the experience to improve/fix the OS-specific functionality. There's no expertise required to maintain LWJGL 3. Someone has a problem with GLFW? Open an issue on their github and (if it's legit) elmindreda will fix it eventually. It's not our problem anymore.

I lost interest in maintaining LWJGL after a few years of developing on it, largely because it did everything I needed it to by that point, and also because I was seeing virtually no return on my efforts. I watched Markus accumulate two and a half billion dollars on the back of the literally months and months of effort I'd put in on the library he used to catapult himself into the realms of the unspeakably rich with barely so much as a thankyou, and that, for me, was the point at which I decided I couldn't be arsed with open source any more. I only have so much time left in the world and a lot of things I'd like to do, and making Markus richer wasn't on the list, so I diverted my efforts elsewhere. At some point, you too will find something more interesting and distracting, and you'll be leaving behind a huge, huge pile of stuff which no-one except you really cares too much about.

Oh, I do have something a lot more interesting to work on. Wink That's why I've put a huge effort into making LWJGL 3 easily maintanable.

On seeing a return on open-source efforts... I don't know, that's not what open-source is about I guess. I even removed the option to donate to LWJGL when I took over. Didn't feel right without having something to deliver. On the other hand, what we have been doing in LWJGL isn't just open-source... Writing JNI bindings is on its own level of masochism. It's the kind of open-source that no one wants to be doing. That usually has value. When my wife asks what I'm doing, I wish I had something better to say than "omg I'm writing Vulkan bindings, do you know how IMPORTANT this is?". Especially with the economy in Greece being what it is.

On Minecraft, I cannot claim any credit for what LWJGL was when Minecraft happened. Maybe Cas is right, I don't know. What I do know is that post-Minecraft success, its users had lots of trouble because of LWJGL and we didn't do much for them. We never had much of a contact with Marcus or their devs either, which I found strange given how critical LWJGL was for the game. Strange situation.

I strongly advise you to split LWJGL up into the bare minimum and then create separate, independent projects that build on top of or besides LWJGL for GUI libraries, structs, OpenCL, in-memory databases, vector math, etc.

Having everything in the same repo, in branches, or in different repos, is just a technicality. The only thing that matters is how the software is deployed. With #100 + a few other ideas we had recently, I believe everyone will be satisfied.
4  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - LMDB bindings on: 2016-06-07 10:33:53
I might actually rip a lot out of the jar if thats the case.

This is possible and some users do it. You can remove any binding package you don't need from lwjgl.jar and you can also delete the jemalloc/GLFW/OpenAL shared libraries. #100 will make it so that you don't have to do it manually and will also split the lwjgl shared library itself (which contains the core functionality + statically linked bindings).
5  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - LMDB bindings on: 2016-06-07 10:16:32
This is why I waited for the 3.0.0 release before merging the LMDB branch. I expected some controversy and wanted to see if enough users would find it useful first. Currently LMDB only exists in a nightly build of 3.0.1. No harm has been done. This is also the 3rd time I have to mention in this forum that 3.0.1 will not be released without a solution for #100, which will break the LWJGL distribution in separate artifacts for each binding; you will be able to choose what you want or don't want in your application.

I'm really not at all sure how this fits in with LWJGL, either in a gaming context, a general purpose graphics context

Offering solutions for gaming and graphics has always been LWJGL's primary objective and what most people in this forum care about. But it's not only about that. Which makes sense since I'm (almost) the sole developer, I use it a lot in my projects and I don't make games.

I bet no more than 5 users have ever used LWJGL's OpenCL bindings, yet I find them super-important and have spent countless hours working on them. Why aren't there any complains about those?

or even in a Java context... I'm very reluctant to bind to native code to do stuff that Java code can do. The LWJGL was all about binding to native APIs that could not otherwise be done in Java

I don't agree with this either. Just because something can be implemented in Java does not mean it should. I've actually done it: JGLFW. It was a GLFW implementation written entirely in Java, using only bindings to OS functionality. It was an experiment to validate LWJGL 3's approach to JNI and I gladly deleted it when I became satisfied it worked nicely. Why?

- Look at the mess LWJGL 2 was in. There were dozens of bugs and no one to fix them. Who's going to write a decent windowing system in Java (or anything that touches lots of OS-specific APIs like GLFW and LMDB) and maintain it?
- A Java binding to a native library means that Java developers benefit from the existing community in many ways: more example code out there to get you started, more users testing the same code, more users contributing fixes. The existing community benefits too, Java developers can contribute feedback and fixes to the native library (there are many examples of that in GLFW already). Overall, the bigger the ecosystem around a library the better for everyone involved.
- Why reinvent the wheel?
6  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - LMDB bindings on: 2016-06-06 18:31:53
1. This link doesn't work :

Thanks, fixed.

2. I understand what the LMDB is, I can think of non gaming scenario's where this is very useful. But what do you see as the use case in a gaming sense for a database (and one that is super fast)?

I mentioned some ideas in the first post. I often see game developers creating custom solutions for storing user settings, game saves, metadata for shaders/models/textures, game levels, etc. I think replacing all that with a robust, easy-to-use and very efficient database like LMDB would be useful. It can even be used to store binary blobs (meshes, textures, sounds, shader binaries).
7  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - Nuklear bindings on: 2016-06-06 15:08:37
I wouldn't recommend this become part of "core" LWJGL but it'd be a welcome bolt-on library. That said... it would maybe just be better off as an entirely separate project dependent on LWJGL3?

The 3.0.1 release will have a solution for #100. The LWJGL core and most of the "heavyweight" bindings (including Nuklear) will be separate artifacts.
8  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - LMDB bindings on: 2016-06-05 13:44:44
tho' i'd be more intersted in LMDB stand-alone bindings.

That will be 3.0.1's primary feature.
9  Java Game APIs & Engines / Engines, Libraries and Tools / LWJGL 3 - Nuklear bindings on: 2016-06-05 11:29:47
As part of the effort to add a useful GUI solution to LWJGL (see #101), the first LWJGL 3.0.1 build includes bindings to Nuklear, a minimal state immediate mode GUI toolkit. It is similar to imgui, but with a C API.

This is an experimental binding. Please post any impressions or problems you might have here (or open an issue on Github).
10  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - LMDB bindings on: 2016-06-05 11:21:44
The first LWJGL 3.0.1 nightly build is now available and it includes LMDB.
11  Java Game APIs & Engines / Engines, Libraries and Tools / LWJGL 3.0.0 released on: 2016-06-03 18:30:55
Visit the download page to get it. You can also get it from Maven Central or this direct link.

Release notes (since 3.0.0b):

BINDINGS

- Added support for Java array parameters and HotSpot Critical Natives. (#175)
- Added Vulkan bindings. (#50)
- Added NanoVG bindings. (#99)
- Added NativeFileDialog bindings.
- Added par_shapes.h bindings.
- Added dyncall bindings.
- Added jawt bindings for AWT/Swing integration. (#125)
- Added simple OS-specific window creation bindings, for custom window/context creation. (#105)
- Added missing OpenCL and OpenAL extensions.
- Fully documented OpenCL and OpenAL.
- Moved WGL and GLX capabilities to the new WGLCapabilities and GLXCapabilities classes, respectively. Functionality in WGL, GLX and corresponding extensions that does not require a current context can now be used without creating a dummy context first. (#171)

IMPROVEMENTS

- Added stack allocation APIs (the MemoryStack class and new allocation methods in struct classes and MemoryUtil).
- Made the implementations of PointerBuffer and Struct/StructBuffer subclasses as lightweight as possible. This makes it easier for escape analysis to eliminate allocations.
- Minor struct API improvements.
- Added nullability information to struct members, to protect against buggy code crashing the JVM.
- All bindings are updated to the latest versions of the corresponding libraries. Notably, GLFW now has glfwSetWindowIcon and glfwSetWindowMonitor, it now doesn't lack anything compared to LWJGL 2's Display.
- Refactored callbacks for Java 8. (#182)
- Added NativeResource interface and made freeable objects usable as resources in try-with-resources statements. (#186)
- Faster thread-local lookups for the stack and current capabilities. New options in Configuration can be used to complete eliminate thread-local lookup in OpenGL, OpenGL ES and OpenAL, when it is known that only a single context will be used, or that all contexts will be compatible (same capabilities and same function pointers).
- Added memSlice for all buffers types in MemoryUtil. (#179)
- Refactored the Configuration class for type safety and added more options.
- JDK 9 can now be used to build and run LWJGL.
- Javadoc is now generated with JDK 9. The API is fully indexed and search functionality is available. Also made multiple Javadoc formatting improvements.
- Improved debug diagnostics on startup and when loading the LWJGL shared library fails.
- Optimized memSet and memCopy for small buffers.

FIXES

- Stopped using UPX compression for binaries. This eliminates various integration issues and virus scanning false-positives.
- The SharedLibraryLoader now works with any shared library, not only libraries LWJGL knows about. (#176)

BREAKING CHANGES

- LWJGL now requires Java 8 to build and run. Certain custom interfaces have been replaced with java.util.function interfaces. (#177)
- Dropped support for Linux x86. (#162)
- Dropped libffi bindings.
- Dropped ALDevice/ALContext wrappers from OpenAL and CLPlatform/CLDevice wrappers from OpenCL. (#152)
- Dropped the getInstance() method from bindings loaded from shared libraries. Function pointers are now stored either in capabilities classes or in a nested Functions inner class.
- Dropped infrequently used method overloads in bindings. Full javadoc is now generated on (almost) all overloads.
- Dropped utility classes that were not useful.
- Added AutoSize support to struct members. Instance setters for the corresponding count/size members were removed to avoid bugs and confusion.
- Replaced MemoryUtil.memFree(StructBuffer) with StructBuffer.free().
- Renamed __ALIGNMENT to ALIGNOF in struct classes.
- Removed org.lwjgl.system.Retainable interface. Closure and FunctionProvider subclasses are now destroyed using .free() instead of .release().
- Moved xxHash and SSE bindings to the org.lwjgl.util package.
- Integer-boolean native types (0 or 1 are the only legal values) are now mapped to Java booleans. (#181)
- Macros without parameters are now generated as static final values, not methods.
12  Game Development / Newbie & Debugging Questions / Re: LWJGL3 Jar Unable to extract LWJGL natives on: 2016-06-02 11:09:34
For the SharedLibraryLoader to work, the native libraries must be in the classpath.

I tried adding the following to the first line of my static void main(String... args) method:
1  
Configuration.LIBRARY_PATH.set(new File("libs/LWJGL 3.0.0b/native").getAbsolutePath());

Note that
new File("libs/LWJGL 3.0.0b/native")
will create a path relative to the working directory. Make sure it is the root of your project and it should work.
13  Java Game APIs & Engines / JavaFX / Re: JavaFX For Pixel Games on: 2016-06-02 11:00:54
I gave up JavaFX when I ported prism to LWJGL3. With such a horrible backend design and implementation, it's not surprising that progress is slow, performance suffers and simple features cannot be added easily.
14  Discussions / General Discussions / Re: Interesting proposals: Java 9 and beyond on: 2016-05-27 20:11:59
Some examples:

SnippetTest
Vector
UnixSystem

Btw, a Scope object is "a unit of resources allocation that can be released all together". The current prototype has the NativeScope and HeapScope classes. The later uses long[] as the backing memory (on which you can map structs etc).
15  Discussions / General Discussions / Re: Interesting proposals: Java 9 and beyond on: 2016-05-27 14:15:41
Any mention of stack allocation and value types in the same sentence makes me wonder whether they're going to design what we actually need or whether they're just going to go off on one and make something almost but not quite entirely wrong.

The current Panama prototype supports "machine code snippets". You can write some code outside the JVM/JDK that makes the JVM inline and JIT-compile a method handle to one or more native CPU instructions (of your choice) that also play well with the JVM register allocator. This functionality alone could be used by a library to do amazing things.

API-wise, I wouldn't expect anything pretty without syntactic sugar. But it is true that it is designed under the assumption that Java 10 will have value types and any-generics. This, in theory, will allow Java-ish code to perform just like native C.
16  Discussions / General Discussions / Re: RSS feeds for JGO still broken since October 2015 on: 2016-05-25 14:34:04
I use RSS (via Inoreader too) to follow people that have interesting blogs, but are really annoying on Twitter.
17  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Java Build Tool on: 2016-05-18 15:18:25
Kotlin Meets Gradle
18  Game Development / Newbie & Debugging Questions / Re: [LWJGL] Choosing your GPU on: 2016-05-16 18:37:52
There is an open issue related to this, currently targeted for GLFW 3.3.
19  Java Game APIs & Engines / Engines, Libraries and Tools / LWJGL 3 - LMDB bindings on: 2016-05-02 19:10:05
There's a new lmdb branch in the LWJGL 3 repository that implements bindings to LMDB. It's an embedded key-value store that may be used for all kinds of persistence, from game settings to shaders, models and textures (binary values up to Integer.MAX_VALUE in size are supported).

See this presentation to understand what's special about LMDB.
See this LWJGL sample for a demo of the API and an example of zero-copy string persistence.

The nightly builds do not include LMDB yet, you'll have to clone LWJGL and build locally to give it a try. I'll decide what to do after the 3.0.0 release, but it's definitely small enough to embed in the standard LWJGL distribution. Please let me know if you're interested.
20  Java Game APIs & Engines / OpenGL Development / Re: LWJGL 3 vs JOGL on: 2016-05-02 11:04:33
Thanks, fixed in 3.0.0 build 81.
21  Java Game APIs & Engines / OpenGL Development / Re: Mutithreaded LWJGL - Works... Sometimes on: 2016-05-01 07:25:46
what will happen if I add a glfw key callback to the child threads? Will they still be called back, or do I have to track which window is focused myself?

You can't, glfwSetKeyCallback can only be called from the main thread. The same is true for glfwPollEvents, so all events will be handled on the main thread too. If a rendering thread needs to know whether it's corresponding window is focused or not, you must pass that information from the main thread to the rendering thread.
22  Java Game APIs & Engines / OpenGL Development / Re: Mutithreaded LWJGL - Works... Sometimes on: 2016-04-30 17:14:47
I was looking for a tutorial like that! I'm implementing the countdown and a bunch of other stuff now.

Note that you don't have to use a CountDownLatch for synchronization/communication, that's just an example. The only important detail is: most GLFW functions are called from the main thread, the per-window threads only deal with rendering.

This does imply that, at some point, you have to have synchronization points and/or pass messages between threads. Neither GLFW nor LWJGL have any special requirements for how that happens, it's entirely up to the application and how it's designed. Fortunately, Java has a very rich set of concurrency primitives (like CountDownLatch) and concurrent data structures that can be used for that purpose.

I meant to ask, does input handling per window still work regardless of the main thread?

The only thread that deals with window/input events is the main thread. It works fine regardless of how many windows or rendering threads you have.

23  Java Game APIs & Engines / OpenGL Development / Re: Mutithreaded LWJGL - Works... Sometimes on: 2016-04-30 07:06:19
Here's the run method, which is pretty unimpressive (I really just threw it together with some stuff I found online, it worked for a little while, then the glfwInit started crashing the VM)
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
@Override
public void run() {
    super.run();
    glfwPollEvents();

    glfwSetErrorCallback(errorCallback = new GLFWErrorCallback() {
        @Override
        public void invoke(int error, long description) {
            System.err.println("glerror occurred: " + error);
        }
    });
    if (glfwInit() != GL_TRUE) {
        System.err.println("Error initializing GLFW");
    }
}

You cannot call glfwPollEvents before glfwInit. If glfwSetErrorCallback was above the glfwPollEvents call, you'd see the error.

Also, calling glfwInit and handling the event loop in arbitrary threads is not supported. The design of GLFW is similar to AWT/Swing/JavaFX; event processing must happen in a single thread. See the Threads sample for the correct way to handle multiple windows/threads.
24  Java Game APIs & Engines / OpenGL Development / Re: LWJGL 3 vs JOGL on: 2016-04-28 15:54:02
Also, the window icon support is very limited right now.

What exactly is missing? If you mean OS X icons, that's up to the application bundling and outside GLFW's scope.

I still can't actually use it commercially, myself, because GLFW still doesn't have buffered controller input :/

A few points:

- GLFW was originally supposed to be one of many windowing/input backends in LWJGL 3. Users have been pretty happy with it so an alternative has not been considered so far, but we're open to suggestions.
- Partial replacements is another possibility (OIS?).
- Issues that affect commercial applications get top priority. Let us know please!
25  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3.0.0 release candidate on: 2016-04-27 14:32:28
GLFW still cannot be started on the AWT thread without it's event loop.

Note that this is a problem only on MacOS. In any case, GLFW does not know anything about AWT and is not supposed to interoperate with it.

The JAWT bindings are there for users interested in implementing LWJGL 2's AWTGLCanvas on top of LWJGL 3. Example code here.
26  Java Game APIs & Engines / Engines, Libraries and Tools / LWJGL 3.0.0 release candidate on: 2016-04-27 13:58:26
The current LWJGL 3 nightly build is the first 3.0.0 release candidate.

Now is the time to try it out and report any instabilities or raise any issues you might have with the API. See this post for changes since 3.0.0b.
27  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3 and Android on: 2016-04-27 11:46:43
@Spasi I'm not really sure if we're talking about same thing, but for me the strength of 3rd party library is the abstraction over the display and input; no need to poll/listen/draw using platform specific APIs. I  don't know how people use the GL with relation to Java though it's true I see most people use engines/libs like LibGDX or JME, not directly; never have seen anybody writing a native code to optimize stuff (but I'm not really in the so serious business).

There would be two ways to use LWJGL in Android:

1) Use LWJGL for OpenGL ES or Vulkan and use Android APIs for display and input.
2) Replace Android APIs with GLFW for display and input. Currently the problem with GLFW is that it won't support touch events until version 3.3.
28  Java Game APIs & Engines / OpenGL Development / Re: LWJGL 3 vs JOGL on: 2016-04-27 11:34:50
I'm obviously biased and won't try to compare LWJGL with JogAmp or list LWJGL's pros/cons. I'll just say that there are differences in philosophy between the two libraries and in what they try to do and not do. JogAmp does things I wouldn't want any library to be doing for me.

Having said that, I have to reply to this:

This reflects in jogl being faster by about 3-5% over lwjgl based on some benchs, strictly opengl call bound

For those that are not aware, LWJGL performs a thread-local lookup on every call to OpenGL. It's the only way to make the static nature of the API work. This also applies to OpenGL ES and OpenAL, but not other bindings (e.g. OpenCL or Vulkan). This may sound expensive, however:

- It's been like that since the first LWJGL version. If it was fast enough in 2002 and Java 1.4, it's fast enough now.

- You can barely measure the performance impact. It's certainly nowhere close to a 3-5% overhead. It's not measurable in real-world OpenGL applications and in fact it's quite hard to measure even in micro-benchmarks (e.g. I had to use JNI methods that do nothing).

- LWJGL 2 optimized the lookup by caching the last thread that called an OpenGL method. This has been removed in LWJGL 3, since it's more common to have multiple threads/contexts these days. It has been replaced with an efficient (but somewhat "hacky") O(1) lookup. java.lang.ThreadLocal is not used by default.

- In the (very very unlikely) scenario where this lookup has a measurable performance impact for your app, you can cache OpenGL function pointers and use LWJGL's (publicly available) JNI/"unsafe" methods. This is one of LWJGL 3's non-obvious features: if LWJGL can do it internally, so can the user. If the user doesn't like the way LWJGL implements something, they can replace it with a custom implementation.

- In the (very very common) scenario where the application either a) creates a single OpenGL context only or b) all OpenGL contexts are created on the same device and with the same context creation flags, you can use
Configuration.OPENGL_CAPABILITIES_STATE.set("static")
(or launch the JVM with -Dorg.lwjgl.opengl.capabilities=static). This completely eliminates the thread-local lookup and in fact JIT compiles to more efficient code than even JOGL's way. This option is also available for OpenGL ES and OpenAL.

In general, LWJGL 3 has undergone extreme performance tuning. A lot of work has gone into that front the past few months and it's one of the main reasons 3.0.0 is not released yet. The way buffers, arrays and structs are handled in LWJGL and JogAmp are completely different and LWJGL has the upper hand in all situations. If anyone has doubts or thinks otherwise, I'm willing to discuss technical details and accept any benchmarking challenge.
29  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3 and Android on: 2016-04-27 10:28:55
check out LibGDX, which uses LWJGL3 (and 2 if you prefer) and builds to both desktop and android (and ios)

Just to be clear: This isn't a question of whether it's possible to take a library that normally targets PCs and making it run on Android or other resource constrained devices. I'm sure you can do that with most, if not all, libraries. The real question is: what does it offer over what's already available on the platform and will people use it?

With LWJGL, the above question can be made more specific:

- LWJGL 3 has been designed for modern JVMs (i.e. Hotspot -server). All choices related to API design and performance-tuning have been made after testing on such JVMs. Are the same choices optimal on Android? (very likely not)
- Android already has EGL/OpenGL ES bindings. It's missing Vulkan atm, but it's probably coming. Why would anyone use a 3rd-party library for that? Also, we're talking about Java code calling GL/VK functions... does anyone even do that these days? I'm under the impression that most serious developers prefer using the NDK and going to native code for performance sensitive stuff.
30  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3 and Android on: 2016-04-26 15:19:50
since the LWJGL docs seems to be almost non-present

Not sure what you mean. LWJGL has a site, a forum, a wiki, github issues and ~75MB worth of javadoc.

Does LWJGL3 applications can be run on Android? Is there a support for touch events, or perhaps accelerometer? Simply: what about the interoperability between LWJGL3 and Android devices? Could somebody elaborate on this topic?

The next steps for LWJGL, after the 3.0.0 release which is coming soon, are:

- ARM builds for devices like the Raspberry Pi.
- Android support, if it makes sense.

For the second point, I recently bought an Nvidia Shield to explore if there's a viable approach. I wouldn't get too excited though, because one or more of the points below are quite likely to happen:

- It will suck and there won't be any support.
- LWJGL for Android will be a different library than standard LWJGL (will have different bindings and different core API).
- The minimum supported Android version will be (too) high.
Pages: [1] 2 3 ... 34
 
Hydroque (48 views)
2016-06-22 02:17:53

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

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

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

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

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

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

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

Mac70 (170 views)
2016-05-24 21:16:33

theagentd (153 views)
2016-05-14 18:38:35
Making a Dynamic Plugin System
by Hydroque
2016-06-25 00:13:25

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

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

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

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

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

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

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