* WORK IN PROGRESS * This post will be updated over the next days with additional info and results of the discussion that will follow.
So, it's time to start talking about LWJGL 3.0. For those that haven't heard it before, this next major release will not be backward compatible with the current one. The plan is to clean up some legacy stuff and improve the library design so that we can support features that are either impossible right now or too hard to implement. Any feedback on the proposed changes or suggestions for additional ones will be very welcome.
First, lets get something clear up front. The static nature of the AL/CL/GL bindings, which sets LWJGL apart from similar libraries, will NOT change. This means that when migrating to 3.0, required changes will be quite limited. Everything else is subject to discussion (context management, input APIs, utility classes, etc).
[ High Level Goals ]
- Migrate the codebase to Git and possibly host on Github. The existing codebase will remain on SVN/Sourceforge for critical/minor fixes only.
The main incentive is to attract more contributions to LWJGL. Git is more popular than SVN, hence more likely to be already installed on a potential contributor's environment, removing one extra step from the process. It operates more efficiently (http://git-scm.com/about/small-and-fast) than SVN and allows for cheap branching, essential for exploring new features. Github is a great hosting environment and free for OS projects. Even though alternatives exists, it's the most mature and popular one. The brilliant pull request automation is another feature that will hopefully attract more contributions.
- Improve context management. Allow LWJGL to more easily use external contexts. Better support multiple contexts.
The goal here is to expose much more of the functionality currently hidden behind Context and Drawable. The critical change for this to happen is to make the native layer much lighter; we need to transform it to a simple binding layer, like the GL extensions, and move all the complicated functionality to Java code. In the process, we'll expose the low-level APIs so that advanced users will be able to take over context management and do things we didn't predict or didn't have the time to implement.
- Fully expose vendor-specific and OS-specific extensions, just like we do with normal GL extensions (with automated generation with the extension generator).
Similar to the above goal, this will allow users to easily explore advanced features (multi-GPU solutions, video I/O, etc).
- Move the native windowing system to an independent package. Remove any dependencies between the windowing system and GL contexts. Make windowing system pluggable.
Besides the obvious cleanup that is required, this is probably the most complicated problem we have. Discussion below.
- The native Display should be OOfied to allow for multiple native windows.
The benefit for this is arguably limited, but since we're refactoring everything, it shouldn't be too hard to accomplish.
- Remove legacy features: pbuffers, AWT integration, the debug jar, the util package, deprecated functions.
pbuffers are obsolete, AWT/Swing are basically dead (JavaFX is everywhere we want LWJGL to run anyway), the debug jar is useless since ARB_debug_output (and well, there are other debug tools (https://www.opengl.org/wiki/Debugging_Tools) too). I guess we should talk a bit about the util package, but imho it belongs to a higher-level library than LWJGL.
[ Technical Issues ]
- Bump minimum required JRE version to 6.0. Or maybe 7.0?
- Bump minimum required GL version from 1.1 to 2.0 (or 2.1?). This will allow us to unify the GL11..GL20 classes for convenience.
- The extension generator uses annotation processing through apt, which has been deprecated since Java 6 and removed in Java 8. It needs to be updated to use javax.annotation.processing instead. Another option is to re-implement the whole thing without annotations; the current code is very powerful but also a nightmare to understand and maintain. There are easier/cleaner ways to do what it does. This of course will require a different representation for the extension templates, something other than Java interface + annotations.
- I'd be nice to remove the license message that exists in every LWJGL source file. We could replace it with something much more compact, like a link to the actual license (http://lwjgl.org/license.php).
- Support for OpenGL ES should be cleaned up and no dependencies should exist between ES and desktop GL. Improve the build process and provide pre-built binaries if possible.
[ Other features (not critical for 3.0) ]
- Provide "profile-based" GL classes. An example would be a GLCore class that contains all the functions/tokens from 1.1 to 3.1 (or 3.2), without the deprecated stuff.
- Allow building LWJGL with extension filters. For example, a user might want a light build without any vendor-specific extensions, only core + ARB/EXT extensions.
- Implement JavaFX integration if technically possible.
[ Discussion ]
We have two major issues: What to do exactly about the windowing system and how to organize the library in general.
- Windowing System
There's the current solution and there are the alternatives. Obviously, what we have now is years of battle-tested code, it works well but it's also a THE major headache to maintain and improve. The multi-platform nature of the code and the fact that we're targetting Java developers has made it very hard over the years to find reliable people to contribute changes to the windowing system. On the other hand, having our own solution is an obvious huge benefit, so far we have never depended on a third-party for new features and fixes.
Alternatives exist. The JogAmp people seem to have done a good job with NEWT, though I haven't explored their code yet and am not sure if it covers everything we need. JavaFX is getting fully open sourced soon (last I heard was January?) and its Glass Windowing Toolkit is another solution. Though, we're not sure how full the open sourcing will be and if we'll be able to use it, both for technical and licensing reasons. Then there are various (http://en.wikipedia.org/wiki/List_of_widget_toolkits#Cross-platform) C/C++ based cross-platform windowing toolkits we could bind to. Again, we'd need to explore and choose a solution that fits our needs.
To me it seems that the best way forward would be to abstract away the windowing system. It would take too much time to decide and commit to a single solution. It's better to go through the pain of hidding the current solution behind an interface and enable pluggable windowing systems.
- Library Organization
A few issues here:
1. How to handle the util package and other utility classes. I would like to see a more clean separation between what's essential and what's an utility. The extreme would be to move everything out of LWJGL and create a separate library (maintained either by us or a third-party if there's interest) that takes care of simplifying people's life. This library would probably get richer than what we currently have, a propery vector lib, shader utilities, etc. Personally I would happily contribute to such a library (I got a lot of stuff hanging around that I use in my various projects). LWJGL would only keep the absolutely basics, like the BufferUtils class.
2. There's plenty of duplicated code in LWJGL that we haven't eliminated so far in the name of proper encapsulation (e.g. package private classes) or maybe safety. I'm tired of this bullshit tbh and I plan to just make stuff public and reusable. For where this code will reside we have 2 options: a) Create an "org.lwjgl.impl" package and b) Create a package that doesn't start with "org.lwjgl", equivalent to the com.sun or com.oracle packages in the JRE. In either case the message to the user would be: "don't care about what's in here, it's only stuff we use to implement the library". I've seen both ways in other projects and I personally don't care what we choose. Let me know if anyone has a preference either way or maybe a package name suggestion.
3. Deployment and modularity. Depending on what we decide with the windowing toolkits, the util package and the cleanup of dependencies in general, we might want to revisit how we build and deploy the library. Continue with one fat jar or split it up a bit?
Can we not get rid of AWT support? Display.setParent is nice, especially for applets, and I'd be sad to not have an equivalent in 3.0.
Seconded, I vote for the interface solution and modify the existing AWT stuff to live behind a more general pluggable interface. This makes life easy for those of us depending on the current implementation and makes it easy for us to migrate to better solutions as they are added with minimal effort~
With a clean abstraction of the windowing system and the new context management, it should be relatively easy to re-implement AWT integration. Whether this happens within the library or through a 3rd party I'd like to leave open for now. The key point is to not "infect" the Display API with anything AWT related. An AWT Canvas is not a LWJGL Display and the Display stops being what it is when you use setParent.
Besides, there'll always be a pre-3.0 LWJGL available and hopefully we'll have JavaFX integration in 3.0 as well.
Very nice, agree with most.
1) The biggest issue is the native windowing, it needs to be moved out of and decoupled from the opengl package, the rest of the core library is pretty stable and needs little maintenance once implemented. I'd say just put it in something like org.lwjgl.display.*; so you'd have org.lwgl.display.Display, org.lwgl.display.DisplayImplementation and all the other classes needed to implement your own Display for a platform. Put each implementation in its own package (already done for native code but also needs to be done for the java side), e.g. org.lwjgl.display.windows;, org.lwjgl.display.linux, etc, this will allow programmers to easily hack on the platform they know without having to see or deal with any other platforms implementation or code.
2) Moving to GitHub is a good idea, SVN is now pretty much a stone age system in comparison.
3) Get rid of the all the utility packages, I'd say just put them in their own repo, pretty easy to do on github and still have them linked to the main LWJGL repo page. Just maintain them as separate projects with their own release cycle, its all Java code and as its utilities they don't need to be signed and the bits that aren't interesting to anyone can just die gracefully without causing code rot in the LWJGL core. The less there is in the main LWJGL repo the less there is to maintain.
4) Bumping to Java 6 shouldn't be a problem as Java 5 is pretty much dead market share wise.
5) As for annotations, wasn't apt mostly merged into javac? might be easier to use that then "javax.annotation.processing", not sure though.
[The below are just random idea's]
6) There should still be some sort of offscreen capability in the LWJGL core, maybe something based on FBO (possibly with a pbuffer fallback)? That way we can just grab the texture and write utilities to support all other windowing systems. Just pass the offscreen texture to AWT (Volatile Image), JavaFX, SWT, etc. Will have a tiny overhead but if its an idea that is workable would make life a lot easier rather than trying to maintain large chucks of code (including native) to support all the different frameworks, and as the texture is being drawn by the frameworks themselves, input, focus, etc would just work. Be nice to have the LWJGL core free from dependencies on any other framework (should make stuff like native compilation a lot easier).
7) Investigate the possibility of using something like the Waffle Project (http://people.freedesktop.org/~chadversary/waffle/) internally, GLX, WGL, CGL, EGL all need to be maintained separately and a pain as its native code which is different for each platform, if workable it'd mean a lot less maintenance for us and much cleaner code. The project is actively maintained by Intel and under a BSD Licence. There is already a push to try get Desktop OpenGL to use EGL, if such a move does happen (or someone needs the option), we'd already have the infrastructure to support this and just need to push a switch.
8 ) Just a pet peeve but guess i'll throw it out anyway, the name 'LWJGL' is quite a mouthful and not very brandable or memorable, how about dropping the 'W', since technically the word Lightweight is a single word, so it'll become 'LJGL' :)
I've got a more detailed list, which I'll post later once I find it.
Might be a bit controversial and it will definitely be a big effort...but maybe having a lightweight physics library like JBullet (it hasn't been updated since 2010 so maybe a fork in to this library)?
Also the library currently has graphics, sound and parallel computing CL area's. But it doesn't have video (like xuggler), physics (as above), and probably some others. Is the plan to build out the area's LWJGL covers or to keep it to its core of opengl/al/cl?
Quote from: spasi on November 08, 2012, 13:23:54...
- Improve context management. Allow LWJGL to more easily use external contexts. Better support multiple contexts.
The goal here is to expose much more of the functionality currently hidden behind Context and Drawable. The critical change for this to happen is to make the native layer much lighter; we need to transform it to a simple binding layer, like the GL extensions, and move all the complicated functionality to Java code. In the process, we'll expose the low-level APIs so that advanced users will be able to take over context management and do things we didn't predict or didn't have the time to implement.
- Fully expose vendor-specific and OS-specific extensions, just like we do with normal GL extensions (with automated generation with the extension generator).
Similar to the above goal, this will allow users to easily explore advanced features (multi-GPU solutions, video I/O, etc).
...
Hi spasi, I'd suggest a better multi-threading support for LWJGL. as you mentioned context switching and about multi-GPU support, here's something I want to ask : Is the following screen of piece of code from the "optimizing texture transfers (http://developer.download.nvidia.com/GTC/PDF/GTC2012/PresentationPDF/S0356-GTC2012-Texture-Transfers.pdf)" from nVidia GTC '12 portable to LWJGL ?
| capture thread | render thread | playout thread |
// Wait for signal to start upload
CPUWait(startUploadValid);
glWaitSync(startUpload[2]);
// Bind texture object
BindTexture(capTex[2]);
// Upload
glTexSubImage(texID…);
// Signal upload complete
GLSync endUpload[2]= glFenceSync(…);
CPUSignal(endUploadValid); | // Wait for download to complete
CPUWait(endDownloadValid);
glWaitSync(endDownload[3]);
// Wait for upload to complete
CPUWait(endUploadValid);
glWaitSync(endUpload)[0]);
// Bind render target
glFramebufferTexture(playTex[3]);
// Bind video capture source texture
BindTexture(capTex[0]);
// Draw
// Signal next upload
startUpload[0] = glFenceSync(…);
CPUSignal(startUploadValid);
// Signal next download
startDownload[3] = glFenceSync(…);
CPUSignal(startDownloadValid); | // Playout thread
CPUWait(startDownloadValid);
glWaitSync(startDownload[2]);
// Readback
glGetTexImage(playTex[2]);
// Read pixels to PBO
// Signal download complete
endDownload[2] = glFenceSync(…);
CPUSignal(endDownloadValid); |
:)
Yes it is. Just use SharedDrawables for the capture and playout threads. SharedDrawable will probably go away in 3.0, you'll have direct access to the GL contexts and you'll be able to share objects with the main thread context.
Quote from: abcdef on November 08, 2012, 17:21:43Also the library currently has graphics, sound and parallel computing CL area's. But it doesn't have video (like xuggler), physics (as above), and probably some others. Is the plan to build out the area's LWJGL covers or to keep it to its core of opengl/al/cl?
Absolutely core only. One persons JBullet is another person's "YOU'RE DOING PHYSICS ALL WRONG!!!". Just look at the ridiculous situation with JogAmp for an example :) Let people maintain other libraries on top of LWJGL, not bundle them.
Cas :)
I have one request for the windowing api. Make it possible to get or calculate the screen space rectangle of the opengl canvas. For example by exposing the position and size of the of the window and the insets of the frame. We use head tracking with a large back projected wall at work. The location of the canvas on screen is needed to calculate the correct view frustum.
Support for multiple windows are also welcome as it makes it possible to setup a CAVE.
Quote from: tomb on November 09, 2012, 11:02:12
I have one request for the windowing api. Make it possible to get or calculate the screen space rectangle of the opengl canvas. For example by exposing the position and size of the of the window and the insets of the frame. We use head tracking with a large back projected wall at work. The location of the canvas on screen is needed to calculate the correct view frustum.
With LWJGL, you can get the size of the Display (since LWJGL 2.8.0) by using Display.getWidth() and Display.getHeight(), and you can get the position of the Display (since LWJGL 2.8.4) by using Display.getX() and Display.getY(), now sure if that is what you need or are asking?
The getX() and getY() return the position of the window's corner, not the corner of the rendering area.
Quote from: CodeBunny on November 09, 2012, 13:35:16
The getX() and getY() return the position of the window's corner, not the corner of the rendering area.
hmm, true, one quick trick you could use, grab the LWJGL Mouse location on the Display (Mouse.getX() and getY() this will be relative to the rendering area with (0,0) being top left corner of the rendering area). At the same time grab the screen position of Mouse (java.awt.MouseInfo.getPointerInfo().getLocation().getX() and getY() being relative to the screen top left being 0,0) and the Display position (Display.getX() and getY()). From these 3 points you can calculate the top left inset of the Display window.
Anyway better avoid derailing thread :)
Quote from: kappa on November 08, 2012, 15:33:316) There should still be some sort of offscreen capability in the LWJGL core, maybe something based on FBO (possibly with a pbuffer fallback)? That way we can just grab the texture and write utilities to support all other windowing systems. Just pass the offscreen texture to AWT (Volatile Image), JavaFX, SWT, etc.
See the attachment. :)
Wow, really cool, how did you do that? (technically) :o
There's a WritableImage class in JavaFX since 2.2, which you can modify through a PixelWriter. PixelWriters accept ByteBuffers, so it's straightforward to do a ReadPixels and then directly update the JavaFX image. With the proper thread synchronization of course.
The JavaFX window draws the image, a JavaFX Canvas on top with some 2D shapes, then applies a reflection effect. It runs great on my machine, ~350 fps with -Djavafx.animation.fullspeed=true, perfectly smooth 60 fps at 10% CPU without it.
I'll try to use an offscreen context now with FBOs and double buffered read backs (with glGetTexImage).
I'd be happy to help with a utils library; I've already started working on a minimal one (https://github.com/mattdesl/lwjgl-basics).
@spasi - if this offscreen stuff works out then LWJGL Core could be super streamlined, simple and slick, supporting just native Display and Offscreen mode.
We'd just need a small utility class using Offscreen mode to added support for any framework (would even work on the super problematic OS X AWT Applet Mode). All the AWT, AWTGLCanvas, Display.setParent() stuff could be thrown out of the core.
Main overhead to this approach is transferring the OpenGL texture data to the target framework but if this is small enough could be easy to over look (may even be possible to pass a pointer in some situations without a copy).
Offscreen mode could also be very useful in other situations too like rendering directly to a frame buffer on a Raspberry PI without needing to start X or even just used as a utility in games to Render to Texture.
OK, this looks very promising, at least for JavaFX. Results for a plain image in a JavaFX scene without anything else:
- 300x300: ~7500 fps (the size in the screenshot above)
- 720p: ~930 fps
- 1080p: ~370 fps
I created a 1x1 pbuffer as the offscreen context, an FBO for rendering and asynchronous PBO (double-buffered) for read-backs. Using Renderbuffers/ReadPixels is faster than render-to-texture/GetImage on my setup, but we can support either way. I used a CountDownLatch for synchronization between the render thread and the JavaFX application thread.
Getting rid of protected/private qualifications would be MASSIVELY good: It would be so much easier to alter small details or leverage components of the library without having to recompile the entire thing, use reflection, or copy/paste reams of code. Let the programmer have the burden of not screwing things up: If we muck about with things we don't understand, and it fails, then too bad for us.
It's fine to require a higher GL version, but I'd prefer the GL classes not be merged (or else, be merged but have the un-merged ones still available). The current GL11..GL43 naming system is useful for more than just targetting a GL version: It's also useful for keeping track of which versions of GL features are in, and walking back and forth through the specs in my head. It's also nice to be able to simply open up GLxx.java and grok through it for reminders without having to sort through dozens of pages of stuff.
Princec converted me: I also vote for super-streamlined bare-metal core with no added stuff, and the rest can be third-party additional layers.
I finally vote against changing the name from lwjgl, since my fingers have now become used to typing that and seeing it, and I dislike change. :P
Changing the name of LWJGL will be a big mistake, IMHO.
Cas :)
The name will not change.
@spasi looks like very good results, is it possible to use FBO's with an offscreen context without pbuffer involvement? (since pbuffers are depreciated).
Certainly looks equally trivial to implement for AWT using a VolatileImage or BufferedImage.
As both AWT and JavaFX have OpenGL pipelines (where detected) we could also investigate using a shared context and then with a bit of reflection voodoo simply replace the textureID to the OpenGL texture inside an AWT BufferedImage (or that of the equivalent in JavaFX). That way we avoid the copy overhead altogether, certainly looks plausible from a quick glance at the Java2D code.
Quote from: kappa on November 12, 2012, 13:30:03is it possible to use FBO's with an offscreen context without pbuffer involvement? (since pbuffers are depreciated).
Yes, I think most people create a hidden window and create a normal GL context on that. This is not possible in LWJGL atm, but hopefully will be in 3.0. That way we can get rid of pbuffers altogether.
Quote from: kappa on November 12, 2012, 13:30:03As both AWT and JavaFX have OpenGL pipelines (where detected) we could also investigate using a shared context and then with a bit of reflection voodoo
Voodoo is certainly possible, even without a GL pipeline. For example, JavaFX uses ByteBuffers internally for Image data. We could do a glMapBuffer and inject the returned buffer instance in JavaFX somehow, thus avoiding a copy when transferring data to/from GL.
I'm still working on this btw, but I'm focusing on getting the non-voodoo stuff right first. The streaming FBO is basically done and I'm now going the opposite direction, i.e. rendering a JavaFX node to an LWJGL texture. What I have now is Webkit textured on a quad, behind the 3D gears and all that displayed inside JavaFX. :)
I'll prepare a working demo and source bundle when it's complete.
Here are some of the things I would like to see changed:
1. I'm pretty keen that we completely separate all context management from all OpenGL binding stuff. I would like, ideally, that we provide an extremely lightweight context management interface that would enable us to use contexts from AWT, SWT, NEWT, and even SDL. There was some vague attempt at that with the design (I seem to recall attempting to make GLContext an opaque "handle" back in the day).
2. I want to have removed basically all the C code that we possibly can remove and go for a more SWT-like design of absolutely lightweight wrappers to native method calls. Thus each "platform" would have a single monolithic class of system API in it eg. Win32API, Linux32API, MacOS107API, etc. which would contain all the native methods we could possibly want and the utter minimum of native logic. Then write all the code in Java, implementing some fancy interfaces in the "service provider" factory pattern.
3. Reimplementation of all keyboard/mouse input to use JInput and remove the native code that currently handles it.
4. Output packaging. Please change the distribution to package everything in a single zip download.
Here are some things I would like to stay:
1. The separation of GL11/GL12/etc.
2. I don't really want to deprecate GL11/12/13; they are no trouble at all to keep and maintain and a remarkable amount of tutorial code still uses this stuff, not to mention the fact that old-style drivers (pre 3.3?) are all based on the foundations in GL11 anyway. Save it for LWJGL4.0 when old-style OpenGL is not just deprecated but actually removed from everyone's computers.
3. I am still keen on the original Display interface: it is extremely simple and user-friendly to use. I think we should keep it but ensure that the underlying implementation is actually based on whatever newfangled better design we have. Point advanced users at the underlying implementations; point people writing games, and n00bs, at the simple Display interface.
4. Likewise I am keen on retaining Mouse and Keyboard classes doing what they do. Again, advanced people can use JInput directly. The rest of use don't need any more.
Here are some things I would like to go:
1. All of lwjgl_util.jar
2. Applets. They are dead. Anyone still daft enough to be using applets in this day and age can stick with 2.8.x.
3. All the proprietary vendor extensions that aren't in use by at least all three of NVidia, ATI and Intel.
4. Security context stuff. See #2. No point without applets.
A good first step is deciding on the pure interfaces required.
Cas :)
@spasi - Oh nice, that sounds like super cool stuff, look forward to it.
Currently the OS X Java 7 implementation has rather flaky (not even sure it still works properly) support for AWT as most methods are now native Cocoa (The AWT stuff is currently just left over from the previous implementation).
So rather than spending time trying to reimplement the AWT stuff for the LWJGL 2.9 release when its planned to be removed in 3.0, might be a better idea to strip all internal AWT use now and go pure Cocoa in readiness for 3.0.
We could then use your Offscreen to AWT stuff behind the current LWJGL OS X AWT API's to keep it backward compatible. Should serve as a nice testing ground while at the same time having the code ready (pending a bit of refactoring) for LWJGL 3.0.
@princec - replacing all input with JInput sounds like a cool idea (especially as it reduces the native code), however is JInput workable and good enough to replace input from the windowing system? does stuff like Keyboard localisation work? are there limitations of using JInput over input from the windowing system?.
If we do go with JInput for input I'd prefer the binaries be merged into the lwjgl ones rather than having to carrying around yet another jar and native for each platform, quite like the idea of the core being one jar, one native (for each platform). Might even be easier to just absorb JInput into lwjgl to allow consistent package names and allowing bugs to be fixed directly.
One jar and one native would be really nice from a development and distribution standpoint, especially for simple hobbyists like myself.
I was doubtful when you said pbuffers would go away, but as long as the windowing system is capable of a hidden window for an offscreen context, that meets my needs for context sharing.
I like the simplicity of having an optimized Display and then all other windowing systems are implemented on top of texture transfer.
I just posted a working demo of the JavaFX integration (http://www.java-gaming.org/topics/lwjgl-javafx-integration/27801/view.html), on JGO for more visibility. Please test and report any issues.
I updated the post on JGO with a new build and more info. I'll be trying AWT integration next. I could really use more test results though, especially on nvidia GPUs.
Another thing we might want to consider for LWJGL3 is using two threads for the native Display, one for only rendering and the other for window events, input, etc. This would be transparent to the library users as its an internal change and would allow for smoother rendering (i.e. no time spent on input polling, window events, etc on the rendering thread) and would allow for rendering/game loop to continue without being blocked when doing stuff like moving and resizing the Display window.
Progress update:
I just created the first window using the API that's generated through the new code generator. And it's all Java code!
public void testCreateWindow() {
final ByteBuffer wndClassEx = WNDCLASSEX.malloc();
WNDCLASSEX.cbSize(wndClassEx, WNDCLASSEX.SIZEOF);
WNDCLASSEX.style(wndClassEx, CS_OWNDC);
WNDCLASSEX.lpfnWndProc(wndClassEx, WindowsPlatform.getDefWindowProc());
WNDCLASSEX.cbClsExtra(wndClassEx, 0);
WNDCLASSEX.cbWndExtra(wndClassEx, 0);
WNDCLASSEX.hInstance(wndClassEx, WindowsPlatform.getHINSTANCE());
WNDCLASSEX.hIcon(wndClassEx, nLoadIcon(0, IDI_APPLICATION));
WNDCLASSEX.hCursor(wndClassEx, nLoadCursor(0, IDC_ARROW));
WNDCLASSEX.hbrBackground(wndClassEx, 0);
WNDCLASSEX.lpszMenuName(wndClassEx, 0);
WNDCLASSEX.lpszClassName(wndClassEx, memAddress(memEncodeUTF16("LWJGL")));
WNDCLASSEX.hIconSm(wndClassEx, 0);
final short classAtom = RegisterClassEx(wndClassEx);
assertTrue(classAtom != 0);
final long hwnd = CreateWindowEx(
WS_EX_APPWINDOW,
memEncodeUTF16("LWJGL"),
memEncodeUTF16("LWJGL Test"),
WS_OVERLAPPED | WS_BORDER | WS_CAPTION | WS_MINIMIZEBOX | WS_SYSMENU | WS_CLIPCHILDREN | WS_CLIPSIBLINGS,
0, 0, 640, 480,
0, 0, WindowsPlatform.getHINSTANCE(), 0
);
assertTrue(hwnd != 0);
ShowWindow(hwnd, SW_SHOWDEFAULT);
DestroyWindow(hwnd);
}
So, the first milestone is complete, we can now create bindings to arbitrary OS-specific APIs. We also generate "struct classes" that take care of setting up ByteBuffer in a way that the system call understands (WNDCLASSEX in the above example). It supports any primitive value, pointer values (automatically cast to 32 or 64 bits at runtime) and also nested structs. All the struct member offsets are discovered at runtime from auto-generated native code.
The Generator Kotlin-based DSL looks like this:
// A simple type
val DWORD = PrimitiveType("DWORD", PrimitiveMapping.INT)
// A struct type definition
val LPGLYPHMETRICSFLOAT = StructType(
name = "LPGLYPHMETRICSFLOAT",
includesPointer = true,
definition = struct(WINDOWS_PACKAGE, "GLYPHMETRICSFLOAT") {
nativeImport ("WindowsLWJGL.h")
FLOAT _ "gmfBlackBoxX"
FLOAT _ "gmfBlackBoxY"
POINTFLOAT _ "gmfptGlyphOrigin" // Nested struct
FLOAT _ "gmfCellIncX"
FLOAT _ "gmfCellIncY"
}
)
// A Windows function
HWND.func("CreateWindowEx") {
DWORD IN "exStyle"
LPCTSTR IN "className"
LPCTSTR IN "windowName"
DWORD IN "style"
int IN "x"
int IN "y"
int IN "width"
int IN "height"
HWND IN "parent"
HMENU IN "menu"
HINSTANCE IN "instance"
LPVOID IN "param"
}
// A WGL function
BOOL.func("wglMakeCurrent") {
HDC IN "device"
HGLRC IN "context"
javaDoc {
"""
Makes a specified OpenGL rendering context the calling thread's current rendering context.
All subsequent OpenGL calls made by the thread are drawn on the device identified by device.
You can also use wglMakeCurrent to change the calling thread's current rendering context so it's no longer current.
"""
}
}
The next milestone will be adding support for context/device specific functions. Once that's done, I'll create the 3.0 branch and start accepting contributions.
Quote from: kappa on November 12, 2012, 17:31:19
@princec - replacing all input with JInput sounds like a cool idea (especially as it reduces the native code), however is JInput workable and good enough to replace input from the windowing system? does stuff like Keyboard localisation work? are there limitations of using JInput over input from the windowing system?.
If we do go with JInput for input I'd prefer the binaries be merged into the lwjgl ones rather than having to carrying around yet another jar and native for each platform, quite like the idea of the core being one jar, one native (for each platform). Might even be easier to just absorb JInput into lwjgl to allow consistent package names and allowing bugs to be fixed directly.
The JInput source scares the hell out of me. I would vote to
not use it, or to do a rewrite as a real part of LWJGL.
Quote from: NateS on November 27, 2012, 10:35:27
The JInput source scares the hell out of me. I would vote to not use it, or to do a rewrite as a real part of LWJGL.
I also evaluated it and came to the same conclusion, a major point being that there is no way to get the mouse location using JInput, which can only be done by implementing native windowing code for the mouse which would again bring us back to the current situation.
Another limitation is lack of hot-plug support of controllers, as far as I've been able to determine.
The one thing I would definitely not like to see go would be the utility package, from what I can tell from LWJGL's name, it's not a graphics library but a game library. For me, one of the greatest benefits of LWJGL was its inclusion of simple vector, matrix, etc, classes, which are necessary parts of game development.
I understand that there are plenty of other Math libraries out there, but the convenience of having one included in the library and not having to find java bindings for another makes a massive difference. It's the same thing with other game libraries such as XNA, it's very easy to create a new project and have something rendered on the screen in a matter of minutes, rather than having to spend a few hours finding a math library that does everything you need and then finding/making java bindings for it.
Just my two cents, but I think removing the utility package would move LWJGL closer to JOGL, and I chose LWJGL for the very reason that it was focused on game development, not just an OpenGL java binding.
It depends on what LWJGL wants to be. I personally would prefer if LWJGL didn't try to solve too many problems. Including a utils package makes it a bit of a junk drawer. There are all kinds of things it *could* have that aren't related to the core problems it solves.
I use libgdx, which uses LWJGL on the desktop, and I delete the entire LWJGL util package from the JAR because I don't use any of it. libgdx has vector, matrix, quaternion, collections classes, and more.
Knowing the util library is deprecated, and having some other things missing that full game libraries have, has actually forced me to write better code, as well as understanding what that code really does. OpenGL's simplification has done the same thing: Being forced to use VBOs/VAOs for everything, and having no client-side matrix transformation whatsoever, has taken entire layers off of my code and streamlined it immensely, simply because I was forced to think about what I was doing instead of simply using function calls as I felt like.
LWJGL is mirroring OpenGL in the sense that it wants to be a facilitation, not a solution: LWJGL is not like a transit system, but more like a road: It doesn't simply take you from A to B, but rather provides a way for you to get from A to B yourself, and though that leads to fewer people using it due to lack of all-around utility (the same reason many use DX instead of GL, because DX is like a Swiss-army knife), in the end, it leads to better things.
Quote from: jakj on November 29, 2012, 00:21:34
Knowing the util library is deprecated, and having some other things missing that full game libraries have, has actually forced me to write better code, as well as understanding what that code really does. OpenGL's simplification has done the same thing: Being forced to use VBOs/VAOs for everything, and having no client-side matrix transformation whatsoever, has taken entire layers off of my code and streamlined it immensely, simply because I was forced to think about what I was doing instead of simply using function calls as I felt like.
LWJGL is mirroring OpenGL in the sense that it wants to be a facilitation, not a solution: LWJGL is not like a transit system, but more like a road: It doesn't simply take you from A to B, but rather provides a way for you to get from A to B yourself, and though that leads to fewer people using it due to lack of all-around utility (the same reason many use DX instead of GL, because DX is like a Swiss-army knife), in the end, it leads to better things.
I suppose you have a point there, but LWJGL is (for me) a way to develop games without having to worry about different Math implementations, similar to Unity (albeit with a lower-level feature set) or XNA. I first started Java programming just over a year ago, and I used LWJGL as a way to apply what I learnt. I didn't have to install Math libraries, I didn't have to worry about handling input, and all of this definitely helped me making small and relatively big games.
If it were to lose its utility package (including Maths, Input, etc), then it would be nothing more than a clone of JOGL, which is
not a game library, and I'm finding it hard to believe that such a change would attract newcomers, and if anything we want to be encouraging a growing user base.
Regarding moving the utility package over to a separate project, I have no arguments against this, but what I would at least like to see is some form of integration (e.g. LWJGL and util in one distribution), so new users can get started quickly.
Quote from: MattCa on November 29, 2012, 21:34:33Regarding moving the utility package over to a separate project, I have no arguments against this, but what I would at least like to see is some form of integration (e.g. LWJGL and util in one distribution), so new users can get started quickly.
This is what will most likely happen in 3.0.
What's going to happen to the Display class in 3.0?
As I've said before, an Object-Oriented Display API would be really, really nice (http://lwjgl.org/forum/index.php/topic,4511.msg24269.html#msg24269 (http://lwjgl.org/forum/index.php/topic,4511.msg24269.html#msg24269)).
The LWJGL 3 repo is up, here (https://github.com/LWJGL/lwjgl3). There's nothing usable in there yet, but the generator is almost feature complete for the OpenGL API. Everything in GL11 has been implemented and there's API parity with 2.x, minus a few signature fixes and cleanups.
The most important new feature since my last post is support for Javadoc generation. Currently the generator requires that every function/parameter template comes with a description and I did my best to document everything in GL11, including enum lists and links from one function to another. Most of it is simple descriptions from the GL spec, but I tried to add extra info for the more important/often-used functions. I'm hoping that this will make LWJGL easier to use and we won't have to leave our IDEs as often to go look for info in the GL/extension specs. This is what it currently looks like in my IDE:
(http://i45.tinypic.com/xofktv.jpg)
For contributors: To get a glimpse of what the new generator provides and what the internals of 3.0 might look like, see the following two classes:
- org.lwjgl.system.windows.WindowsDisplay in src/core/
- org.lwjgl.demo.windows.WGLDemo in src/tests/
awesome!I don't have much time right now - but at a cursory glance, I like what I see :)
The kotlin stuff and the native handling looks a lot better.
Are you confident that we can handle al and cl, as easily too?
compiling:
compile:
[Core java compilation] Compiling 45 source files to J:\Work\programming\Personal\lwjgl3\bin\Core
[Core java compilation] J:\Work\programming\Personal\lwjgl3\src\core\org\lwjgl\system\MathUtil.java:7: cannot find symbol
[Core java compilation] symbol : class ThreadLocalRandom
[Core java compilation] location: package java.util.concurrent
[Core java compilation] import java.util.concurrent.ThreadLocalRandom;
[Core java compilation] ^
[Core java compilation] J:\Work\programming\Personal\lwjgl3\src\core\org\lwjgl\system\MathUtil.java:27: cannot find symbol
[Core java compilation] symbol : variable ThreadLocalRandom
[Core java compilation] location: class org.lwjgl.system.MathUtil
[Core java compilation] return ThreadLocalRandom.current().nextInt(range + 1);
[Core java compilation] ^
[Core java compilation] 2 errorsDo we require Java 7 now?
compile-templates also seemed kinda slow?
QuoteTotal time: 19 seconds
- on a pretty fast machine
Although I am a big fan of 'use-the-source-luke', I think that we need to also spend some time documenting the templates processing so that it is easier to work with, unlike the old apt.
Also, I assume the WGLDemo is just a display of raw
windows usage, more so than the expected API for creating a window?
That is, we will add the current'
ish API on top of the raw platform api.
Anyhow, I'll look more at this later - just wanted to shoot some comments on your work.
Quote from: Matzon on December 24, 2012, 10:01:05Are you confident that we can handle al and cl, as easily too?
Very.
Quote from: Matzon on December 24, 2012, 10:01:05Do we require Java 7 now?
No, we don't. It's a leftover from some tests I'd been doing, not used anymore.
Quote from: Matzon on December 24, 2012, 10:01:05compile-templates also seemed kinda slow?
QuoteTotal time: 19 seconds
- on a pretty fast machine
That's because of kotlinc. Kotlin is still a work in progress and compilation performance is pretty bad at this time. Their goal is to match javac performance for the final version, so I'm hoping that the situation will improve rapidly (JetBrains has started using it in production since the last milestone). The code generation itself takes ~1 second with a clean cache.
Quote from: Matzon on December 24, 2012, 10:01:05Although I am a big fan of 'use-the-source-luke', I think that we need to also spend some time documenting the templates processing so that it is easier to work with, unlike the old apt.
Yes, I'll try to fully document it once it's stable.
Quote from: Matzon on December 24, 2012, 10:01:05Also, I assume the WGLDemo is just a display of raw windows usage, more so than the expected API for creating a window?
That is, we will add the current'ish API on top of the raw platform api.
Exactly. So, for example, the WindowsDisplay class would be an implementation of the cross-platform Display in the public API layer. It also showcases how one could circumvent all LWJGL code and go straight to the native APIs, for custom solutions, etc.
Thank you spasi for the Javadocs! This makes it much easier for those of us who aren't greatly familiar with GL. Is it from https://anonymous:anonymous@cvs.khronos.org/svn/repos/ogl/trunk/ecosystem/public/sdk/docs/man4/xhtml/ (https://anonymous:anonymous@cvs.khronos.org/svn/repos/ogl/trunk/ecosystem/public/sdk/docs/man4/xhtml/)? I was looking into a conversion process for this but it is above my abilities.
Also, I would like to suggest/request/beg that Applet support not be dropped. Browser support, even with an older technology (Isn't it a new implementation with JavaFX?) is very important, Java has almost as much market share as Flash and the technology is superior IMO. I feel this is one of the stronger points of LWJGL.
That JavaFX application is awesome, by the way!
Most of it is from the official OpenGL spec. I'm using a few bits and pieces from the khronos man pages where it makes sense, but it tends to be too verbose for javadoc and it also covers the Core profile functions only. In a newer build I'm auto-generating a link to the xml files for the core functions, you can click on it from inside the IDE to open a browser and read the full documentation. For deprecated functions I'm also generating a warning: This function is deprecated and unavailable in the Core profile. For extensions, I've added a url to the extension spec on the class javadoc.
Don't forget that some of us don't use IDEs. :P All I mean is, while it's fine for the information/notation to be optimized for IDE use, it should still be parseable by a human being at need.
Well it's just javadoc, so it's as human readable as javadoc can get. Here (http://pastebin.com/GixFXx10)'s a preview of GL11 in 3.0.
Quote from: spasi on December 30, 2012, 13:52:52
Here (http://pastebin.com/GixFXx10)'s a preview of GL11 in 3.0.
That looks great. I'm excited for 3.0.
I second that. I would settle for the javadocs alone, they will make this immensely more enjoyable, but with everything else rolling out in 3.0: wow. Thankyou so much for this.
I have two features I'd like to suggest. Not sure how difficult or feasible they would be to implement in the new display API.
1. No flickering on resize. This would make LWJGL games and especially apps (like Spine) a little more polished.
2. Basic drag and drop support. Especially files. Dragging and dropping files is IMHO a hundred times easier than dealing with file choosers -- especially if you have to use a file chooser like JFileChooser (eugh...) or TWL's. As LWJGL becomes a more popular choice for software apps (like Spine, 3D model viewers, etc), drag and drop seems appropriate.
3.0 does look promising indeed.
I'm especially looking forward to the integration with JavaFX (or any other windowing system with the help of offscreen rendering)
I started a thread about it on JGO with gouessej (JOGL)
http://www.java-gaming.org/topics/jogl-in-javafx/26881/view.html
Hello.
I ask, no, I beg you guys to do something to enable multisampling/antialiasing capable device contexts for SWT. Hell, SWT´s GLCanvas is just a horrible mess (sobs...).
https://bugs.eclipse.org/bugs/show_bug.cgi?id=136514 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=136514)
Could there be a clean way to use LWJGL with SWT? For good or bad, I think SWT is one of the fastest GUI frameworks Java has to offer. I admit though I have yet to explore JavaFX in depth, but as far as implementing generic User Interface controls in applications, SWT gets the job done.
Actually, I think the JOGL folks went ahead and implemented their own GLCanvas!
https://jogamp.org/bugzilla/show_bug.cgi?id=484 (https://jogamp.org/bugzilla/show_bug.cgi?id=484)
Second thing, NVIDIA Optimus support. I believe it was mentioned that this was a planned feature for LWJGL 3 so I'm a happy groundhog.
Lastly, in the long run, if the intention is to truly modularize LWJGL, I would highly recommend adopting Gradle as a build system.
http://gradle.org (http://gradle.org)
Of course it's not a trivial task by any means, but I've used it in very large code bases at my job and it truly works. Other large Java projects use it too (Spring, Hibernate and Tapestry). For example:
https://community.jboss.org/wiki/GradleWhy?_sscc=t (https://community.jboss.org/wiki/GradleWhy?_sscc=t)
I thank you for this very cool library, and if I can do anything to improve it, let me know.
Cheers!
Progress update:
- LWJGL 3.0 now supports AL and CL in addition to GL. The first two are basically done, but we still need to add the OpenGL extensions we support in 2.x. There will be some filtering (obsolete extensions, etc), but it still is loads of work, especially documenting everything. Contributions on this would be very welcome! At the very least we'll need all ARB extensions and the latest EXT, AMD and NV ones. We can add more as needed after 3.0 is released.
- Support for the first windowing back-end is in, which is GLFW (http://www.glfw.org/). It has most of the features we require, but it's also a work-in-progress (GLFW 3.0 is a rewrite, like LWJGL 3.0). Please consider anything related to the windowing system experimental. We might end-up dropping it if we find a better alternative.
The screenshot below shows one of the demos in the LWJGL 3.0 repo. It highlights one of the most important features in 3.0: multiple, resizable windows. Each window has its own OpenGL context. Both fractals are being rendered with OpenCL, the first on the GPU and the second on the CPU.
(http://i47.tinypic.com/v5fk20.png) (http://oi50.tinypic.com/evc3f6.jpg)
Great information here. I am really looking forward to javaFx, (and already postet there, before I knew that you are from the LWJGL team). Also do I like the idea of a GLCore class.
Edit:
Finally I did try to download and compile LWJGL 3.0, but it did not compile. At first It took more than a minute to Generate and at some time I always ended in an out of memory exception. Can't explain why 4GB should be ok?
Then most interesting I think is that LWJGL uses Kotlin internally. So as a Scala developer I am interested weather Kotlin has great benefits compared to Scala. From what I've seen so far Kotlin is very close to Scala, but not so functional as Scala. But all my experience come from examples from the internet.
This sounds great! I am looking forward to this soo much. Thank you guys for your awesome work.
LWJGL 3 now has a dedicated Wiki (https://github.com/LWJGL/lwjgl3/wiki).
It is not complete, but it has important information that I felt should readily be available to potential users and contributors. Please let me know if you'd like anything fixed, if something requires better explanation or if I've missed an important aspect of the project that deserves to be documented.
Recent changes:
- OS X is now supported.
- Updated GLFW to v3.0.3.
- Added JavaDoc generation.
- Added libffi (https://sourceware.org/libffi/) bindings.
- The required minimum JDK version is now 7.
- Many fixes and improvements to code generation & documentation.
The wiki now has a long to-do list, so there's plenty more work to be done. The current plan is to wait for GLFW 3.0.4 (contains many important fixes) and then we'll release an alpha build for all platforms. If you'd like to try it out sooner, feel free to clone the project and build manually, I've tried to make it as easy as possible. If you encounter any issues, please do let me know.
Just curious, will the wiki be transcribed to the actual wiki? Or do you intend to stick with the Github Wiki?
Any information related to the development, especially important details useful to contributors, will likely stay on Github. Everything else could be copied/moved to the official wiki.
I have a problem while compiling.
Here is my log:
Buildfile: C:\Users\jeroe_000\git\lwjgl3\lwjgl3\build.xml
-initialize:
-dependencies-uptodate:
check-dependencies:
compile-templates:
[Templates] Compiling Kotlin templates. This will take several seconds...
-generated-uptodate:
generate:
compile:
compile-tests:
compile-native:
compile-native-windows:
BUILD FAILED
C:\Users\jeroe_000\git\lwjgl3\lwjgl3\build.xml:187: The following error occurred while executing this line:
C:\Users\jeroe_000\git\lwjgl3\lwjgl3\config\windows\build.xml:33: Execute failed: java.io.IOException: Cannot run program "cl" (in directory "C:\Users\jeroe_000\git\lwjgl3\lwjgl3\bin\lwjglx86"): CreateProcess error=2, The system cannot find the file specified
Total time: 36 seconds
The folder "C:\Users\jeroe_000\git\lwjgl3\lwjgl3\bin\lwjglx86" indeed has nothing in it.
I couldn't find much about it online. If anyone could help me that would be great.
You need to properly configure a C compiler to build LWJGL. The only tested (and officially supported) compiler at the moment is MSVC. The easiest way to set it up is:
- Download Visual Studio Express (http://www.visualstudio.com/en-US/products/visual-studio-express-vs) (for Windows Desktop) and install it.
- Run VC's vcvarsall.bat script from the command line, passing the appropriate architecture argument. The JVM used to run ant is the one that determines the architecture for the current build. If a x86 JVM is used, use "vcvarsall x86". If a x64 JVM is used, use either "vcvarsall x64" or "vcvarsall x86_amd64" (cross-compiler). The native x64 compiler is available on VS Professional or better, while the Express edition contains only the cross-compiler.
You should be good to go after that.
Thanks!
I will try to get it to work. I'm new to building with ant and native languages so hopefully i'll get it to work.
So far i got the native compiling to work but now i have problems on -link.
Im on a NVIDIA Gpu btw, so if you are still in need of some test results on those i would love to give my feedback.
Also do you have any idea on when lwjgl 3.0 will have downloadable jars available?
Right now we have a big hole to fill; support for the OpenGL extensions we have in LWJGL 2. We'll drop a lot of them (there are many obsolete that no one uses), but it's still a lot of work to port everything. When that's done, we'll have a beta release that everyone will be able to try. Can't promise anything time-wise, without external help at least, because there are more important issues I'll have to work on first.
Ah okay yeah i understand.
I would love to help but i unfortunately have no C experience just some c++, and no JNI experience at all.
Looking forward to the release though, my last project was with GLFW and multiple windows is one awesome future i was missing in lwjgl.
Good luck with creating 3.0.
LWJGL 3 has been designed to not require any C coding at all and only minimal understanding of how C works (the same experience you'd need to use OpenGL). The only functionality that needs manual coding is callbacks, which in terms of OpenGL means a handful of extensions (the debug_output ones). Everything else can be implemented using the Generator and tested using plain Java code. More details can be found in the wiki (https://github.com/LWJGL/lwjgl3/wiki), under the Contribute section.
Have you tried testing LWJGL 3 with tools like Avian or RoboVM yet? There's one discussion about it on the RoboVM forum. Seems it's not quite there yet:
https://groups.google.com/forum/#!topic/robovm/p3HJisndt-4 (https://groups.google.com/forum/#!topic/robovm/p3HJisndt-4)
Also, I haven't been able to find much about your reasoning for using Kotlin. Would be nice if there was a write-up about it on the wiki. Was it chosen mainly for the sake of convenience, or do you have some bigger plans for Kotlin's special features like the JavaScript interoperability?
That discussion is about Kotlin. LWJGL 3 only uses Kotlin for the code generator, which is a purely "offline" process that produces plain Java and C code. The rest of the project is pure Java and compiled using javac. I don't know if Kotlin interacts badly with Avian/RoboVM, but in any case, we don't have a runtime dependency to it.
Quote from: spasi on March 05, 2014, 10:38:19
That discussion is about Kotlin. LWJGL 3 only uses Kotlin for the code generator, which is a purely "offline" process that produces plain Java and C code. The rest of the project is pure Java and compiled using javac. I don't know if Kotlin interacts badly with Avian/RoboVM, but in any case, we don't have a runtime dependency to it.
Okay great, that's exactly what I wanted to know, thanks!
I got this error when trying to compile LWJGL3 from source on OS X 10.9.1, any idea what's wrong? Let me know if you need more information!
compile-native-macosx:
[SDK Root] /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
[Compiler] /Users/anten/git/lwjgl3/generated/native/opencl/org_lwjgl_opencl_CL20.c:10:96: fatal error: unknown type name 'cl_pipe_properties'; did you mean 'cl_context_properties'?
[Compiler] typedef cl_mem (APIENTRY *clCreatePipePROC) (cl_context, cl_mem_flags, cl_uint, cl_uint, const cl_pipe_properties *, cl_int *);
[Compiler] ^~~~~~~~~~~~~~~~~~
[Compiler] cl_context_properties
[Compiler] /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/OpenCL.framework/Headers/cl.h:62:29: note: 'cl_context_properties' declared here
[Compiler] typedef intptr_t cl_context_properties;
[Compiler] ^
[Compiler] 1 error generated.
BUILD FAILED
/Users/anten/git/lwjgl3/build.xml:187: The following error occurred while executing this line:
/Users/anten/git/lwjgl3/config/macosx/build.xml:111: apply returned: 1
I just have 2 questions:
- theres a lot of talk about using JavaFX with LWJGL, will I still be able to use normal java? I cannot get JavaFX working on eclipse
- how much of the API will change? Will I have to recode everything?
Sorry if someone has already asked these questions on this topic, I didn't read all the pages (So many!)
Quote from: cebarks on March 22, 2014, 00:09:08I got this error when trying to compile LWJGL3 from source on OS X 10.9.1, any idea what's wrong? Let me know if you need more information!
I've seen the issue on Github, will try to fix soon.
Quote from: matanui159 on March 22, 2014, 00:45:09I just have 2 questions:
- theres a lot of talk about using JavaFX with LWJGL, will I still be able to use normal java? I cannot get JavaFX working on eclipse
- how much of the API will change? Will I have to recode everything?
1) JavaFX integration, if possible, will be optional.
2) Most of the OpenGL/CL/AL APIs will remain the same. The windowing and input APIs will be completely different, so you'll have to re-implement those.
Quote from: spasi on March 22, 2014, 09:58:43
Quote from: cebarks on March 22, 2014, 00:09:08I got this error when trying to compile LWJGL3 from source on OS X 10.9.1, any idea what's wrong? Let me know if you need more information!
I've seen the issue on Github, will try to fix soon.
Quote from: matanui159 on March 22, 2014, 00:45:09I just have 2 questions:
- theres a lot of talk about using JavaFX with LWJGL, will I still be able to use normal java? I cannot get JavaFX working on eclipse
- how much of the API will change? Will I have to recode everything?
1) JavaFX integration, if possible, will be optional.
2) Most of the OpenGL/CL/AL APIs will remain the same. The windowing and input APIs will be completely different, so you'll have to re-implement those.
Ok, thanks :)
If i do get JavaFX working on eclipse how would it work? (Again I haven't looked through the whole topic)
Would it be the same with AWT where you bind it to a canvas or something?
Or will it be different?
Quote from: matanui159 on March 22, 2014, 12:28:01If i do get JavaFX working on eclipse how would it work? (Again I haven't looked through the whole topic)
Would it be the same with AWT where you bind it to a canvas or something?
Or will it be different?
Hard to say at this point. Java 8 has shipped without any changes to JavaFX that would make integration easier (or with decent performance). Depending on what happens in the future, the integration could be simple from the user perspective (with LWJGL handling all the details) and also fast (I think the best-case we can hope for is a single framebuffer copy + synchronization overhead).
Quote from: spasi on March 22, 2014, 09:58:43
Quote from: cebarks on March 22, 2014, 00:09:08I got this error when trying to compile LWJGL3 from source on OS X 10.9.1, any idea what's wrong? Let me know if you need more information!
I've seen the issue on Github, will try to fix
Awesome thank you!
Just one more question (sorry for so many questions, I'm making a game engine)
Will the Mac taskbar icon bug be fixed?
On mac if you don't set an icon it will show a java cup on paper (not the lwjgl icon)
And if you try to set an icon it will show the swing task bar icon
(http://www.ariscommunity.com/system/files/editor/image/arisexpress/java_icon.png)
I decided to try and get LWJGL 3 up-and-running for testing purposes, but it seems that I've hit a snag.
Firstly, I'd like to add here that the version of Ant Eclipse uses does NOT support Java 8 (as of 17.5.2014, Kepler SR2 with Java 8 patch). This may cause the build script to throw "Could not find class: javac1.8", or something along those lines, because it will try to use the default JRE (probably 1.8 ). To fix this issue: Right-click on the build script - Run as - Ant build... - JRE - and finally set it to use java 1.7. That should fix that issue.
I followed the somewhat lacking (suggest improving) documentation and guides posted here and on the lwjgl3 wiki:
Quote from: spasi on February 11, 2014, 16:13:13
You need to properly configure a C compiler to build LWJGL. The only tested (and officially supported) compiler at the moment is MSVC. The easiest way to set it up is:
- Download Visual Studio Express (http://www.visualstudio.com/en-US/products/visual-studio-express-vs) and install it.
- Run VC's vcvarsall.bat script from the command line, passing the appropriate architecture argument; x86 or x64, depending on which one you want to build.
You should be good to go after that.
Unfortunately this didn't work. The build script fails to run "cl" in the native bin folder (which is due to the C-compiler not configured correctly?).
E:\Eclipse\eclipse\Git\lwjgl3\config\windows\build.xml:33: Execute failed: java.io.IOException: Cannot run program "cl" (in directory "E:\Eclipse\eclipse\Git\lwjgl3\bin\lwjglamd64"): CreateProcess error=2In fact, the folder is entirely empty, and this is the same issue that user Jeroenimoo0 had (an older post in this thread).
I do not know whether I have failed to follow the few (seemingly easy) steps, or whether there are some steps that are missing. Given that the batch file does not seem to output anything unless a wrong architecture argument is passed (resulting in "The specified configuration type is missing."), it is hard for me to say if it has even done anything. I do not know what it should do, or even what the native bin folder should contain. I did, however, try to go through the various ant files in hopes of finding a lead.
So, basically, I need some help with this! :P
I also apologize if this is a bit too old thread to reply to.
EDIT: Corrected the order of two paragraphs.
Hey EnergyRay,
The instructions do not mention Eclipse and the repository does not include a properly configured Eclipse project yet (there's one only for IntelliJ so far). I'm not sure what the problem is exactly; do you run the ant targets from within Eclipse or via the command line? For now, my recommendation would be to run the "compile-templates" and "compile-native" targets from the command line, it should be easier to solve any issues.
A thing you should test is running "cl" on the command line after vcvarsall.bat. Is it available? If yes, "ant compile-native" should run just fine.
Hey, spasi!
I highly doubt Eclipse had anything to do with the problem. I ran Ant from command line just in case (however, this required me to change default jdk to 1.7, but I digress) which resulted in the exact same error as before.
Then I checked the "cl" command, and it wasn't recognized (there's the problem). I re-installed VS, which then fixed the issue (I don't know why).
Not making much progress:
compile-native-windows:
[Compiler] org_lwjgl_system_windows_WinBase.c
[Compiler] E:\LWJGL\lwjgl3\generated\native\system\windows\org_lwjgl_system_windows_WinBase.c(14) : error C2220: warning treated as error - no 'object' file generated
[Compiler] E:\LWJGL\lwjgl3\generated\native\system\windows\org_lwjgl_system_windows_WinBase.c(14) : warning C4996: 'GetVersionExW': was declared deprecated
[Compiler] C:\Program Files (x86)\Windows Kits\8.1\include\um\sysinfoapi.h(442) : see declaration of 'GetVersionExW'
BUILD FAILED
E:\LWJGL\lwjgl3\build.xml:187: The following error occurred while executing this line:
E:\LWJGL\lwjgl3\config\windows\build.xml:33: apply returned: 2
That is the output from the build script (specifically "compile-native" target) ran from command line. At least the ${bin.native} folder has a bunch of .obj files now...
Quote from: EnergyRay on May 19, 2014, 11:48:05
Hey, spasi!
I highly doubt Eclipse had anything to do with the problem. I ran Ant from command line just in case (however, this required me to change default jdk to 1.7, but I digress) which resulted in the exact same error as before.
Then I checked the "cl" command, and it wasn't recognized (there's the problem). I re-installed VS, which then fixed the issue (I don't know why).
Not making much progress:
compile-native-windows:
[Compiler] org_lwjgl_system_windows_WinBase.c
[Compiler] E:\LWJGL\lwjgl3\generated\native\system\windows\org_lwjgl_system_windows_WinBase.c(14) : error C2220: warning treated as error - no 'object' file generated
[Compiler] E:\LWJGL\lwjgl3\generated\native\system\windows\org_lwjgl_system_windows_WinBase.c(14) : warning C4996: 'GetVersionExW': was declared deprecated
[Compiler] C:\Program Files (x86)\Windows Kits\8.1\include\um\sysinfoapi.h(442) : see declaration of 'GetVersionExW'
BUILD FAILED
E:\LWJGL\lwjgl3\build.xml:187: The following error occurred while executing this line:
E:\LWJGL\lwjgl3\config\windows\build.xml:33: apply returned: 2
That is the output from the build script (specifically "compile-native" target) ran from command line. At least the ${bin.native} folder has a bunch of .obj files now...
I'm having this same issue also, same error and everything. Tried it on multiple windows installs so I'm not sure what's wrong.
Yes, sorry, I haven't updated to the latest VS yet. I pushed a (temporary) fix, please do a git pull, then try again.
Making progress, but the script is still failing...
tests:
BUILD FAILED
E:\LWJGL\lwjgl3\build.xml:208: Problem: failed to create task or type testng
Cause: The name is undefined.
Action: Check the spelling.
Action: Check that any custom tasks/types have been declared.
Action: Check that any <presetdef>/<macrodef> declarations have taken place.
New error
Buildfile: C:\Users\Anten\git\lwjgl3\build.xml
-initialize:
-dependencies-uptodate:
check-dependencies:
compile-templates:
[Templates] Compiling Kotlin templates. This will take several seconds...
-generated-uptodate:
generate:
compile:
compile-tests:
compile-native:
compile-native-windows:
-link:
[Linker] Creating library lwjgl64.lib and object lwjgl64.exp
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwInit referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwInit@8
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwTerminate referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwTerminate@8
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwGetVersion referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwGetVersion@32
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwGetVersionString referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwGetVersionString@8
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwSetErrorCallback referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwSetErrorCallback@16
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwGetMonitors referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwGetMonitors@16
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwGetPrimaryMonitor referenced in function _Java_org_lwjgl_system_glfw_GLFW_glfwGetPrimaryMonitor@8
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwGetMonitorPos referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwGetMonitorPos@32
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwGetMonitorPhysicalSize referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwGetMonitorPhysicalSize@32
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwGetMonitorName referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwGetMonitorName@16
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwSetMonitorCallback referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwSetMonitorCallback@16
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwGetVideoModes referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwGetVideoModes@24
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwGetVideoMode referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwGetVideoMode@16
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwSetGamma referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwSetGamma@20
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwGetGammaRamp referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwGetGammaRamp@16
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwSetGammaRamp referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwSetGammaRamp@24
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwDefaultWindowHints referenced in function _Java_org_lwjgl_system_glfw_GLFW_glfwDefaultWindowHints@8
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwWindowHint referenced in function _Java_org_lwjgl_system_glfw_GLFW_glfwWindowHint@16
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwCreateWindow referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwCreateWindow@40
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwDestroyWindow referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwDestroyWindow@16
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwWindowShouldClose referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwWindowShouldClose@16
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwSetWindowShouldClose referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwSetWindowShouldClose@20
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwSetWindowTitle referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwSetWindowTitle@24
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwGetWindowPos referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwGetWindowPos@32
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwSetWindowPos referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwSetWindowPos@24
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwGetWindowSize referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwGetWindowSize@32
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwSetWindowSize referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwSetWindowSize@24
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwGetFramebufferSize referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwGetFramebufferSize@32
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwIconifyWindow referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwIconifyWindow@16
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwRestoreWindow referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwRestoreWindow@16
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwShowWindow referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwShowWindow@16
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwHideWindow referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwHideWindow@16
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwGetWindowMonitor referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwGetWindowMonitor@16
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwGetWindowAttrib referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwGetWindowAttrib@20
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwSetWindowUserPointer referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwSetWindowUserPointer@24
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwGetWindowUserPointer referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwGetWindowUserPointer@16
[Linker] org_lwjgl_system_glfw_WindowCallback.obj : error LNK2001: unresolved external symbol _glfwGetWindowUserPointer
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwSetWindowPosCallback referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwSetWindowPosCallback@24
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwSetWindowSizeCallback referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwSetWindowSizeCallback@24
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwSetWindowCloseCallback referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwSetWindowCloseCallback@24
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwSetWindowRefreshCallback referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwSetWindowRefreshCallback@24
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwSetWindowFocusCallback referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwSetWindowFocusCallback@24
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwSetWindowIconifyCallback referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwSetWindowIconifyCallback@24
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwSetFramebufferSizeCallback referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwSetFramebufferSizeCallback@24
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwPollEvents referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwPollEvents@8
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwWaitEvents referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwWaitEvents@8
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwGetInputMode referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwGetInputMode@20
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwSetInputMode referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwSetInputMode@24
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwGetKey referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwGetKey@20
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwGetMouseButton referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwGetMouseButton@20
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwGetCursorPos referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwGetCursorPos@32
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwSetCursorPos referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwSetCursorPos@32
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwSetKeyCallback referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwSetKeyCallback@24
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwSetCharCallback referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwSetCharCallback@24
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwSetMouseButtonCallback referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwSetMouseButtonCallback@24
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwSetCursorPosCallback referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwSetCursorPosCallback@24
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwSetCursorEnterCallback referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwSetCursorEnterCallback@24
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwSetScrollCallback referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwSetScrollCallback@24
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwJoystickPresent referenced in function _Java_org_lwjgl_system_glfw_GLFW_glfwJoystickPresent@12
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwGetJoystickAxes referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwGetJoystickAxes@20
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwGetJoystickButtons referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwGetJoystickButtons@20
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwGetJoystickName referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwGetJoystickName@12
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwSetClipboardString referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwSetClipboardString@24
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwGetClipboardString referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwGetClipboardString@16
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwGetTime referenced in function _Java_org_lwjgl_system_glfw_GLFW_glfwGetTime@8
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwSetTime referenced in function _Java_org_lwjgl_system_glfw_GLFW_glfwSetTime@16
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwMakeContextCurrent referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwMakeContextCurrent@16
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwGetCurrentContext referenced in function _Java_org_lwjgl_system_glfw_GLFW_glfwGetCurrentContext@8
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwSwapBuffers referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwSwapBuffers@16
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwSwapInterval referenced in function _Java_org_lwjgl_system_glfw_GLFW_glfwSwapInterval@12
[Linker] org_lwjgl_system_glfw_GLFW.obj : error LNK2019: unresolved external symbol _glfwExtensionSupported referenced in function _Java_org_lwjgl_system_glfw_GLFW_nglfwExtensionSupported@16
[Linker] org_lwjgl_system_libffi_LibFFI.obj : error LNK2019: unresolved external symbol _ffi_prep_cif referenced in function _Java_org_lwjgl_system_libffi_LibFFI_nffi_1prep_1cif@40
[Linker] org_lwjgl_system_libffi_LibFFI.obj : error LNK2019: unresolved external symbol _ffi_prep_cif_var referenced in function _Java_org_lwjgl_system_libffi_LibFFI_nffi_1prep_1cif_1var@44
[Linker] org_lwjgl_system_libffi_LibFFI.obj : error LNK2019: unresolved external symbol _ffi_call referenced in function _Java_org_lwjgl_system_libffi_LibFFI_nffi_1call@40
[Linker] org_lwjgl_system_libffi_LibFFIConstants.obj : error LNK2019: unresolved external symbol _ffi_type_void referenced in function _Java_org_lwjgl_system_libffi_LibFFIConstants_ffi_1type_1void@8
[Linker] org_lwjgl_system_libffi_LibFFIConstants.obj : error LNK2019: unresolved external symbol _ffi_type_uint8 referenced in function _Java_org_lwjgl_system_libffi_LibFFIConstants_ffi_1type_1uchar@8
[Linker] org_lwjgl_system_libffi_LibFFIConstants.obj : error LNK2019: unresolved external symbol _ffi_type_sint8 referenced in function _Java_org_lwjgl_system_libffi_LibFFIConstants_ffi_1type_1schar@8
[Linker] org_lwjgl_system_libffi_LibFFIConstants.obj : error LNK2019: unresolved external symbol _ffi_type_uint16 referenced in function _Java_org_lwjgl_system_libffi_LibFFIConstants_ffi_1type_1uint16@8
[Linker] org_lwjgl_system_libffi_LibFFIConstants.obj : error LNK2019: unresolved external symbol _ffi_type_sint16 referenced in function _Java_org_lwjgl_system_libffi_LibFFIConstants_ffi_1type_1sint16@8
[Linker] org_lwjgl_system_libffi_LibFFIConstants.obj : error LNK2019: unresolved external symbol _ffi_type_uint32 referenced in function _Java_org_lwjgl_system_libffi_LibFFIConstants_ffi_1type_1uint32@8
[Linker] org_lwjgl_system_libffi_LibFFIConstants.obj : error LNK2019: unresolved external symbol _ffi_type_sint32 referenced in function _Java_org_lwjgl_system_libffi_LibFFIConstants_ffi_1type_1sint32@8
[Linker] org_lwjgl_system_libffi_LibFFIConstants.obj : error LNK2019: unresolved external symbol _ffi_type_uint64 referenced in function _Java_org_lwjgl_system_libffi_LibFFIConstants_ffi_1type_1uint64@8
[Linker] org_lwjgl_system_libffi_LibFFIConstants.obj : error LNK2019: unresolved external symbol _ffi_type_sint64 referenced in function _Java_org_lwjgl_system_libffi_LibFFIConstants_ffi_1type_1sint64@8
[Linker] org_lwjgl_system_libffi_LibFFIConstants.obj : error LNK2019: unresolved external symbol _ffi_type_float referenced in function _Java_org_lwjgl_system_libffi_LibFFIConstants_ffi_1type_1float@8
[Linker] org_lwjgl_system_libffi_LibFFIConstants.obj : error LNK2019: unresolved external symbol _ffi_type_double referenced in function _Java_org_lwjgl_system_libffi_LibFFIConstants_ffi_1type_1double@8
[Linker] org_lwjgl_system_libffi_LibFFIConstants.obj : error LNK2019: unresolved external symbol _ffi_type_pointer referenced in function _Java_org_lwjgl_system_libffi_LibFFIConstants_ffi_1type_1pointer@8
[Linker] org_lwjgl_system_windows_GLFWWin32.obj : error LNK2019: unresolved external symbol _glfwGetWin32Window referenced in function _Java_org_lwjgl_system_windows_GLFWWin32_nglfwGetWin32Window@16
[Linker] org_lwjgl_system_windows_GLFWWin32.obj : error LNK2019: unresolved external symbol _glfwGetWGLContext referenced in function _Java_org_lwjgl_system_windows_GLFWWin32_nglfwGetWGLContext@16
[Linker] lwjgl64.dll : fatal error LNK1120: 87 unresolved externals
Could you try "ant -f update-dependencies.xml" and build again? If nothing changed, you could also try an "ant clean" followed by "ant" to do a full rebuild.
Updated dependencies, and tried building again.
BUILD SUCCESSFUL
Total time: 38 seconds
0 tests failed, 0 skipped! :)
I have updated the Wiki and a previous post here with better instructions on how to build on Windows. Also removed some posts to keep this topic clean.
I'm still having a problem with compiling the native code:
Ant Error:
(33, 1) D:\Users\XXXX\Downloads\lwjgl3-master\config\windows\build.xml:33: apply returned: 2
Also, it yells at me that it doesn't find "stdio.h" (apparently it has something to do with openCL)
What should I do? ??? :(
I hope you can help me. ;)
-mtronics
Please attach the full build log.
Here:
Also note: I installed visual studio 13 [express] and ran vcvarsall.bat with the x86_amd64 parameter (maybe it matters?)
It seems like you're executing compile-native from inside IntelliJ. I honestly haven't tried that before, but it probably fails because vcvarsall.bat hasn't run in the context of the IntelliJ process. You have 2 options:
- Open a command prompt, run "vcvarsall.bat x86_amd64", then "ant compile-native".
- (untested) Modify IntelliJ's startup scripts to run vcvarsall before the IDE (see idea.bat in the bin folder of the IntelliJ installation).
Personally I use the command line, because I frequently have to do both x86 and x64 builds. I use a custom script that allows me to easily switch between the two (configures both the current JDK and calls vcvarsall with the appropriate argument).
Thanks for the help but it still gives me the same errors. It seems to not find a bunch of .c files in src/native/system/windows/ prefixed with org_lwjgl_system_windows_. Could it be that the code generator missed something (although the generator doesn't give me any error)?
From the log you attached, the error seems to be related to stdio.h. Afaict, the generated files are fine. Have you tried building from the command prompt? Are you sure nothing has changed in the output?
Yes, I tried building from the command line and I tried it again but with a new fresh copy of lwjgl 3 and messing around with Visual Studio's C compiler. Now I'm getting a different log:
(Sorry that parts of the build log are in German but it basically says that there's a lot of syntax errors)
("Es fehlt" ... "vor" ... means "... is missing in front of ..." (occurs a lot of times in the log))
Thanks, that last log was helpful indeed. The bug has been fixed, you can pull, do an "ant clean-generated" and try again.
Yes! It worked. Thank you, Spasi!
BUILD SUCCESSFUL
LWJGL 3 nightly builds are now available.
This is not an official release yet, but it's usable for early adopters. An official 3.0.0a release will be done when GLFW 3.1 (http://www.glfw.org/) is released.
The new nightly build infrastructure is also used to build all binary dependencies. These are currently GLFW, openal-soft and libFFI. They are forked here (https://github.com/LWJGL-CI?tab=repositories), so that there is better control of their integration with LWJGL. If you're building from source, the LWJGL build scripts have been updated to download them automatically.
Build status:
- Windows builds at http://teamcity.lwjgl.org (http://teamcity.lwjgl.org). (use the guest login)
- Linux and OSX builds on Travis CI: LWJGL3 (https://travis-ci.org/LWJGL-CI/lwjgl3), GLFW (https://travis-ci.org/LWJGL-CI/glfw), openal-soft (https://travis-ci.org/LWJGL-CI/openal-soft), libFFI (https://travis-ci.org/LWJGL-CI/libffi).
Download:
- Nightly: build.lwjgl.org/nightly/lwjgl.zip (http://build.lwjgl.org/nightly/lwjgl.zip) (bleeding edge, possibly broken)
- Stable: build.lwjgl.org/stable/lwjgl.zip (http://build.lwjgl.org/stable/lwjgl.zip) (latest build that has been verified to work)
- Release - latest: build.lwjgl.org/release/latest/lwjgl.zip (http://build.lwjgl.org/release/latest/lwjgl.zip) (latest official release, nothing here atm)
- Release - version: build.lwjgl.org/release/{version}/lwjgl-{version}.zip (replace {version} with the specific version of a previous official LWJGL release)
Enjoy! Any issues may be reported here or (preferably) on github (https://github.com/LWJGL/lwjgl3/issues).
Cool! Will there be big API changes when the official release comes out? If not, I'm off updating my game engine ;)
Very exciting, nice work! Are there any notable changes to the roadmap (https://github.com/LWJGL/lwjgl3/wiki/1.3.-Roadmap)? (last edited 17. Nov, 2013)
Regarding the small note on "post 3.0" features:
QuoteJavaFX integration.
Cool
QuotePhysics bindings. (JBullet?)
I'd say don't bother with it, as it's unmaintained and much slower than the native version. You can check out the jMonkeyEngine 3.1 sources to study bindings for native Bullet. In my honest opinion physics bindings is out of scope for LWJGL though.
QuoteVideo bindings. (libVLC? ffmpeg?)
Desperately needed in Java gamedev.
Quote from: mtronics on November 08, 2014, 13:51:17Cool! Will there be big API changes when the official release comes out? If not, I'm off updating my game engine ;)
Ignore the org.lwjgl.api package, it will be dropped in the next update. Other than that, there's not much API left, just bindings. There is org.lwjgl.system which is considered internal API and subject to change at any time, though it has the very useful MemoryUtil class for power-users. A lot of work has gone into it, so I think its API will be pretty stable moving forward.
Quote from: erlend_sh on November 08, 2014, 16:14:10Very exciting, nice work! Are there any notable changes to the roadmap (https://github.com/LWJGL/lwjgl3/wiki/1.3.-Roadmap)? (last edited 17. Nov, 2013)
Nothing important, except maybe that the main focus right now is getting all the bindings in place (many GL/CL extensions are missing and OpenGL ES) and there's no time to explore alternative windowing systems. It's quite possible that 3.0 will ship with only GLFW (which is fantastic btw). I'd love to have JavaFX integration, but the technical limitations make it very unlikely. A compatibility layer for LWJGL 2 would also be nice to have, but not a priority right now.
Quote from: erlend_sh on November 08, 2014, 16:14:10QuotePhysics bindings. (JBullet?)
I'd say don't bother with it, as it's unmaintained and much slower than the native version. You can check out the jMonkeyEngine 3.1 sources to study bindings for native Bullet. In my honest opinion physics bindings is out of scope for LWJGL though.
Yeah, that J there was unnecessary. I meant direct bindings to native Bullet. I just wish it had a C API, would make things easier. Anyway, I'll work on it only if LWJGL can do a better job than JME & libGDX, they each have their own Bullet bindings afaict.
There is some progress being made with the C-API for Bullet Physics 3:
https://github.com/bulletphysics/bullet3/issues/130
Great work, spasi. Thanks!
It even seems that glfw window management results in much smoother animations (far fewer micro-stutters) compared to the "old" lwjgl2.9 Display.
I have a simple application that does very simple elapsed-time-based animations and tested it under both lwjgl2.9 and now lwjgl3 with glfw, and the latter looked much smoother.
I don't know whether that has something to do with v-sync (which I disabled for both Display and glfw window).
In short: lwjgl3 with glfw is great! :-)
Online javadoc is up at javadoc.lwjgl.org (http://javadoc.lwjgl.org/)
Could you have lwjgl3 be compiled with class file version 49.0 (Java 5.0) or at most 50.0 (Java 6.0) instead of 51.0?
Some client still has Java 6 installed and the current version of lwjgl3 requires a Java 7 capable JVM.
I'm afraid not. The decision was made early on that LWJGL3 will be Java 7+. You have a couple of options:
a) Fork the project and refactor any usage of Java 7 features. They are not too many and iirc no Java 7 APIs are being used atm.
b) Try retrolambda (https://github.com/orfjackal/retrolambda).
Note that most people these days ship their apps with a private JRE. The additional download overhead is insignificant for most users. It is (and has always been) a nightmare to have to depend on a pre-installed JRE on the user's machine.
Okay, thanks for the info.
There were really only a very few places where some diamonds must be undiamonded and some try-with-resources refactored to try-finally statements.
Apart from that: How do you bundle the compiled classes to a final jar? The build.xml in the lwjgl3 repo does not seem to have such a target. Especially, the "api" package seems to be missing when building from sources.
Cheers,
Kai
tried testing the Gears demo on Windows 32bit, however getting the following native crash
Quote#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x100010ac, pid=1604, tid=2388
#
# JRE version: Java(TM) SE Runtime Environment (7.0_71-b14) (build 1.7.0_71-b14)
# Java VM: Java HotSpot(TM) Client VM (24.71-b01 mixed mode, sharing windows-x86 )
# Problematic frame:
# C [lwjgl.dll+0x10ac]
#
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# C:\Documents and Settings\workspace\testl\hs_err_pid1604.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.sun.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
error report for the above here (https://dl.dropboxusercontent.com/u/33049592/hs_err_pid2316.log)
Quote from: Kai on November 10, 2014, 12:05:52How do you bundle the compiled classes to a final jar? The build.xml in the lwjgl3 repo does not seem to have such a target. Especially, the "api" package seems to be missing when building from sources.
I haven't added a release target to the Ant scripts yet. Just do a:
jar cf lwjgl.jar -C bin/Core .The api package was removed yesterday, see the commit log.
Quote from: kappa on November 10, 2014, 12:11:01tried testing the Gears demo on Windows 32bit, however getting the following native crash
That's odd and quite possibly a GLFW bug. I cannot reproduce it on Windows 8.1 but will investigate further.
Having made lwjgl3 compatible with Java 1.6 and running it on a Mac OS X 10.9.5 x64 with Java 1.6 installed, we got the following error:
Segmentation fault 11.
The trace can be downloaded here: https://www.dropbox.com/s/81lcdqm0ynfqexe/trace.txt?dl=1 (https://www.dropbox.com/s/81lcdqm0ynfqexe/trace.txt?dl=1)
Additionally, I did not recompile any native library or changed any classes apart from making diamond operators to explicit generics and try-with-resources to try-finally.
Also, I think, the issue is rather only related to the native library, which I downloaded from http://build.lwjgl.org/stable/lwjgl.zip (http://build.lwjgl.org/stable/lwjgl.zip).
EDIT: I too had to change switch-with-strings to if-string-equals statements.
A few questions:
- Does it work with Java 7 or 8?
- Is there anything AWT related in the app?
- Does it work if you don't touch AWT?
Quote- Does it work with Java 7 or 8?
Very unfortunately, I cannot test it under either 7 nor 8, since upgrading from 6 will introduce other issues with other Java applications on that host (or at least that is what I have been told)
Quote- Is there anything AWT related in the app?
No. It is a very simplistic application, without SWT, AWT or Swing or any other Java or native library, aparat from lwjgl3. It does at its first action a "Sys.touch()", then a "glfwSetErrorCallback(ErrorCallback.Util.getDefault());" and then a "glfwInit()". An that glfwInit() produces the glfw error message and afterwards crashes.
Quote- Does it work if you don't touch AWT?
n/a
EDIT: Also, the patched 1.6 lwjgl.jar runs fine on a Windows 7 x64 with jdk1.6_45 under which the application is run.
I cannot reproduce this either. Running Java 6u65 on Mavericks. I'm forcing an error and the callback runs fine.
It seems to be running fine for you too (at least the Java part). What happens if you don't set the error callback? Does it still crash?
Btw, above the "Failed to retrieve display name" error in GLFW, I see this comment: "This may happen if a desktop Mac is running headless".
The Mac in question is a Mac Book Pro 2012 with a Nvidia GeForce GT 650M, which is even an equivalent to my Quadro K2000M.
And it is being run in headfull mode with its laptop display.
Apart from that: Using lwjgl2.9 with Display class worked.
I try to get some more info on the Mac.
tried testing the Gears demo on Linux 64bit (OpenSuse 13.1), however getting the following error
QuoteException in thread "main" java.lang.ExceptionInInitializerError
at org.lwjgl.system.linux.opengl.LinuxGLContext.createFromCurrent(LinuxGLContext.java:59)
at org.lwjgl.opengl.GLContext.createFromCurrent(GLContext.java:31)
at org.lwjgl.demo.glfw.Gears.init(Gears.java:71)
at org.lwjgl.demo.glfw.AbstractGears.execute(AbstractGears.java:39)
at org.lwjgl.demo.glfw.Gears.main(Gears.java:30)
Caused by: java.lang.RuntimeException: Failed to dynamically load library: libGL.so
at org.lwjgl.system.linux.LinuxLibrary.<init>(LinuxLibrary.java:25)
at org.lwjgl.system.APIUtil.apiCreateLibrary(APIUtil.java:68)
at org.lwjgl.opengl.GL.create(GL.java:69)
at org.lwjgl.opengl.GL.create(GL.java:62)
at org.lwjgl.opengl.GL.<clinit>(GL.java:39)
... 5 more
tested the MultipleWindows & Gears demos on OS X 10.10 64bit, both work pretty nicely.
kappa, both issues you were having should be fixed now, please download the latest nightly and confirm when you have time.
Kai, I'm out of ideas for that OSX crash. Will try again tomorrow, but I don't think it's Java 6 related. One random thing you can try is passing -Dorg.lwjgl.macosx.nsloop=NA to the JVM, let me know if that changes anything. Also, is that MacBook running Mavericks or Yosemite?
Latest news: with the latest nightly yesterday evening I had prepared a super simple example with setting the GLFW exception callback and without setting it.
The segfault happened again while the exception callback was set but it did not happen without setting it...
The Java callstack of the segfault:
[LWJGL] GLFW error Code: 0x10008
Description: Failed to retrieve display name
Stacktrace:
org.lwjgl.system.glfw.ErrorCallback$Util.invoke(ErrorCallback.java:91)
org.lwjgl.system.glfw.GLFW.nglfwInit(Native Method)
org.lwjgl.system.glfw.GLFW.glfwInit(GLFW.java:414)
simple.Main.main(Main.java:21)
Invalid memory access of location 0x20 rip=0x10bb90dd7
Segmentation fault: 11
And also on Mac the application seemed to be using those disruptor classes (which was the next issue, because I wasn't shipping this) whereas on Windows everything worked fine without it.
The Mac runs on Mavericks (10.9.5).
The next thing I will be trying is to create an App bundle for Mac OS X via https://docs.oracle.com/javase/7/docs/technotes/guides/jweb/packagingAppsForMac.html (https://docs.oracle.com/javase/7/docs/technotes/guides/jweb/packagingAppsForMac.html) and ship a JRE 7 with it.
Well, actually, I have tried it right now, and of course the simple packaging step did not work with the ant task.
I have downloaded from the Oracle site the current JRE7 for Mac OS X as tar.gz, I unzipped it (under Windows) and referenced the runtime dir element (as ../jre1.7.0_71.jre/Contents/Home) within the ant task invocation. And it did not copy the JRE into the app directory. It only copied the Info.plist file.
Does anyone know what needs to be done to bundle a JRE into the app distribution folder for Mac OS X on a Windows build host?
Quote from: spasi on November 11, 2014, 00:19:16
kappa, both issues you were having should be fixed now, please download the latest nightly and confirm when you have time.
tried the gears demo with the latest nightly build download on Windows 32bit, still getting the following crash:
Quote#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x100010ac, pid=3108, tid=2364
#
# JRE version: Java(TM) SE Runtime Environment (7.0_71-b14) (build 1.7.0_71-b14)
# Java VM: Java HotSpot(TM) Client VM (24.71-b01 mixed mode, sharing windows-x86 )
# Problematic frame:
# C [lwjgl.dll+0x10ac]
#
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# C:\Documents and Settings\workspace\testl\hs_err_pid3108.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.sun.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
error report file hs_err_pid3108.log here (https://dl.dropboxusercontent.com/u/33049592/hs_err_pid3108.log).
actually tested again, I noticed that the nightly build jars were last modified on 9th Nov while the stable release jars were modified on 11th Nov, so stable builds are currently newer :).
Running these seems to get a little further on windows 32bit, no more native crash, however now I get the following exception:
QuoteException in thread "main" java.lang.IllegalStateException: OpenGL 1.1 is required.
at org.lwjgl.opengl.GL.createCapabilities(GL.java:221)
at org.lwjgl.system.windows.opengl.WindowsGLContext.createFromCurrent(WindowsGLContext.java:62)
at org.lwjgl.opengl.GLContext.createFromCurrent(GLContext.java:29)
at org.lwjgl.demo.glfw.Gears.init(Gears.java:71)
at org.lwjgl.demo.glfw.AbstractGears.execute(AbstractGears.java:39)
at org.lwjgl.demo.glfw.Gears.main(Gears.java:30)
And yes the computer does support OpenGL 1.1+ :).
Oh, thanks for the hint with the "stable build is newer than latest nightly" ! ;D
The macosx native has also changed.
I will give it a try on Mac with the most bleeding edge "stable build". ;)
Quote from: Kai on November 11, 2014, 13:48:44
Oh, thanks for the hint with the "stable build is newer than latest nightly" ! ;D
The macosx native has also changed.
Hi, this is Apostolos, I'm managing the new LWJGL servers and general infrastructure. We are deploying all downloads to a CDN ( Content Distribution Network ) so we can have faster downloads for each geo region. However, what you're describing shouldn't be happening. I'm downloading both files ( nightly & stable ) and they are - and should be - exactly the same. There may be an issue to the geo node you're using.
Could you please download both files again and send us the last modified date of the zip file as well the CRC32 of lwjgl.jar? ( For the CRC32 you could open it in WinRAR, it's the last column on the file list )
Thanks.
Hello Apostolos,
this is definitely an issue with some corporate firewalls or content proxies, it seems.
I have downloaded both .zip files over a corporate VPN (exiting at a region near Stuttgart) as well as without VPN (from Hamburg) and the download from Stuttgart got me different files, while the download from Hamburg got me both the same files...
So, this might be an issue with HTTP Cache headers?
EDIT: forgot about the timestamps and CRC32s:
The "old" download zip:
timestamp: 09.11.2014 22:09
CRC32: C50EEC66
The "new" download:
timestamp: 11.11.2014 00:12 (for native/ it is 00:11)
CRC32: C2547134
EDIT 2 (from 15:45:03 Germany, Berlin time):
download over Stuttgart still gets me different files.
old: 6.749.948 bytes vs new: 6.750.957 bytes
Quote from: kappa on November 11, 2014, 13:36:40And yes the computer does support OpenGL 1.1+ :).
Could you post the GL_VERSION, GL_VENDOR and GL_RENDERER strings? (use LWJGL2 or GLview (http://www.realtech-vr.com/glview/))
Quote from: spasi on November 11, 2014, 14:26:54
Quote from: kappa on November 11, 2014, 13:36:40And yes the computer does support OpenGL 1.1+ :).
Could you post the GL_VERSION, GL_VENDOR and GL_RENDERER strings? (use LWJGL2 or GLview (http://www.realtech-vr.com/glview/))
Using LWJGL 2 with the following code:
System.out.println("OpenGL version: " + GL11.glGetString(GL11.GL_VERSION));
System.out.println("OpenGL vendor: " + GL11.glGetString(GL11.GL_VENDOR));
System.out.println("OpenGL renderer: " + GL11.glGetString(GL11.GL_RENDERER ));returns:
OpenGL version: 2.1.8545 Release
OpenGL vendor: ATI Technologies Inc.
OpenGL renderer: ATI RADEON XPRESS 200 SeriesYes, crappy card there but should still work :)
Quote from: apostolos on November 11, 2014, 14:17:00
Could you please download both files again and send us the last modified date of the zip file as well the CRC32 of lwjgl.jar? ( For the CRC32 you could open it in WinRAR, it's the last column on the file list )
Downloaded both stable and nightly zips again, they are both identical now. The download a few hours before though was different.
kappa, I pushed a possible fix, please try again.
Quote from: spasi on November 11, 2014, 16:11:33
kappa, I pushed a possible fix, please try again.
Was getting old nightly zips, maybe firefox cache or something, but managed to get latest zips using a standalone download manager.
Anyway tested with the latest nightly builds and they work great now on windows 32bit, thanks for the fixes.
Tested the Gears demo on Linux 64bit (OpenSuse 13.1) with latest nightly build and can confirm that your fixes work and it all runs really nicely now. The windowed mode vsync works really well too (something lwjgl2 didn't do so well on linux).
Just curious, what part of lwjgl is the disruptor.jar used for? is it mac specific?
Yes, I've added a tiny note about Disruptor and OS X in README.txt, will make sure it's more visible when the new site is up.
The problem is, of course, the main thread situation in Mac OS X. GLFW, AWT, JavaFX, SWT, they're all competing for that first thread to spawn the event loop on. Java has different behavior with different JVM versions ( has changed at least on every major release, including Java 8 ) and then there's -XstartOnFirstThread. At least they have fixed AWT/JavaFX integration. Ideally, a modern Java app would never touch AWT (yes, including ImageIO), but currently LWJGL 3 assumes that you'd start with GLFW, without -XstartOnFirstThread, then go ahead and do something that initializes AWT (e.g. loading a texture image from disk). I had to implement two workarounds:
a) AWT is initialized automatically, before the native glfwInit is called. See org.lwjgl.system.macosx.EventLoop (https://github.com/LWJGL/lwjgl3/blob/master/src/core/org/lwjgl/system/macosx/EventLoop.java), can be overridden with -Dorg.lwjgl.macosx.nsloop.
b) Since the event loop is running on the AppKit thread and the LWJGL app is running on the main thread, we need to somehow transfer events between the two. This absolutely has to happen asynchronously (e.g. see glfwWaitEvents). The Disruptor is simply the highest performance solution to this problem. See org.lwjgl.system.glfw.WindowCallbackMacOSX (https://github.com/LWJGL/lwjgl3/blob/master/src/core/org/lwjgl/system/glfw/WindowCallbackMacOSX.java) for details. It's also very useful for game programming in general. It's designed for zero-allocation and is perfect for inter-process and inter-thread messaging, so I thought it'd be nice to bundle it with LWJGL.
All of the above is subject to change. This is the only difficult technical issue in LWJGL 3 and I currently don't have enough Mac OS experience to figure out a satisfactory solution. Best I can do is provide different solutions for different use cases (and JVMs!).
Quote from: Kai on November 11, 2014, 07:47:52
Latest news: with the latest nightly yesterday evening I had prepared a super simple example with setting the GLFW exception callback and without setting it.
The segfault happened again while the exception callback was set but it did not happen without setting it...
The Java callstack of the segfault:
[LWJGL] GLFW error Code: 0x10008
Description: Failed to retrieve display name
Stacktrace:
org.lwjgl.system.glfw.ErrorCallback$Util.invoke(ErrorCallback.java:91)
org.lwjgl.system.glfw.GLFW.nglfwInit(Native Method)
org.lwjgl.system.glfw.GLFW.glfwInit(GLFW.java:414)
simple.Main.main(Main.java:21)
Invalid memory access of location 0x20 rip=0x10bb90dd7
Segmentation fault: 11
This is what I tried today:
- I made a custom GLFW build that fires the same error ("Failed to retrieve display name"). This is a "soft" error btw, it does not make glfwInit to fail.
- I uninstalled the latest JDK 6 for OS X and installed an older version, same as the one in the trace (u65-b04-462).
- I'm running on Mavericks 10.9.5 as well.
The result is that I don't see the segfault, the callback is fired properly and I see the error, then the app works just fine. There must be something about that machine's environment. Why would it fail to retrieve the display name in the first place?
Another thing you may try: Call another GLFW function before glfwInit, e.g. glfwWindowHint(GLFW_VISIBLE, GL_FALSE). This will also result in your error callback being called, but I want to see if it will segfault outside glfwInit.
First of all: Thanks, spasi, for your quick responses and great support so far!
You are right. There must be an issue with that machine in general. For the time being, I think I'm gonna call it a day with that one. It has taken a lot more time and nerves than it should have. :)
I think I'm gonna wait for that LWJGL3 release and for glfw to "mature" a little bit more as well as for that particular Mac user to maybe upgrade to 10.10 and/or Java 7.
Right now as I am typing, I got a response from the Mac user about whether it makes a difference to set the error callback or not to set it (while also including the disruptor jar in the app):
The result was that not setting the error callback results in the application to work, but somehow without the glfw poll events function to recognize a ESC hit or a mouse click on the red "window close" 'button', which ought to close the application, but did not.
Quote from: Kai on November 11, 2014, 20:54:21but somehow without the glfw poll events function to recognize a ESC hit or a mouse click on the red "window close" 'button', which ought to close the application, but did not.
The window close button simply sets a flag inside GLFW that you test in your main loop with glfwWindowShouldClose. For example, see in the Gears demo (https://github.com/LWJGL/lwjgl3/blob/master/src/tests/org/lwjgl/demo/glfw/Gears.java#L88). Is your code doing that?
Well, it was just a guess that somehow the event notification may not work and that would also affect poll events. But, of course, you are right, the "should window close" function is what makes everything happen there.
And yes, I do it exactly like adviced in all tests. The very simple loop consist of:
while (0 == glfwWindowShouldClose(window)){
glfwPollEvents(window);
GL11.glClear(GL11.GL_COLOR_BUFFER_BIT);
glfwSwapBuffers(window);
}
The thing is, on Windows 7 x64, that same demo app just runs fine, but on Mac OS X it persistently refuses to do so for days. :)
Yes, well, native callbacks are really awkward with JNI. GLFW's error callback and event callbacks are separate, but their implementation is similar.
It's really odd though that it only happens on that particular Mac and not on mine and kappa's. Would it be possible to send me your app (or a simple demo that also fails on that machine), see if I can reproduce the segfault locally? I really would like to get to the bottom of this.
If the user is willing to cooperate more, another thing you could try is a native GLFW demo, so that we can at least exclude a bug in GLFW.
Of course. The test is so silly simple that I just copy/paste it here as code snippet. :)
package simple;
import org.lwjgl.Sys;
import org.lwjgl.opengl.*;
import org.lwjgl.system.glfw.*;
public class Main {
public static void main(String[] args) {
Sys.touch();
GLFW.glfwSetErrorCallback(ErrorCallback.Util.getDefault());
GLFW.glfwInit();
GLFW.glfwDefaultWindowHints();
GLFW.glfwWindowHint(GLFW.GLFW_CONTEXT_VERSION_MAJOR, 3);
GLFW.glfwWindowHint(GLFW.GLFW_CONTEXT_VERSION_MINOR, 2);
GLFW.glfwWindowHint(GLFW.GLFW_OPENGL_PROFILE,
GLFW.GLFW_OPENGL_CORE_PROFILE);
GLFW.glfwWindowHint(GLFW.GLFW_OPENGL_FORWARD_COMPAT, 1);
GLFW.glfwWindowHint(GLFW.GLFW_VISIBLE, 0);
long window = GLFW.glfwCreateWindow(800, 600, "Test", 0L, 0L);
GLFW.glfwMakeContextCurrent(window);
GLContext.createFromCurrent();
GLFW.glfwShowWindow(window);
GL11.glClearColor(0.2f, 0.3f, 0.4f, 1.0f);
while (0 == GLFW.glfwWindowShouldClose(window)) {
GLFW.glfwPollEvents();
GL11.glClear(GL11.GL_COLOR_BUFFER_BIT);
GLFW.glfwSwapBuffers(window);
}
GLFW.glfwDestroyWindow(window);
}
}
As for the native test, since I cannot compile for Mac OS X I would ask you for help to send me a native application that we can then execute on the Mac OS X 64-bit.
spasi, just noticed one thing in the Gears Demo
try {
if ( LWJGLUtil.getPlatform() == Platform.MACOSX )
CGLLockContext(context.getPointer());
renderLoop();
} finally {
if ( LWJGLUtil.getPlatform() == Platform.MACOSX )
CGLUnlockContext(context.getPointer());
}
is there any particular reason why there is OS X specific code in the gears demo? commented it out and still works fine on OS X, is it needed?
Quote from: kappa on November 11, 2014, 22:35:00is there any particular reason why there is OS X specific code in the gears demo? commented it out and still works fine on OS X, is it needed?
You'll find that it will crash if you try to resize the window, because the AppKit thread "hijacks" the context. That's why you need locking, two threads may be accessing the context at the same time. Another drawback is that the windowRefresh callback is basically useless with the current implementation. Normally it's called during resize, so that you can redraw your app and avoid flicker. With the current event queuing scheme it's too late by the time the refresh event is received.
This is all the unfortunate consequence of how OS X works and how GLFW was (logically) designed. LWJGL can probably offer two modes:
- Use XstartOnFirstThread, use GLFW just like it was meant to (everything on the first/main thread), never touch AWT.
- Current scheme, with the drawbacks/gotchas mentioned.
Anything else would probably require a custom implementation or hacking GLFW.
Ah ok, that explains it. Anyway started experimenting on writing a basic LWJGL2 compatibility layer will post something about it shortly.
Working on the basic compatibility layer, however in org.lwjgl.openal.AL10, the following method seems to be missing/different
public static void alSourceStop(java.nio.IntBuffer sources);
in lwjgl 3 there is however the method
public static void alSourceStop(int n, java.nio.ByteBuffer sources);
what's the difference and reason for the change?
Thanks, has been fixed. New nightly will be up soon.
thx for the quick fix.
On windows 32bit getting the following error when trying to play sound
QuoteCaused by: java.lang.RuntimeException: Failed to locate the OpenAL library
at org.lwjgl.openal.ALC$1.<init>(ALC.java:63)
at org.lwjgl.openal.ALC.<clinit>(ALC.java:45)
... 7 more
Same code works fine on OS X 10.10.
I don't see an issue locally, could you post your JVM launch arguments? Also output with -Dorg.lwjgl.util.Debug=true would be useful.
Quote from: spasi on November 13, 2014, 14:39:32
I don't see an issue locally, could you post your JVM launch arguments? Also output with -Dorg.lwjgl.util.Debug=true would be useful.
Not using any extra JVM Launch arguments (other than setting the path to the natives as normal), OpenGL demo's not using sound work fine, using the argument "-Dorg.lwjgl.util.Debug=true" the output is as follows:
Quote[LWJGL] Version 3.0.0a
Use -fullscreen for fullscreen mode
[LWJGL] MemoryUtil MemoryAccessor: MemoryAccessorUnsafe
[LWJGL] Failed to load C:\Documents and Settings\workspace\testl\native\windows\x86\OpenAL32.dll: Failed to load library: C:\Documents and Settings\workspace\testl\native\windows\x86\OpenAL32.dll (error code = 0)
[LWJGL] Failed to load C:\Documents and Settings\workspace\testl\OpenAL32.dll: Failed to load library: C:\Documents and Settings\workspace\testl\OpenAL32.dll (error code = 126)
[LWJGL] Failed to load OpenAL32.dll: Failed to load library: OpenAL32.dll (error code = 126)
Exception in thread "main" java.lang.ExceptionInInitializerError
at org.lwjgl.openal.AL$1.<init>(AL.java:29)
at org.lwjgl.openal.AL.<clinit>(AL.java:24)
at org.lwjgl.demo.glfw.spaceinvaders.SoundManager.initialize(SoundManager.java:120)
at org.lwjgl.demo.glfw.spaceinvaders.Game.initialize(Game.java:251)
at org.lwjgl.demo.glfw.spaceinvaders.Game.<init>(Game.java:186)
at org.lwjgl.demo.glfw.spaceinvaders.Game.main(Game.java:594)
Caused by: java.lang.RuntimeException: Failed to locate the OpenAL library
at org.lwjgl.openal.ALC$1.<init>(ALC.java:63)
at org.lwjgl.openal.ALC.<clinit>(ALC.java:45)
... 7 more
kappa, a new build which may solve the problem is up.
Quote from: spasi on November 13, 2014, 17:38:13
kappa, a new build which may solve the problem is up.
can confirm new builds solves problem, nice work.
Trying to read the available display modes using glfwGetVideoModes(long, ByteBuffer/IntBuffer); however seems a bit tricky and difficult to do.
Noticed that glfwGetVideoMode() has the convenient GLFWvidmode type, this makes it pretty easy to use that method, is there some equivalent type or utility to make this easy for glfwGetVideoModes() too?
Maybe there could be an overloaded version of glfwGetVideoModes(long) that could return an array of GLFWvidmode's or an array of ByteBuffers (which could then be read with the GLFWvidmode type)?
The style and utilities provided by the struct classes is one of the things I'd like to revisit, after the alpha release. I want to wait for more feedback, but we certainly can make them more convenient. Your suggestion is noted of course.
With that said, this is the intended usage, with the current API:
IntBuffer count = BufferUtils.createIntBuffer(1);
ByteBuffer modes = glfwGetVideoModes(monitor, count);
for ( int i = 0; i < count.get(0); i++ ) {
modes.position(i * GLFWvidmode.SIZEOF);
int w = GLFWvidmode.width(modes);
int h = GLFWvidmode.height(modes);
int r = GLFWvidmode.refreshRate(modes);
System.out.println(w + " x " + h + " @ " + r + "Hz");
}
Quote from: spasi on November 14, 2014, 00:30:08
The style and utilities provided by the struct classes is one of the things I'd like to revisit, after the alpha release. I want to wait for more feedback, but we certainly can make them more convenient. Your suggestion is noted of course.
With that said, this is the intended usage, with the current API:
IntBuffer count = BufferUtils.createIntBuffer(1);
ByteBuffer modes = glfwGetVideoModes(monitor, count);
for ( int i = 0; i < count.get(0); i++ ) {
modes.position(i * GLFWvidmode.SIZEOF);
int w = GLFWvidmode.width(modes);
int h = GLFWvidmode.height(modes);
int r = GLFWvidmode.refreshRate(modes);
System.out.println(w + " x " + h + " @ " + r + "Hz");
}
cool, the above seems good enough for my needs.
GL11.GL_COLOR_INDEX seems to be missing in LWJGL3
LWJGL 2 doesn't support color-index mode either. It doesn't have any color-index function, but does have COLOR_INDEX & COLOR_INDEXES. I removed those from LWJGL 3, since they're pointless.
I'm not sure if this is lwjgl-related, but I had some serious trouble just now with GLFW. This is my code:
lesson1/Game.java
package lesson1;
import org.lwjgl.Sys;
import org.lwjgl.opengl.*;
import org.lwjgl.system.glfw.*;
import java.nio.ByteBuffer;
import static org.lwjgl.opengl.GL11.*;
import static org.lwjgl.system.MemoryUtil.*;
import static org.lwjgl.system.glfw.GLFW.*;
public class Game {
public void run() {
Window.create(800,600,false);
while (!Window.isClosed()) {
//Window.clear();
Window.update();
}
Window.destroy();
}
}
lesson1/Window.java
package lesson1;
import org.lwjgl.Sys;
import org.lwjgl.opengl.*;
import org.lwjgl.system.glfw.*;
import java.nio.ByteBuffer;
import static org.lwjgl.opengl.GL11.*;
import static org.lwjgl.system.MemoryUtil.*;
import static org.lwjgl.system.glfw.GLFW.*;
public class Window {
//Variables
private static long window;
public static String title = "";
//Getters
public static boolean isClosed() { if (glfwWindowShouldClose(window) == 0) return false; else return true; }
//Setters
public static void setSize(int width,int height) { glfwSetWindowSize(window, width, height); }
public static void setPosition(int x,int y) { glfwSetWindowPos(window,x,y); }
//General functions
public static void create(int width,int height, boolean fullscreen) {
if (glfwInit() == GL_FALSE) {
System.err.println("[Window] Unable to initialize Window");
System.exit(1);
}
if (!fullscreen) {
window = glfwCreateWindow(width,height,"",NULL,NULL);
} else {
window = glfwCreateWindow(width,height,"",glfwGetPrimaryMonitor(),NULL);
}
if (window == GL_FALSE) {
System.err.println("[Window] Unable to create window");
System.exit(1);
}
glfwMakeContextCurrent(window);
glfwSwapInterval(1);
GLContext.createFromCurrent();
Keyboard.init(window);
}
public static void close() {
glfwSetWindowShouldClose(window, 1);
}
public static void clear() {
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
glClearColor(1,1,1,0);
}
public static void update() {
glfwSetWindowTitle(window,title);
glfwSwapBuffers(window);
glfwPollEvents();
}
public static void destroy() {
glfwDestroyWindow(window);
glfwTerminate();
}
public static void minimize() {
glfwIconifyWindow(window);
}
public static void restore() {
glfwRestoreWindow(window);
}
public static void hide() {
glfwHideWindow(window);
}
public static void show() {
glfwShowWindow(window);
}
}
Program.java
import lesson1.Game;
public class Program {
public static void main (String[] args) {
Game game = new Game();
game.run();
}
}
I am running Ubuntu 14.04 LTS 64 bit. I compile this using the terminal. What happens is that my entire system crashes when I click the resize button. I was forced to reboot in order to get control again. However, if I uncomment the Window.clear() void everything works fine.
Quote from: spasi on November 15, 2014, 16:02:04
LWJGL 2 doesn't support color-index mode either. It doesn't have any color-index function, but does have COLOR_INDEX & COLOR_INDEXES. I removed those from LWJGL 3, since they're pointless.
Ah ok, only noticed this as its used in LWJGL2's GLU package and wasn't there when I was wrapping the API.
Anyway finished a first rough version of the wrapper for LWJGL2. It can run unmodified versions (except for package names) of LWJGL2's Gears and Space Invaders demo's. Only implemented the bare minimum require API so far.
Early source code here (http://kappa.dreamhosters.com/test/lwjglx-src.zip)
1) For some reason not getting any sound on Linux 64bit (OpenSuse 13.1) although there is sound on both Win32 and OSX.
2) Had to use a different package name (org.lwjglx.*) to avoid conflicting with the LWJGL3 classes that have the same names, guess this could be worked around by either using some classloader voodoo or building a custom version of LWJGL3 which has different package names, this could then allow unmodified LWJGL2 apps to run on LWJGL3.
3) As for deployment, natives for Win32/Win64 and Linux32/64 have the same names, would make life a lot easier if they had different names (like LWJGL2 e.g. lwjgl64.dll, etc) as then you can put them all in one folder to make deployment easier, easier to identify which natives are what, and allowing the same "-Djava.library.path" path to be set once and it'll work for all platforms.
Quote from: TheBoneJarmer on November 15, 2014, 18:54:40
I'm not sure if this is lwjgl-related, but I had some serious trouble just now with GLFW. This is my code:
...
I am running Ubuntu 14.04 LTS 64 bit. I compile this using the terminal. What happens is that my entire system crashes when I click the resize button. I was forced to reboot in order to get control again. However, if I uncomment the Window.clear() void everything works fine.
I was able to reproduce this. It happens every time, without resizing the window. Using Window.clear() makes no difference, it's actually a bit better with it. I'm on OpenSuse 13.1, it doesn't crash, but the whole OS slows down to a crawl.
The fix is to not use glfwSetWindowTitle in the render loop. Linux does not do vsync (glfwSwapInterval(1)) in windowed mode, which means that your simple loop is called thousands of times per second. I don't think it's an LWJGL or GLFW issue, X simply cannot handle that many window title updates.
Quote from: kappa on November 15, 2014, 19:00:05
Anyway finished a first rough version of the wrapper for LWJGL2. It can run unmodified versions (except for package names) of LWJGL2's Gears and Space Invaders demo's. Only implemented the bare minimum require API so far.
Early source code here (http://kappa.dreamhosters.com/test/lwjglx-src.zip)
Nice, good job!
Quote from: kappa on November 15, 2014, 19:00:051) For some reason not getting any sound on Linux 64bit (OpenSuse 13.1) although there is sound on both Win32 and OSX.
I'm on OpenSuse 13.1 too and OpenAL works fine. What's the output of org.lwjgl.demo.openal.ALCDemo on your machine?
Quote from: kappa on November 15, 2014, 19:00:052) Had to use a different package name (org.lwjglx.*) to avoid conflicting with the LWJGL3 classes that have the same names, guess this could be worked around by either using some classloader voodoo or building a custom version of LWJGL3 which has different package names, this could then allow unmodified LWJGL2 apps to run on LWJGL3.
There might be other options,
if we really want to do this.
Quote from: kappa on November 15, 2014, 19:00:053) As for deployment, natives for Win32/Win64 and Linux32/64 have the same names, would make life a lot easier if they had different names (like LWJGL2 e.g. lwjgl64.dll, etc) as then you can put them all in one folder to make deployment easier, easier to identify which natives are what, and allowing the same "-Djava.library.path" path to be set once and it'll work for all platforms.
This makes the library initialization and build scripts unnecessarily complex, but you've got a point about deployment. I'll see what I can do.
Quote from: spasi on November 15, 2014, 19:52:13
I'm on OpenSuse 13.1 too and OpenAL works fine. What's the output of org.lwjgl.demo.openal.ALCDemo on your machine?
Also tried with ALCDemo, get the following output but don't hear anything
QuoteOpenALC10: true
OpenALC11: true
caps.ALC_EXT_EFX = true
0: No Output
Default device: OpenAL Soft
Waiting 5 seconds for sound to complete
Quote from: spasi on November 15, 2014, 19:52:13
Quote from: kappa on November 15, 2014, 19:00:052) Had to use a different package name (org.lwjglx.*) to avoid conflicting with the LWJGL3 classes that have the same names, guess this could be worked around by either using some classloader voodoo or building a custom version of LWJGL3 which has different package names, this could then allow unmodified LWJGL2 apps to run on LWJGL3.
There might be other options, if we really want to do this.
Yes don't wanna waste massive amounts of time on such a library because it'll eventually die once everyone switches to LWJGL3, but its not really much work (spent maybe an hour on the above and was a good learning experience for the LWJGL3 API), its just a matter of hooking up the corresponding Display calls to GLFW and the GL and AL stuff is pretty much the same (above already covers a good chunk of the LWJGL2 core). It doesn't need to cover the whole LWJGL2 API just the API's a target project is using. Could be nice for current LWJGL2 code bases (e.g. minecraft, puppygames, Spiral Knights, jME, etc) to trial LWJGL3 before deciding whether they want to commit to it or when LWJGL2 projects starts breaking on future platforms there could be quick fix library available. Anyway just curious, what other options did you have in mind?
Quote from: kappa on November 15, 2014, 20:15:06Also tried with ALCDemo, get the following output but don't hear anything
QuoteOpenALC10: true
OpenALC11: true
caps.ALC_EXT_EFX = true
0: No Output
Default device: OpenAL Soft
Waiting 5 seconds for sound to complete
Hmm. Could you please try the OpenAL binary from LWJGL 2? Does that work?
Quote from: kappa on November 15, 2014, 20:15:06Anyway just curious, what other options did you have in mind?
We could move LWJGL 3 classes, except bindings, to a new root: org.lwjgl3. It should simplify the emulation layer, but it's a bit inconvenient for new LWJGL 3 users and we'll have to publicly expose some package-private functionality.
Quote from: spasi on November 15, 2014, 20:19:54
Hmm. Could you please try the OpenAL binary from LWJGL 2? Does that work?
The OpenAL binary from LWJGL2 works nicely (renamed its libopenal64.so to libopenal.so), ALCDemo output is as follows:
QuoteOpenALC10: true
OpenALC11: true
caps.ALC_EXT_EFX = true
0: ALSA Default
1: HDA Intel, ALC888 Analog (CARD=Intel,DEV=0)
2: HDA Intel, ALC888 Digital (CARD=Intel,DEV=1)
3: HDA NVidia, HDMI 0 (CARD=NVidia,DEV=3)
4: HDA NVidia, HDMI 1 (CARD=NVidia,DEV=7)
5: HDA NVidia, HDMI 2 (CARD=NVidia,DEV=8)
6: HDA NVidia, HDMI 3 (CARD=NVidia,DEV=9)
Default device: OpenAL Soft
AL lib: (EE) UpdateDeviceParams: Failed to set 44100hz, got 48000hz instead
Waiting 5 seconds for sound to complete
Quote from: spasi on November 15, 2014, 20:19:54
We could move LWJGL 3 classes, except bindings, to a new root: org.lwjgl3. It should simplify the emulation layer, but it's a bit inconvenient for new LWJGL 3 users and we'll have to publicly expose some package-private functionality.
Ah, better not to compromise any LWJGL3 niceness for such a library (since its not really that important), rather keep all the hackage and voodoo in the wrapper library.
Quote from: kappa on November 15, 2014, 20:32:50The OpenAL binary from LWJGL2 works nicely
I've stopped merging OpenAL Soft automatically from upstream.
Seems a lot of unstable stuff are being pushed to the master branch. I have now reverted our nightly build to the 1.16 release (edit: nvm, I think I fixed it now), could you please try this binary (http://build.lwjgl.org/nightly/linux/x64/libopenal.so)?
Quote from: spasi on November 16, 2014, 12:21:14
Quote from: kappa on November 15, 2014, 20:32:50The OpenAL binary from LWJGL2 works nicely
I've stopped merging OpenAL Soft automatically from upstream. Seems a lot of unstable stuff are being pushed to the master branch. I have now reverted our nightly build to the 1.16 release (edit: nvm, I think I fixed it now), could you please try this binary (http://build.lwjgl.org/nightly/linux/x64/libopenal.so)?
Yup, can confirm that the binary above works fine.
Quote from: kappa on November 15, 2014, 19:00:053) As for deployment, natives for Win32/Win64 and Linux32/64 have the same names, would make life a lot easier if they had different names (like LWJGL2 e.g. lwjgl64.dll, etc) as then you can put them all in one folder to make deployment easier, easier to identify which natives are what, and allowing the same "-Djava.library.path" path to be set once and it'll work for all platforms.
I implemented a new method of loading native libraries, which solves the above issue. With the current build structure, you can simply point
java.library.path or
org.lwjgl.librarypath to the
/native folder and it will work on all OSes and architectures.
I did my best to extensively test this (I think I tried everything except OpenCL on Linux) but please try the latest nightly and let me know if you have any issues.
See the blog (http://blog.lwjgl.org/20141118_first_10_days/) for a fresh progress update.
Continuing to play with the LWJGL2 compatibility layer, implemented some more bits and can now run LWJake2 on LWJGL3 almost without any modifications to its code.
(http://i.imgur.com/IfudhOC.png)
Some thoughts and hurdles I ran into:
- Finally with LWJGL3 we have sane keyboard key names (thx to GLFW) some of the LWJGL2's key names were pretty horrid (still haven't figured out what some of the keys are and how to correspond them to the ones in GLFW).
- The characters keys return with GLFW is really well implemented and supports unicode (something the non-english users will really like).
- Really loving the callbacks in GLFW makes code a lot simpler in places.
- The AL class is different in LWJGL3 although the changes are not too dramatic and do allow more flexibility but not as simple anymore as LWGL2's AL.create() and require more code to initialise.
- Had to wrap EFX for LWJGL2 compatibility as its no longer in the EFX10 class but in one called EXTEfx other than that the EFX API calls are the same.
- The extensions ARBMultitexture, EXTPointParameters & EXTSharedTexturePalette are used extensively in LWJake2 but missing in LWJGL3, so created wrappers for them (for
ARBMultitexture pointed the calls to corresponding GL13 calls, for EXTPointParameters created a wrapper which points to ARBPointParameters which is the same, for
EXTSharedTexturePalette there was only reference to an int called GL_SHARED_TEXTURE_PALETTE_EXT=33275 so just added that).
- came across the missing GL11.GL_COLOR_INDEX again, which is used quiet a lot in LWJake2, so replaced with public static final int GL_COLOR_INDEX = 6400;
- I still need to implement full screen support in the LWJGL2 compatibility layer, will probably try next to get it working in a bigger project like LibGDX, jME, etc.
Other than the above, it was a pretty smooth transition to getting LWJake2 working.
Awesome, thanks for the info. Addressing a few points:
- AL needs work in general. I'll also see if we can structure EFX better. Not saying it's going to be compatible with LWJGL 2, will prefer the design that makes more sense.
- I'll add the missing extensions asap and please let me know if you need more.
- I really wonder what GL_COLOR_INDEX is used for... If we're talking about a valid use-case I'll add all the missing functionality.
Quote from: spasi on November 23, 2014, 19:37:57
- I really wonder what GL_COLOR_INDEX is used for... If we're talking about a valid use-case I'll add all the missing functionality.
TBH, not really sure what its used for, seems like its one of the format options supported by glTexImage2D.
It also part of the OpenGL specs, the OpenGL docs say
QuoteGL_COLOR_INDEX
Each element is a single value, a color index. The GL converts it to fixed point (with an unspecified number of zero bits to the right of the binary point), shifted left or right depending on the value and sign of GL_INDEX_SHIFT, and added to GL_INDEX_OFFSET (see glPixelTransfer). The resulting index is converted to a set of color components using the GL_PIXEL_MAP_I_TO_R, GL_PIXEL_MAP_I_TO_G, GL_PIXEL_MAP_I_TO_B, and GL_PIXEL_MAP_I_TO_A tables, and clamped to the range [0,1].
Doing a quick google search for GL11.GL_COLOR_INDEX shows that its used in quiet a few other projects including, JPCSP (java psp emulator), Eclipse GEF3d, Ardor3d, github says 270 repo's use it.
Started working on getting the LWJGL2 compatibility layer working with LibGDX, noticed that the overloaded method AL10.alSourceUnqueueBuffers(int source) is missing in LWJGL3.
Latest build has ARB_multitexture, EXTPointParameters, EXTSharedTexturePalette, color index functions/constants in GL11 and fixed alSourceUnqueueBuffers.
Does LWJGL 2 really not support color index mode? I found a usage of it in JPCSP's code after kappa mentioned: https://github.com/sum2012/jpcsp-free/blob/master/src/jpcsp/test/OpenGL.java
Look for usage of 'texture2Id'.
On Github I found no legitimate use in Java code, only clumped with other cases in utilities that check for texture type in a switch statement.
Quote from: spasi on November 23, 2014, 23:18:04
Latest build has ARB_multitexture, EXTPointParameters, EXTSharedTexturePalette, color index functions/constants in GL11 and fixed alSourceUnqueueBuffers.
Awesome stuff, tested above and all seems to work pretty good.
Trying the LibGDX code also flagging up the missing extension EXTFramebufferObject which they use a lot in their LWJGL backend (not sure why they didn't just use the ARB version).
Also GL15.glGetBufferPointer in LWJGL3 returns a long now, while the same method in LWJGL2 returned a ByteBuffer.
Other than the above shouldn't take long to get LibGDX ported to LWJGL3 using the compatibility layer.
I did ask this in jgo, but not sure how often you check both. For new projects, should we use 3 or stick with 2 and port later?
Quote from: kappa on November 24, 2014, 00:29:52Also GL15.glGetBufferPointer in LWJGL3 returns a long now, while the same method in LWJGL2 returned a ByteBuffer.
This is indeed another change that is incompatible with LWJGL 2. The GetXPointer functions were inconsistent and in some cases inflexible. For example, GL15.glGetBufferPointer had a glGetBufferParameteri(target, GL_BUFFER_SIZE) hidden inside the call, but the user might already know the size. Or they might only care about the pointer value itself and we were forcing a ByteBuffer allocation. In other cases, such as GL11.glGetPointer, there was an extra argument for the user to specify the size explicitly, but no such argument exists in the corresponding native function. This breaks the fundamental decision in LWJGL 3 to always match the native function signature perfectly.
There are two ways to use the new style:
int target = GL_ARRAY_BUFFER;
int size = glGetBufferParameteri(target, GL_BUFFER_SIZE);
// standard
PointerBuffer pb = BufferUtils.createPointerBuffer(1);
glGetBufferPointer(target, GL_BUFFER_MAP_POINTER, pb);
ByteBuffer bb = pb.getByteBuffer(0, size);
FloatBuffer fb = pb.getFloatBuffer(0, size >> 2);
// unsafe
long p = glGetBufferPointer(target, GL_BUFFER_MAP_POINTER);
ByteBuffer bb = memByteBuffer(p, size);
FloatBuffer fb = memFloatBuffer(p, size >> 2);The "unsafe" version is basically a shortcut for:
PointerBuffer pb = BufferUtils.createPointerBuffer(1);
glGetBufferPointer(target, GL_BUFFER_MAP_POINTER, pb);
long p = pb.get(0);but without a PointerBuffer allocation.
ah ok, will see if I can work round it.
btw LibGDX also uses GL20.glIsProgram(int) and GL20.glIsShader(int) which seem to be missing in LWJGL3.
Quote from: ra4king on November 23, 2014, 23:31:10Does LWJGL 2 really not support color index mode?
Latest nightly has all color index mode related functionality, missed some last time.
Quote from: kappa on November 24, 2014, 00:29:52Trying the LibGDX code also flagging up the missing extension EXTFramebufferObject which they use a lot in their LWJGL backend (not sure why they didn't just use the ARB version).
Latest nightly has support for EXT_framebuffer_object and other EXT_framebuffer extensions.
Quote from: kappa on November 25, 2014, 00:01:06btw LibGDX also uses GL20.glIsProgram(int) and GL20.glIsShader(int) which seem to be missing in LWJGL3.
Latest nightly has these two.
Quote from: delt0r on November 24, 2014, 14:54:19I did ask this in jgo, but not sure how often you check both. For new projects, should we use 3 or stick with 2 and port later?
See replies on JGO. But it depends on the project really, what are your requirements?
Quote from: spasi on November 25, 2014, 00:41:10
Quote from: kappa on November 24, 2014, 00:29:52Trying the LibGDX code also flagging up the missing extension EXTFramebufferObject which they use a lot in their LWJGL backend (not sure why they didn't just use the ARB version).
Latest nightly has support for EXT_framebuffer_object and other EXT_framebuffer extensions.
Quote from: kappa on November 25, 2014, 00:01:06btw LibGDX also uses GL20.glIsProgram(int) and GL20.glIsShader(int) which seem to be missing in LWJGL3.
Latest nightly has these two.
Excellent, they work as expected.
Another thing LibGDX uses from LWJGL2 but I couldn't find in LWJGL3 is the following methods:
GL15.glGetActiveUniform(int program, int index, int maxLength, java.nio.IntBuffer sizeType)and
GL15.glGetActiveAttrib(int program, int index, int maxLength, java.nio.IntBuffer sizeType)Lastly the following 2 methods are different
GL15.glVertexAttribPointer(int index, int size, boolean unsigned, boolean normalized, int stride, java.nio.ByteBuffer buffer);
GL15.glVertexAttribPointer(int index, int size, boolean unsigned, boolean normalized, int stride, java.nio.ShortBuffer buffer);They no longer have the 'unsigned' boolean variable but require an int 'type' variable. This is definitely a change for the better in LWJGL3.
These are more examples of custom LWJGL 2 bindings. These methods were included for convenience, but they do not match the native function signatures and require special-case "magic" in the code generator. So they've been removed, more user-friendly versions can easily be written on top of LWJGL.
Warning: skip the following if you don't care (or don't want to know) about unsafe, direct pointer management in your Java code.
[unsafe]
The sizeType parameter in GetActiveUniform/GetActiveAtttrib was added because of how buffer arguments are used in LWJGL; it was impossible to use just one IntBuffer for both, you had to have two. So instead of (ignore the string decoding stuff):
IntBuffer lengthBuffer = BufferUtils.createIntBuffer(1);
IntBuffer sizeBuffer = BufferUtils.createIntBuffer(1);
IntBuffer typeBuffer = BufferUtils.createIntBuffer(1);
ByteBuffer nameBuffer = BufferUtils.createByteBuffer(maxLength);
glGetActiveUniform(program, index, lengthBuffer, sizeBuffer, typeBuffer, nameBuffer);
nameBuffer.limit(lengthBuffer.get(0));
String name = MemoryUtil.decodeASCII(nameBuffer);
int size = sizeBuffer.get(0);
int type = typeBuffer.get(1);
you could do:
IntBuffer sizeType = BufferUtils.createIntBuffer(2);
String name = glGetActiveUniform(program, index, maxLength, sizeType);
int size = sizeType.get(0);
int type = sizeType.get(1);
you can emulate the same thing in LWJGL 3 using the unsafe version:
IntBuffer intParams = BufferUtils.createIntBuffer(3);
ByteBuffer nameBuffer = BufferUtils.createByteBuffer(maxLength);
long int_p = memAddress(intParams);
nglGetActiveUniform( // note the 'n' prefix
program, index, maxLength,
int_p, // length
int_p + 4, // size
int_p + 8, // type
memAddress(nameBuffer)
);
String name = memDecodeASCII(nameBuffer, intParams.get(0)); // LWJGL 3 is more flexible, you don't have to set the limit before decoding
int size = intParams.get(1);
int type = intParams.get(2);
Note that this is not a special case in LWJGL 3. All bindings now expose such "unsafe" versions automatically and can be used when more flexibility and/or performance is required.
[/unsafe]
Btw, GetActiveUniform and GetActiveAtttrib are in GL20, not GL15.
Thx for the response, much appreciated.
Quote from: spasi on November 26, 2014, 12:25:38
Btw, GetActiveUniform and GetActiveAtttrib are in GL20, not GL15.
Sorry my bad, did mean GL20, typed GL15 by mistake.
Created a wrapper method to emulate LWJGL2's
glVertexAttribPointer(int index, int size, boolean unsigned, boolean normalized, int stride, ByteBuffer buffer)
as follows:
public static void glVertexAttribPointer(int index, int size,
boolean unsigned, boolean normalized,
int stride, ByteBuffer buffer) {
int type = unsigned ? GL11.GL_UNSIGNED_BYTE : GL11.GL_BYTE;
GL20.glVertexAttribPointer(index, size, type, normalized, stride, buffer);
}bit more tricky to emulate glVertexAttribPointer(int index, int size, boolean unsigned, boolean normalized, int stride, ShortBuffer buffer), since LWJGL3's glVertexAttribPointer(int index, int size, boolean normalized, int stride, ShortBuffer pointer) doesn't allow specifying a GL_UNSIGNED_SHORT, any idea's how to emulate this when providing a ShortBuffer?
Hmm, I see. There are two ways:
- I can stop hiding the type argument, so the "auto-typed" versions will be simple overloads of the ByteBuffer version.
- You can use the unsafe version, like so:
int type = unsigned ? GL11.GL_UNSIGNED_SHORT : GL11.GL_SHORT;
nglVertexAttribPointer(index, size, type, normalized, stride, memAddress(shortBuffer));
Request for feedback
Background
I've been working on a major refactoring for the past few days, related to callback functions, and I finally think that the result is an improvement. Since this is a breaking change and I still have some work to do, it'd probably be useful to get some early feedback on this.
The problem with callbacks has always been that native callbacks work with function pointers and you can't create a function pointer to an arbitrary Java method. The only way native code can call into Java is through JNI functions. This has always been extremely limiting:
a) We had to write custom native code for each callback type.
b) Each callback type could only use a single native function pointer (that came precompiled with LWJGL) and everything had to be implemented from there, no matter how many different callbacks were needed.
c) For implementation reasons, LWJGL needed to use the callback's "user_data" argument. This was a problem because the 1) the user couldn't use it 2) some callback types don't even have a user_data argument (e.g. GLFW callbacks).
There are workarounds for everything and we could do better work with documentation, but in the end it was just too much work. Also, LWJGL 3 tries to be source-compatible with whatever official FFI support comes in Java 9 or 10 and the current custom callback code is fundamentally incompatible. I wanted to see if we could do better.
New implementation
We now use libFFI's "closures" to generate native callback functions at runtime. I won't tire you with details, there's a lot of "magic" involved, but here are the benefits:
a) We can have callbacks to arbitrary objects/methods.
b) All callback types are now auto-generated, there's no need for custom code.
c) user_data arguments can now be used by the user.
d) Java 8 lambdas are supported.
One drawback is that the new callbacks require manual cleanup (they hold on to a bit of memory that would leak), but it's quite easy (see below).
What does it look like
Lets start with GLFW, you can now do:
glfwSetWindowPosCallback(window, new GLFWwindowposfun() {
@Override
public void invoke(long window, int xpos, int ypos) {
System.out.printf("Window 0x%X moved to %d, %d\n", window, xpos, ypos);
}
});
which perfectly matches the native API. In Java 8 you can do:
glfwSetWindowPosCallback(window, (it, xpos, ypos) -> System.out.printf("Window 0x%X moved to %d, %d\n", it, xpos, ypos));
or even:
private static void windowMoved(long window, int xpos, int ypos) {
System.out.printf("Window 0x%X moved to %d, %d\n", window, xpos, ypos);
}
{
glfwSetWindowPosCallback(window, MyClass::windowMoved); // method reference
}
For cleanup, you can do:
glfwSetWindowPosCallback(window, null).release();
// or if you aren't sure
GLFWwindowposfun.Handle previous = glfwSetWindowPosCallback(window, null); // note you get a GLFWwindowposfun.Handle, not a GLFWwindowposfun.
if ( previous != null )
previous.release();
Similarly, for OpenGL debugging:
glDebugMessageCallback(new DEBUGPROC() {
@Override
public void invoke(int source, int type, int id, int severity, String message, long userParam) {
// ...
}
}, NULL); // userParam is available
But this now has the problem that you don't get a previous callback back for cleanup. This can be solved by either using a DEBUGPROC.Handle directly and storing a reference to it, or, using this:
DEBUGPROC.Handle hnd = Closure.create(glGetPointer(GL_DEBUG_CALLBACK_FUNCTION));
glDebugMessageCallback(NULL, NULL);
hnd.release();
Yes, you can actually retrieve the instance from the raw function pointer!
Btw, we have both a DEBUGPROC and a DEBUGPROC.Handle for lambda support. DEBUGPROC.Handle is an abstract class that implements the magic and DEBUGPROC is a functional interface.
Let me know what you think.
Firstly really loving the new LWJGL3 direction, tis awesome, i.e. auto generating most of the bindings and pushing a lot of the maintenance burden upstream (the maintenance required on LWJGL2's Display was probably the most time consuming bit).
The new callback API looks really nice and modern but do think the cleanup part could be a little more fine tuned and made a bit more javaish and higher level without compromising functionality and flexibility.
Could a release() be automatically triggered internally on any previous handle if a null or new callback is passed to the method? Secondly all callbacks for a certain window could automatically be cleaned up internally when a window is destroyed?
It is possible but with quite a bit of implementation pain. Different callback types in different APIs may require very different approaches to do cleanup properly. We pay this price already with the current implementation; GLFW events, OpenGL debug output, OpenCL callbacks, even experimental functions like the WinGDI.EnumObjects callback, are all cleaned up automatically.
The new unified callback implementation may simplify things a bit, but we'll still have to write custom code. Moving the responsibility to the user removes that burden.
There's also the issue of reusing callbacks; allocating a callback instance is quite expensive and it makes sense to reuse the same instance many times (e.g. OpenCL event callbacks). Reference counting is used currently (callbacks implement org.lwjgl.system.Retainable) but this is open to misuse and race conditions if we try to hide cleanup details from the user.
Like always, it's a tradeoff we need to make. On one hand, a new user reads a single line of documentation and goes on to use LWJGL, but they have to be more careful and write a bit of extra code. On the other, we cover 99% of use cases with no impact on code, but users have to first read and understand a non-trivial memory management mechanism inside LWJGL (that may also be different in different APIs).
My personal opinion on memory management is:
Have the user take care of it.
Let LWJGL just be an enabling technology that provides simple translation schemes to convert between concepts in the Java and the native world (functions/methods, enums/constants).
Now we have a scheme for callback functions and I think, what Ioannis suggested, sounds quite good.
Of course we have a leaky abstraction here, because memory management of native structures is exposed to the user.
Therefore, we need to make it very clear in the documentation.
How people then go about memory management could be different: Some users may want to integrate memory management of LWJGL objects with other things in their app by interfacing with GC and using WeakReferences and ReferenceQueues. Some other users may want to do it entirely different, again. We never know.
I'm a novice programmer, so I don't fully grasp all of this, so sorry if I am not understanding. LWJGL's success is probably related to its ease of use, and opening up sometimes complicated memory management for the user seems like a bad idea.
Instead of a mostly-unified callback system, is there a way it could be *clearly* specified between each API? Like in org.lwjgl there would be a "OpenGLCallback" and "GLFWCallback" and so on?
QuoteCould a release() be automatically triggered internally on any previous handle if a null or new callback is passed to the method?
I'm not sure that is necessary. It'd be most important that things are consistent. All methods call .retain, I take it? But some can't call .release because every API has its own nuanced release system, right? Being mildly convenient in 10% of places just seems like more of an annoyance, and more of an unnecessary burden on maintenance.
As a secondary suggestion on layout, I think a display package is justifiable because most games don't have highly complex demands on input and windows (AFAIK). System packages seem like a good way to say "hey you, this is a little more advanced," so leaving GLFW there seems okay (assuming a display package is added).
If a display package is deemed out of scope, then none of that matters, though. The WindowCallback class seems like it'd suffice, if its not a heavy burden to maintain.
Quote from: shivshank on November 30, 2014, 04:30:23Instead of a mostly-unified callback system, is there a way it could be *clearly* specified between each API? Like in org.lwjgl there would be a "OpenGLCallback" and "GLFWCallback" and so on?
The implementation is unified, i.e. all callback types go through the same code (basically one C and one Java file). The only thing that changes is the function signature definition and the public interface the user sees in the API. So each callback type is a separate interface (e.g. DEBUGPROC, GLFWcursorposfun, CLNativeKernel), which is generated automatically.
Quote from: shivshank on November 30, 2014, 04:30:23As a secondary suggestion on layout, I think a display package is justifiable because most games don't have highly complex demands on input and windows (AFAIK). System packages seem like a good way to say "hey you, this is a little more advanced," so leaving GLFW there seems okay (assuming a display package is added).
Yes, GLFW shouldn't be in the system package. The original intent was to have a "display" package with a pure Java API for windows, input, etc. Then GLFW would simply be the back-end for that API. Back-ends would be pluggable and power-users could also use the back-end directly, in the "advanced/unsafe" system package.
The plan has changed now. Everyone seems happy with GLFW and you could say it's a noob-friendly API, there's no reason to "hide" it. I'm already planning to move it out of the system package and leave only unsafe and non-cross-platform APIs in there. The question I'd like feedback with is whether to put it at the top level (org.lwjgl.glfw) or under a "display" package (org.lwjgl.display.glfw, org.lwjgl.window.glfw, org.lwjgl.gui.glfw, etc).
Quote from: spasi on November 30, 2014, 10:42:56
The plan has changed now. Everyone seems happy with GLFW and you could say it's a noob-friendly API, there's no reason to "hide" it. I'm already planning to move it out of the system package and leave only unsafe and non-cross-platform APIs in there. The question I'd like feedback with is whether to put it at the top level (org.lwjgl.glfw) or under a "display" package (org.lwjgl.display.glfw, org.lwjgl.window.glfw, org.lwjgl.gui.glfw, etc).
Agreed, go for top level package "org.lwjgl.glfw".
Mainly because, it provides a lot more than just windows, a high resolution timer and access to the clipboard (previously in org.lwjgl.Sys) and also handles input of Keyboard, Mouse, Controller (previously in org.lwjgl.input.*) also it will highlight that its now the primary windowing system
The 'gui' package name would not be good as GLFW itself provides very little user interface (button, scroll pane, message box, etc) and best saved for an opengl gui library (unlikely to happen :) ) or maybe for a FreeType2 binding. The 'window' package name is confusing with the windows platform name used in other places.
Progress update: After several iterations, the new callback system is ready. I didn't want to rush it, since this will break everyone's code and I wanted to avoid having to break it more than once. This will happen in the next nightly build. For the same reason, the next build will also move GLFW to a top-level package. It should be ready tomorrow.
These are the changes since last time (I will use GLFWwindowposfun as an example again):
a) Before we had a GLFWwindowposfun interface and GLFWwindowposfun.Handle (abstract) class. This was ugly and had complications related to cleanup. Now we have a GLFWwindowposfun (abstract) class and a GLFWwindowposfun.SAM interface. You never, ever, have to deal with the SAM interface directly, it's only used for Java 8 lambdas (automatic SAM conversions, hence the name).
b) The bindings generator now associates a specific callback type with a specific class (GLFWwindowposfun with GLFW, DEBUGPROCARB with ARBDebugOutput, etc). The class now includes additional methods that construct the callback type, by delegating to the corresponding .SAM interface. This is useful for Java 8 and works in a very clean way using static imports. I got the idea from Kotlin constructors, which look like plain methods, without a "new" keyword". This will make more sense in the examples below.
c) IMPORTANT: The JNI global reference created for each callback, is now a weak reference. The intend is that users that forget to store the callback in their Java code, will very soon get an error (a ClosureError will be thrown with an appropriate message). This way we solve two problems: 1) LWJGL causes no memory leaks by default 2) We guarantee that the user is aware of the problem, even if they skip reading the documentation.
The weak dereference + null check has a minor performance impact (about 10%), but callbacks are almost never performance sensitive and are already fast enough. For example, sending a single character with DebugMessageInsert to an empty DEBUGPROC costs around 270 nanoseconds. That's pretty good for a Java -> JNI -> OpenGL driver -> libffi -> JNI -> Java chain imho.
d) There's a new, optional system property "org.lwjgl.system.libffi.ClosureRegistry". If set, any callback allocated will be automatically registered to a ClosureRegistry instance, retrieved from that system property using reflection. This can be used to do semi-automatic cleanup. This is still experimental, so won't say anything more. An implementation will be available at org.lwjgl.demo.util.ClosureGC.
Examples:
GLFWwindowposfun windowPosFun; // strong reference
// Java 6/7
glfwSetWindowPosCallback(window, windowPosFun = new GLFWwindowposfun() {
@Override
public void invoke(long window, int xpos, int ypos) {
// ...
}
});
// Java 8, lambda
glfwSetWindowPosCallback(window, windowPosFun = GLFWwindowposfun((win, xpos, ypos) -> {
// ..
}));
// Java 8, method reference
glfwSetWindowPosCallback(window, windowPosFun = GLFWwindowposfun(this::windowPosEvent));
// ...after callback has been unregistered, or window has been destroyed:
windowPosFun.release();
Note that GLFWwindowposfun(...) in the Java 8 examples, is a simple static method, not a constructor. It is available automatically by doing an import static org.lwjgl.system.glfw.GLFW.*;
Sounds awesome, some really good changes there.
Also been busy with the compatibility layer, ran into some issues getting LibGDX running. LibGDX seems to run LWJGL in another thread, LWJGL3 doesn't seem to work well on OS X yet when running on a secondary thread, firstly the application was freezing, using -XstartOnFirstThread it gets further however now get an odd looking LWJGL window without a title bar, again suspect its due to LWJGL3 running on a different thread.
Anyway decided to give Minecraft a go and it seems to work well with minimal changes, should be useful for the people who have been requesting better unicode language/chat support:
(http://i.imgur.com/ONuAI0v.png)
A few issues:
Quarter screen size was expected due to HiDPI support being switched on by default in GLFW, don't think there is a runtime switch to turn it off yet without recompiling GLFW with a compiler switch (LWJGL2 didn't use HiDPI mode by default but did have a switch to turn it on).
Did run into one odd issue though, was getting this null pointer exception:
java.lang.NullPointerException: Initializing game
at org.lwjgl.opengl.GL30.nglGenFramebuffers(GL30.java:2364)
at org.lwjgl.opengl.ARBFramebufferObject.glGenFramebuffers(ARBFramebufferObject.java:668)
at net.minecraft.client.renderer.OpenGlHelper.func_153165_e(OpenGlHelper.java:577)
at net.minecraft.client.shader.Framebuffer.createFramebuffer(Framebuffer.java:100)
at net.minecraft.client.shader.Framebuffer.createBindFramebuffer(Framebuffer.java:53)
at net.minecraft.client.shader.Framebuffer.<init>(Framebuffer.java:34)
at net.minecraft.client.Minecraft.startGame(Minecraft.java:538)
at net.minecraft.client.Minecraft.run(Minecraft.java:949)
at net.minecraft.client.main.Main.main(Main.java:161)
at Start.main(Start.java:11)
This is odd because not sure why ARBFramebufferObject.glGenFramebuffers would be calling GL30.nglGenFramebuffers. GL3 doesn't work on OS X unless a forward context is requested hence the crash, shouldn't ARBFramebufferObject be using its own native implementation of this method?
One other thing LWJGL2's GL20.glShaderSource(int shader, ByteBuffer string) is no longer in LWJGL3, to wrap it would it be correct to use the following to obtain the same result?:
public static void glShaderSource(int shader, java.nio.ByteBuffer string) {
org.lwjgl.opengl.GL20.glShaderSource(shader, 1, string, null);
}
In regards to the ARBFramebufferObject.glGenFramebuffers calling the GL30 function, LWJGL 2 does the same thing if it detects that the function exists.
Quote from: kappa on December 03, 2014, 01:22:59Also been busy with the compatibility layer, ran into some issues getting LibGDX running. LibGDX seems to run LWJGL in another thread, LWJGL3 doesn't seem to work well on OS X yet when running on a secondary thread, firstly the application was freezing, using -XstartOnFirstThread it gets further however now get an odd looking LWJGL window without a title bar, again suspect its due to LWJGL3 running on a different thread.
I'm about to give up on OS X + GLFW on any thread other than the first. It's just the way it is on OS X and I don't think there's anything we can do.
We could provide a different solution for OS X + AWT/JavaFX/etc. Something that isn't GLFW that is. Something hacky like what we had in LWJGL 2.
Quote from: kappa on December 03, 2014, 01:22:59Quarter screen size was expected due to HiDPI support being switched on by default in GLFW, don't think there is a runtime switch to turn it off yet without recompiling GLFW with a compiler switch (LWJGL2 didn't use HiDPI mode by default but did have a switch to turn it on).
Yes, it's a compile time flag and the nightly builds have it on. This is (https://github.com/glfw/glfw/issues/200#issuecomment-34627227) what elmindreda has to say on the matter (render to smaller FBO and upscale) and I think I agree.
Quote from: kappa on December 03, 2014, 01:22:59Did run into one odd issue though, was getting this null pointer exception:
java.lang.NullPointerException: Initializing game
at org.lwjgl.opengl.GL30.nglGenFramebuffers(GL30.java:2364)
at org.lwjgl.opengl.ARBFramebufferObject.glGenFramebuffers(ARBFramebufferObject.java:668)
at net.minecraft.client.renderer.OpenGlHelper.func_153165_e(OpenGlHelper.java:577)
at net.minecraft.client.shader.Framebuffer.createFramebuffer(Framebuffer.java:100)
at net.minecraft.client.shader.Framebuffer.createBindFramebuffer(Framebuffer.java:53)
at net.minecraft.client.shader.Framebuffer.<init>(Framebuffer.java:34)
at net.minecraft.client.Minecraft.startGame(Minecraft.java:538)
at net.minecraft.client.Minecraft.run(Minecraft.java:949)
at net.minecraft.client.main.Main.main(Main.java:161)
at Start.main(Start.java:11)
This is odd because not sure why ARBFramebufferObject.glGenFramebuffers would be calling GL30.nglGenFramebuffers. GL3 doesn't work on OS X unless a forward context is requested hence the crash, shouldn't ARBFramebufferObject be using its own native implementation of this method?
Thanks, this was a generator bug that has been fixed in the current nightly.
Quote from: kappa on December 03, 2014, 01:22:59One other thing LWJGL2's GL20.glShaderSource(int shader, ByteBuffer string) is no longer in LWJGL3, to wrap it would it be correct to use the following to obtain the same result?:
public static void glShaderSource(int shader, java.nio.ByteBuffer string) {
org.lwjgl.opengl.GL20.glShaderSource(shader, 1, string, null);
}
I'm afraid not. ShaderSource expects an array of strings, i.e. an array of pointers to strings. You'll have to use a PointerBuffer or a ByteBuffer where your write the memAddress of your string buffer. I didn't add generator support for a single ByteBuffer or an array of ByteBuffers, because I thought it was confusing. Full example:
String source = "#version x.xx";
ByteBuffer string = memEncodeUTF8(source);
PointerBuffer strings = BufferUtils.createPointerBuffer(1);
IntBuffer lengths = BufferUtils.createIntBuffer(1);
strings.put(0, string);
lengths.put(0, source.length());
glShaderSource(shader, strings, lengths);
The latest nightly (#23) has the new callbacks and GLFW moved to org.lwjgl.glfw. I won't update the stable build yet.
Build #23 had a bug that caused crashes instead of throwing ClosureError. This has been fixed now, please download #24.
The latest build, #25, adds Java-friendly struct wrappers:
GLFWvidmode vm = new GLFWvidmode(glfwGetVideoMode(glfwGetPrimaryMonitor()));
int w = vm.getWidth();
int h = vm.getHeight();
int r = vm.getRefreshRate();
System.out.println(w + " x " + h + " @ " + r + "Hz");
Currently a ByteBuffer is wrapped, I will probably add support for direct pointer values (long), to avoid the extra allocation.
nice additions, the java-friendly structs makes code a lot cleaner.
Also the new Callback API are nice, here are some thoughts/feedback:
1) I think something might have broken in recent LWJGL night builds with the GLFWcursorposfun callback as the values returned are not correct (on OS X, using latest nightly build), getting constantly the value: "6.9532603094713E-310" on each mouse move for both xpos and ypos.
2) In terms of API naming and to make it a tiny bit more clearer/consistent, IMO renaming the GLFW*fun to GLFW*Callback might help readability a bit more since they are going to be provided to the glfwSet*Callback methods. Also when looking at the overall lwjgl glfw api and all the classes in it, IMO it would make it clearer to pick up that its a callback function/class, which needs to be provided to one of GLFW's callback methods.
e.g.
current
GLFWkeyfun keyfun = new GLFWkeyfun() {
public void invoke(long window, int key, int scancode, int action, int mods) {
// code
}
};
glfwSetKeyCallback(windowHandle, keyfun);
vs
renamed
GLFWkeyCallback keyCallback = new GLFWkeyCallback() {
public void invoke(long window, int key, int scancode, int action, int mods) {
// code
}
};
glfwSetKeyCallback(windowHandle, keyCallback);
3) In the API we also now have 1 method (glfwSet*Callback) and 1 classes/fun (GLFW*fun) for each glfw callback type, one has to first look up the method needed and then look up the corresponding class type, although they are logically named, I had to refer to the javadoc API almost 18 times to implement 9 different callback types. We could possibly eliminate the need for one look up for each type by just having a single method named glfwSetCallback(), that accepts all the different variations of GLFW*fun.
e.g.
glfwSetCallback(handle, new GLFWkeyfun());
glfwSetCallback(handle, new GLFWcharfun());
glfwSetCallback(handle, new GLFWwindowsizefun());
etc
Thus reducing the API and different names to remember/lookup.
I fully agree with what kappa says.
Quote from: kappa on December 06, 2014, 08:09:201) I think something might have broken in recent LWJGL night builds with the GLFWcursorposfun callback as the values returned are not correct (on OS X, using latest nightly build), getting constantly the value: "6.9532603094713E-310" on each mouse move for both xpos and ypos.
Will look into it.
Quote from: kappa on December 06, 2014, 08:09:202) In terms of API naming and to make it a tiny bit more clearer/consistent, IMO renaming the GLFW*fun to GLFW*Callback might help readability a bit more since they are going to be provided to the glfwSet*Callback methods.
This is a fair request, but there is a counterargument.
On OpenCL, the callback function types are anonymous. For example:
cl_int clBuildProgram (
cl_program program,
cl_uint num_devices,
const cl_device_id *device_list,
const char *options,
void (CL_CALLBACK *pfn_notify)(cl_program program, void *user_data),
void *user_data
)All callback arguments are called "pfn_notify" and that's it basically. So, with OpenCL, I chose arbitrary names (CLProgramCallback, CLEventCallback, CLNativeKernel, etc). They could be better, but I preferred in this case to be compatible with LWJGL 2 (not 100%, but mostly).
The situation is different with OpenGL and GLFW. In both APIs the callback types are explicitly named in the documentation/headers. For example:
// OpenGL
typedef void (APIENTRY *DEBUGPROC)(
GLenum source,
GLenum type,
GLuint id,
GLenum severity,
GLsizei length,
const GLchar* message,
const void* userParam
);
void DebugMessageCallback(DEBUGPROC callback, const void* userParam);
// GLFW
typedef void (* GLFWkeyfun)(GLFWwindow*,int,int,int,int);
GLFWAPI GLFWkeyfun glfwSetKeyCallback(GLFWwindow* window, GLFWkeyfun cbfun);Choosing a different name for the callback types would go against the general theme in LWJGL 3, that of perfectly matching the native signatures.
With that said, the generator already supports using different names (than the native type) for the Java classes, so I can make the change very easily. I personally don't like the "fun" postfix either.
Quote from: kappa on December 06, 2014, 08:09:203) In the API we also now have 1 method (glfwSet*Callback) and 1 classes/fun (GLFW*fun) for each glfw callback type, one has to first look up the method needed and then look up the corresponding class type, although they are logically named, I had to refer to the javadoc API almost 18 times to implement 9 different callback types. We could possibly eliminate the need for one look up for each type by just having a single method named glfwSetCallback(), that accepts all the different variations of GLFW*fun.
e.g.
glfwSetCallback(handle, new GLFWkeyfun());
glfwSetCallback(handle, new GLFWcharfun());
glfwSetCallback(handle, new GLFWwindowsizefun());
etc
Thus reducing the API and different names to remember/lookup.
This is a good idea. Is it OK if these methods are added to the org.lwjgl.glfw.Callbacks class? I'd like to avoid org.lwjgl.glfw.GLFW because it's auto-generated and this is a very special case that won't be applicable to any other binding.
Quote from: spasi on December 06, 2014, 09:27:06
This is a fair request, but there is a counterargument.
On OpenCL, the callback function types are anonymous.
...
All callback arguments are called "pfn_notify" and that's it basically. So, with OpenCL, I chose arbitrary names (CLProgramCallback, CLEventCallback, CLNativeKernel, etc). They could be better, but I preferred in this case to be compatible with LWJGL 2 (not 100%, but mostly).
The situation is different with OpenGL and GLFW. In both APIs the callback types are explicitly named in the documentation/headers.
...
With that said, the generator already supports using different names (than the native type) for the Java classes, so I can make the change very easily. I personally don't like the "fun" postfix either.
At this stage the api can be changed without much problems as people porting LWJGL2 apps will have to make big changes anyway, in any event we should try make the LWJGL side as consistent as we can before hitting alpha.
Quote from: spasi on December 06, 2014, 09:27:06
This is a good idea. Is it OK if these methods are added to the org.lwjgl.glfw.Callbacks class? I'd like to avoid org.lwjgl.glfw.GLFW because it's auto-generated and this is a very special case that won't be applicable to any other binding.
Yeh, that sounds fine.
The latest nightly (#26) has fixed GLFWcursorposfun and GLFWscrollfun. It also has the glfwSetCallback overloads in the Callbacks class.
Quote from: kappa on December 06, 2014, 17:31:46in any event we should try make the LWJGL side as consistent as we can before hitting alpha.
Could you elaborate on what you mean exactly? Should we use the same rules across all APIs? For example:
CLEventCallback
GLDebugMessageCallback (was DEBUGPROC)
GLFWcursorposCallback (was GLFWcursorposfun)
Quote from: spasi on December 06, 2014, 20:57:41
The latest nightly (#26) has fixed GLFWcursorposfun and GLFWscrollfun. It also has the glfwSetCallback overloads in the Callbacks class.
Getting native crash instantly on startup on latest nightly build dump here (http://pastebin.com/3fEAEpDr).
You must be using old native binaries, jni_CallVoidMethodA shouldn't be there.
Quote from: spasi on December 06, 2014, 22:37:35
You must be using old native binaries, jni_CallVoidMethodA shouldn't be there.
Sorry my bad, you are correct, didn't update the natives, works correctly now. Thx for the fix.
Quote from: spasi on December 06, 2014, 20:57:41
The latest nightly (#26) has fixed GLFWcursorposfun and GLFWscrollfun. It also has the glfwSetCallback overloads in the Callbacks class.
Quote from: kappa on December 06, 2014, 17:31:46in any event we should try make the LWJGL side as consistent as we can before hitting alpha.
Could you elaborate on what you mean exactly? Should we use the same rules across all APIs? For example:
CLEventCallback
GLDebugMessageCallback (was DEBUGPROC)
GLFWcursorposCallback (was GLFWcursorposfun)
Yup, i'd say we should use the same rules across the API for callbacks. i.e. they should all end with the word Callback.
Although it would be ideal to keep the native api names, but Callbacks are a special case, having this consistency will allow users to immediately know that its a Callback and they have to deal with it as such (i.e. need to release it when finished with it, etc).
In future there may be bindings to other native api's which might have their own naming scheme but would allow consistency to remain on the lwjgl/java side.
I think I'll also use camel case for GLFW callbacks, i.e. GLFWCursorPosCallback instead of GLFWcursorposCallback.
Quote from: spasi on December 06, 2014, 22:45:57
I think I'll also use camel case for GLFW callbacks, i.e. GLFWCursorPosCallback instead of GLFWcursorposCallback.
Yeh Camel case is probably better, can see why you'd not want to use it though (due to the GLFW acronym prefix being in caps).
Another point that comes to mind is that Callback style functionality in the Java API has traditionally ended with the word 'Listener' but guess in this case its better to keep using 'Callback' since there is also the manual clean up users need to keep in mind. Proper Java style Listeners can easily be added by users themselves on top of Callbacks.
OK, lets make a final decision. Need votes on:
CLEventCallback
GLDebugMessageCallback (currently DEBUGPROC)
GLFWCursorPosCallback (currently GLFWcursorposfun)
vs
EventCallback (currently CLEventCallback)
DebugMessageCallback (currently DEBUGPROC)
CursorPosCallback (currently GLFWcursorposfun)
Also, there's a special case for clEnqueueNativeKernel, the callback is called CLNativeKernel instead of CLNativeKernelCallback. I'd like to keep it that way, because callbacks are notifications that something (else) has happened, whereas native kernels are what's actually happening. It's a subtle difference, but I think adding a Callback postfix there would be weird.
I prefer the first style, GLFWCursorPosCallback etc. Prefix and camel case.
I haven't been able to register for the forums using an outlook email account for days-- finally had to use a gmail account. In any case, I'm here to make a bug report.
Quote
Exception in thread "main" org.lwjgl.system.libffi.ClosureError: Callback failed because the closure instance has been garbage collected.
at org.lwjgl.glfw.GLFW.glfwPollEvents(Native Method)
...
This error occurs at random (after some time has passed) when I press keys after using glfwSetKeyCallback. It seems that something is getting garbage collected that shouldn't. Perhaps this is related to the new ClosureRegistry that attempts to do automatic GC of closures?
It's possible that this affects other callbacks that are GCed at improper times as well, but I haven't tested them.
Also, it doesn't seem to be possible to use the system property "org.lwjgl.system.libffi.ClosureRegistry" to disable the automatic GC. I'm not sure if you intended that to be possible, but for it to work I'd have to set the entry to null, which System.setProperty doesn't allow.
Update: Switched to the latest nightly build and this error still occurs.
QuoteThis error occurs at random (after some time has passed) when I press keys after using glfwSetKeyCallback. It seems that something is getting garbage collected that shouldn't. Perhaps this is related to the new ClosureRegistry that attempts to do automatic GC of closures?
GLFWkeyCallback keyCallback = new GLFWkeyCallback() {
// ...
};Did you store a local reference, as above (keyCallback)? I haven't stared at the ClosureRegistry source (which also doesn't look like it's in use right now), but from the other GLFW/Callbacks source, it looks like callbacks are only freed by nglfwSetWindowPosCallback, which wouldn't store a reference to the Java Callback instance. Hence, the JVM has no way to know that you meant to keep it around, I think.
QuoteGLDebugMessageCallback (currently DEBUGPROC)
Camel case with prefix sounds good. Diverging from native APIs is okay, I think, as long as the naming is more helpful, more Java-like, and has the same meaning.
Alright, I've tried your suggestion and it does indeed seem to solve the problem. However it's rather counterintuitive, since there is no situation in Java where one would typically need to store a reference to a listener/callback object to prevent it from being GCed. I see no reason why glfwSetKeyCallback couldn't store a reference to the callback internally, but the fact that it's a machine-generated file might complicate things. In any case, the documentation should state clearly for each callback function that keeping a reference around is necessary.
@spasi - although second style looks simpler i'd vote for the first style because:
1) Its immediately obvious which library the call belongs to.
2) Future library bindings with style one could end up with callbacks that should have the same name, style two's library name prefix avoids this problem.
I vote for #1 as well.
Quote from: xsupermetroidx on December 07, 2014, 06:56:35However it's rather counterintuitive, since there is no situation in Java where one would typically need to store a reference to a listener/callback object to prevent it from being GCed. I see no reason why glfwSetKeyCallback couldn't store a reference to the callback internally, but the fact that it's a machine-generated file might complicate things. In any case, the documentation should state clearly for each callback function that keeping a reference around is necessary.
LWJGL callbacks are different from typical Java listeners in two ways:
a) They are registered with "native code". This means you're passing a function pointer to a native library, you do not pass a Java object reference. There is no target Java object that will store a reference to the LWJGL callback object.
b) There are "native resources" associated with them (specifically, libffi closures), that must be destroyed when the callback is no longer needed. Otherwise you'd be leaking memory.
There are a few solutions to the above problems, but all come with drawbacks: risk of JVM crashes when not used correctly, worse performance and/or GC implications, complicated implementation details the user needs to be aware of. In the end, we decided that the user should be responsible for storing references and doing manual cleanup. It's the simplest solution, easy to understand, and we also have protection against crashes with the ClosureError that lets users know they have done something wrong.
Quote from: xsupermetroidx on December 07, 2014, 03:14:11Also, it doesn't seem to be possible to use the system property "org.lwjgl.system.libffi.ClosureRegistry" to disable the automatic GC. I'm not sure if you intended that to be possible, but for it to work I'd have to set the entry to null, which System.setProperty doesn't allow.
The ClosureRegistry is experimental and not used by default. It's only active when the
org.lwjgl.system.libffi.ClosureRegistry system property is set. Don't set the property and it will be ignored.
#1 Prefix + CamelCase
#1 Prefix + CamelCase
Build #27 has the renamed callbacks. Exceptions: CLNativeKernel, XErrorHandler, WindowProc
Just updated to latest nightly, API is now a lot cleaner and nicer to work with.
Got some time to work on the LWJGL2 compatibility layer, it now runs Minecraft pretty well.
There were some wanting to use Slick-Util with LWGL3 so wrapped a compatibility layer version of it. It can be downloaded from here (http://slick.ninjacave.com/slick-util3.zip).
Next up tested jMonkeyEngine3 on compatibility layer, however it uses a few extensions which are currently missing from LWJGL3, namely:
- org.lwjgl.opengl.EXTPackedDepthStencil.*;
- org.lwjgl.opengl.EXTPackedFloat.*;
- org.lwjgl.opengl.EXTTextureArray.*;
- org.lwjgl.opengl.EXTTextureCompressionLATC.*;
- org.lwjgl.opengl.EXTTextureSRGB.*;
- org.lwjgl.opengl.EXTTextureSharedExponent.*;
Once implemented it should be able to run jME3. There is also usage of pbuffers in jME3, which if I recall won't be implemented in LWJGL3, so will add a dummy PBuffer class which just returns them as unsupported.
Also the Slick library uses one GL11 variable and two extensions which are not in LWJGL3, namely:
- GL11.GL_ALL_CLIENT_ATTRIB_BITS;
- import org.lwjgl.opengl.EXTSecondaryColor;
- import org.lwjgl.opengl.EXTTextureMirrorClamp;
Thanks, will add missing stuff asap.
Quote from: kappa on December 07, 2014, 18:51:04There is also usage of pbuffers in jME3, which if I recall won't be implemented in LWJGL3, so will add a dummy PBuffer class which just returns them as unsupported.
There's no cross-platform abstraction for pbuffers, but you can use the OS-specific APIs. There's currently support for WGL_ARB_pbuffer and GLX 1.3/GLX_SGIX_pbuffer. NSOpenGLPixelBuffer will be added when bindings generation for ObjC is implemented.
One other thing, seem to be getting a debug error message when running minecraft:
Quote[LWJGL] Failed to locate address for GL function glVertexArrayVertexAttribDivisorEXT
Have been trying to track down its source and noticed its being thrown from within LWJLG3 (was running with '-Dorg.lwjgl.util.Debug=true').
Any idea's why its being thrown or how to fix it?
This function is introduced by ARB_instanced_arrays, but only when EXT_direct_state_access is also available. This interaction was added to the spec many years after its initial release, so drivers are not required to expose it:
QuoteIf implementations respond to a wglGetProcAddress, etc. query for "glVertexArrayVertexAttribDivisorEXT" with a NULL pointer, the DSA functionality is not available.
The correct way to detect it is:
ContextCapabilities caps = GL.getCapabilities();
if ( caps.GL_ARB_instanced_arrays && ARBInstancedArrays.getInstance().VertexArrayVertexAttribDivisorEXT != NULL ) {
glVertexArrayVertexAttribDivisorEXT(vaobj, index, divisor);
}
The LWJGL 3 wiki now has a tutorial section and the first tutorial is up: Ray tracing with OpenGL Compute Shaders (Part I) (https://github.com/LWJGL/lwjgl3/wiki/2.6.1.-Ray-tracing-with-OpenGL-Compute-Shaders-%28Part-I%29), authored by Kai.
Quote from: kappa on December 07, 2014, 18:51:04
- org.lwjgl.opengl.EXTPackedDepthStencil.*;
- org.lwjgl.opengl.EXTPackedFloat.*;
- org.lwjgl.opengl.EXTTextureArray.*;
- org.lwjgl.opengl.EXTTextureCompressionLATC.*;
- org.lwjgl.opengl.EXTTextureSRGB.*;
- org.lwjgl.opengl.EXTTextureSharedExponent.*;
- import org.lwjgl.opengl.EXTSecondaryColor;
- import org.lwjgl.opengl.EXTTextureMirrorClamp;
These extensions have been added. GL11.GL_ALL_CLIENT_ATTRIB_BITS was actually a typo in LWJGL 2, the correct is GL_CLIENT_ALL_ATTRIB_BITS.
Quote from: kappa on November 26, 2014, 00:28:18Lastly the following 2 methods are different
GL20.glVertexAttribPointer(int index, int size, boolean unsigned, boolean normalized, int stride, java.nio.ByteBuffer buffer);
GL20.glVertexAttribPointer(int index, int size, boolean unsigned, boolean normalized, int stride, java.nio.ShortBuffer buffer);
They no longer have the 'unsigned' boolean variable but require an int 'type' variable. This is definitely a change for the better in LWJGL3.
I had another look at this and realized that LWJGL 3 already supports the virtual unsigned argument, it just wasn't applied to this particular function. I've pushed a commit that fixes functions that were missing it, so that all vertex pointer functions are consistent.
Now the question is, should we remove it? First, lets see what is generated now:
// Unsafe version, matches the native function
void nglVertexAttribPointer(int index, int size, int type, boolean normalized, int stride, long pointer)
// Direct mapping of the unsafe version to Java, ARRAY_BUFFER_BINDING == 0
void glVertexAttribPointer(int index, int size, int type, boolean normalized, int stride, ByteBuffer pointer)
// Direct mapping of the unsafe version to Java, ARRAY_BUFFER_BINDING != 0
void glVertexAttribPointer(int index, int size, int type, boolean normalized, int stride, long pointerOffset)
// Below are the "convenient" methods that we may want to change.
// type = GL_BYTE or GL_UNSIGNED_BYTE
void glVertexAttribPointer(int index, int size, boolean unsigned, boolean normalized, int stride, ByteBuffer pointer)
// type = GL_SHORT or GL_UNSIGNED_SHORT
void glVertexAttribPointer(int index, int size, boolean unsigned, boolean normalized, int stride, ShortBuffer pointer)
// type = GL_INT
void glVertexAttribPointer(int index, int size, boolean normalized, int stride, IntBuffer pointer)
// type = GL_FLOAT
void glVertexAttribPointer(int index, int size, boolean normalized, int stride, FloatBuffer pointer)
// type = GL_DOUBLE
void glVertexAttribPointer(int index, int size, boolean normalized, int stride, DoubleBuffer pointer)There are a few issues here:
a) The unsigned argument. It does not exist in the native function and the signature is different for different buffer types.
b) Why is a GL_UNSIGNED_INT version missing?
c) What if we want to use GL30.GL_HALF_FLOAT with a ShortBuffer or GL12#UNSIGNED_INT_2_10_10_10_REV with an IntBuffer?
So, it might make sense to expose the type argument in the convenient methods too, i.e.:
void glVertexAttribPointer(int index, int size, int type, boolean normalized, int stride, ShortBuffer pointer)
void glVertexAttribPointer(int index, int size, int type, boolean normalized, int stride, IntBuffer pointer)
void glVertexAttribPointer(int index, int size, int type, boolean normalized, int stride, FloatBuffer pointer)
void glVertexAttribPointer(int index, int size, int type, boolean normalized, int stride, DoubleBuffer pointer)The pros are that we have full flexibility and one less method (the ByteBuffer version already exists). The cons are:
a) The type argument for the FloatBuffer and DoubleBuffer versions is useless. I don't think it'll ever be anything other than GL_FLOAT and GL_DOUBLE respectively.
b) We break LWJGL 2 compatibility for these functions.
A hybrid solution would be: Replace unsigned with type for integer buffers and hide type for floating point buffers.
I would just expose it. The user is probably going to wrap the method up anyways. And everybody is used to give an OpenGL method like a million arguments already.
Quote from: spasiA hybrid solution would be: Replace unsigned with type for integer buffers and hide type for floating point buffers.
Is this more difficult to do? It seems somewhat optimal. Though is this something that might change in future OpenGL versions? Will there be a float 2.0 or 128bit float, etc, or some type our brains can't yet comprehend?
Quote from: spasi on December 08, 2014, 19:05:13
These extensions have been added. GL11.GL_ALL_CLIENT_ATTRIB_BITS was actually a typo in LWJGL 2, the correct is GL_CLIENT_ALL_ATTRIB_BITS.
super cool stuff, will give it a spin tonight.
In relation to the glVertexAttribPointer variations, just an idea, if we are exposing the type variable for the convenience methods, then do we still need a convenience method for each data type? We could just have one convenience method (thus matching the native style and reducing the API size)
i.e.
glVertexAttribPointer(int index, int size, int type, boolean normalized, int stride, java.nio.Buffer pointer)btw LWJGL's on opengl.org (https://www.opengl.org/) :)
Quote from: kappa on December 09, 2014, 13:45:05In relation to the glVertexAttribPointer variations, just an idea, if we are exposing the type variable for the convenience methods, then do we still need a convenience method for each data type? We could just have one convenience method (thus matching the native style and reducing the API size)
i.e. glVertexAttribPointer(int index, int size, int type, boolean normalized, int stride, java.nio.Buffer pointer)
Yes, we still need the different buffer types. The reason is that the pointer passed to native code depends on the buffer's current .position() and the byte offset needs to be scaled according to the buffer's element type (x1 for ByteBuffer, x2 for ShortBuffer, x4 for Int/Float, etc). It could be implemented with a switch statement on the buffer's .class, but it feels "dirty" and I don't know if it can be optimized by the JVM.
Quote from: spasi on December 09, 2014, 17:07:10
It could be implemented with a switch statement on the buffer's .class, but it feels "dirty" and I don't know if it can be optimized by the JVM.
Also instanceof could be used, e.g.
switch (type) {
case GL11.GL_UNSIGNED_BYTE: case GL11.GL_BYTE:
if (buffer instanceof ByteBuffer) {
// x1
}
break;
case GL11.GL_UNSIGNED_SHORT: case GL11.GL_SHORT:
if (buffer instanceof ShortBuffer) {
//x2
}
break;
case GL11.GL_UNSIGNED_INT: case GL11.GL_INT:
if (buffer instanceof IntBuffer) {
//x4
}
break;
case GL11.GL_FLOAT:
if (buffer instanceof FloatBuffer) {
//x4
}
break;
case GL11.GL_DOUBLE:
if (buffer instanceof DoubleBuffer) {
//x8
}
break;
}
Sorry, I meant an if/else chain, with instanceof. The switch isn't necessary and also hard to maintain (new GL types are introduced all the time).
with the latest extensions in the nightly builds, jMonkeyEngine3 now runs on LWJGL3 using the LWJGL2 compatibility layer, yay :)
(http://i.imgur.com/gekWvmr.png)
Bug report:
glfwSetCursor(window, NULL) results in a NullPointerException. Which happens because glfwSetCursor explicitly checks for NULL as a value and throws the exception.
The documentation states:
Quote
cursor - he cursor to change to, or NULL to switch back to the default system cursor
This means that the only way to change back to the system default cursor is by using glfwDestroyCursor on the current cursor, which might be undesirable.
There's also a minor typo (he instead of the) in there.
Thanks, this has been fixed in build #31.
Very nice job Kappa!
Would be wonderful if we could get a glimpse of the lwjgl2 compat-layer code so we can mess around with it a bit ourselves.
Quote from: Grum on December 14, 2014, 11:14:46
Would be wonderful if we could get a glimpse of the lwjgl2 compat-layer code so we can mess around with it a bit ourselves.
As soon as I get some time will drop it on Github.
The method GL20.glUniform1(int, IntBuffer) is fine, however don't see a similar method for ARBShaderObjects.glUniform1ARB(int, IntBuffer), there is however ARBShaderObjects.glUniform1ARB(int, int count, IntBuffer) available which seems inconsistent (and different from LWJGL2).
same applies for ARBShaderObjects.glUniform2ARB, ARBShaderObjects.glUniform3ARB & ARBShaderObjects.glUniform4ARB.
Quote from: kappa on December 16, 2014, 23:35:38The method GL20.glUniform1(int, IntBuffer) is fine, however don't see a similar method for ARBShaderObjects.glUniform1ARB(int, IntBuffer), there is however ARBShaderObjects.glUniform1ARB(int, int count, IntBuffer) available which seems inconsistent (and different from LWJGL2).
same applies for ARBShaderObjects.glUniform2ARB, ARBShaderObjects.glUniform3ARB & ARBShaderObjects.glUniform4ARB.
This has been fixed in build #33.
Quote from: spasi on December 18, 2014, 22:13:37
This has been fixed in build #33.
Cool, can confirm works as expected.
Thanks.
Quote from: spasi on December 21, 2014, 09:55:09
Disruptor is not necessary anymore with the latest builds. It will soon be removed from the dependencies.
Nice, only a single jar (lwjgl.jar) to worry about (pretty lightweight :) ).
Just a random thought, does the method Sys.touch() need to be a public API? It only seems to be used internally now. Also touch input will be coming in later versions of GLFW 3.x, so maybe this method could be renamed to init() or initialize (as in LWJGL2) to avoid confusion.
Segfaults, Segfaults everywhere!
I'm a noob regarding OpenGL but a rather advanced programmer. I wanted to give the new version of lwjgl a try instead of messing around with the old one I used a couple of years ago and maybe even help with some debugging and stuff.
There are some rather annoying problems though, mostly being segfaults. I'm using Scala instead of Java but never really had a problem there. There are two major segfaults involved:
If I try to close the window with the escape-key or the close window button I always crash like so:
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f85a4e9fa2a, pid=2620, tid=140213512292096
#
# JRE version: OpenJDK Runtime Environment (8.0_25-b18) (build 1.8.0_25-b18)
# Java VM: OpenJDK 64-Bit Server VM (25.25-b02 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C [libffi.so.6+0x4a2a] ffi_closure_free+0x49a
Another may be tied to my small knowledge of OpenGL. When I got a window to display I thought about trying to render something. But as soon as I try to create a new vertex array and bind it, I get a crash.
Using: JRE version: OpenJDK Runtime Environment (8.0_25-b18) (build 1.8.0_25-b18)
As I said, this may not actually be a problem in lwjgl code, but an error on my side. If so, I truly apologize. I'm just learning and maybe mixing up stuff or using it in some way it isn't meant to be used in version 3 of lwjgl anymore.
I attach my example code, just in case somebody wants to give it a try. I assume the erroneous code to be in the Loader class.
PS: I'm not here for you to debug my code, not even subliminal! Just wanted to make sure it's not an error on my side. So if you say that the code compiles and runs just fine, I'm absolutely good with it and will debug and dig through it on my own! :)
@Umami
The problem is because of you are not releasing the callbacks. To avoid this errors, just call the release method on the callbacks before the window is destroyed.
Quote from: SHC on December 22, 2014, 08:01:13
@Umami
The problem is because of you are not releasing the callbacks. To avoid this errors, just call the release method on the callbacks before the window is destroyed.
Thanks, but that's not it.
I switched these two so they look like:
mainWindow.destroy()
glfwDestroyWindow(mainWindow.id)
in the window destroy method the callbacks get released.
Still the same error(s).
(Or am I getting it wrong?)
var vaos:ListBuffer[Int] = new ListBuffer[Int]()
I don't know Scala, but can those List Buffers be freed prematurely? Maybe your freeing fake pointers? Also make sure your using the BufferUtils whenever you pass data to the GPU, it looks like you are though.
Also, if I recall correctly, (it has been a while), this is a part of the VAO state, so just call it during VAO creation.
GL20.glDisableVertexAttribArray(0)
Although I don't think that will fix your problem...
Just noticed: has LWJGL been tested on OpenJDK at all? Is libffi tested on it?
Quote from: shivshank on December 22, 2014, 21:05:17Just noticed: has LWJGL been tested on OpenJDK at all? Is libffi tested on it?
I have never tested on OpenJDK, only on the Oracle JDK.
Quote from: shivshank on December 22, 2014, 21:05:17
var vaos:ListBuffer[Int] = new ListBuffer[Int]()
I don't know Scala, but can those List Buffers be freed prematurely? Maybe your freeing fake pointers? Also make sure your using the BufferUtils whenever you pass data to the GPU, it looks like you are though.
Also, if I recall correctly, (it has been a while), this is a part of the VAO state, so just call it during VAO creation.
GL20.glDisableVertexAttribArray(0)
Although I don't think that will fix your problem...
Just noticed: has LWJGL been tested on OpenJDK at all? Is libffi tested on it?
Thanks, you may be right. I'll try out Java ArrayLists here. Will test it tomorrow.
Well, I used libgdx in the past and lwjgl 2.someish back a few years ago. I always use the openjdk, never the oracle implementation. Shouldn't change much here.
Well, no, it doesn't matter if I use an ArrayList or not. Rewrote the class in java, still the same segfault.
Umami,
Could you please test a simpler version of your program? E.g. simply instantiate a callback and then release it immediately. Other things you can try:
- Clone the LWJGL repo and run the tests (after cloning run ant compile-templates and then ant tests).
- Run your program with a different JDK (e.g. OpenJDK 7 or the Oracle JDK).
Hmm, Umami, I looked again: in Loader.destroy(26), you wrote GL30.glDeleteFramebuffers(i). A VAO is not a frame buffer, I believe you're supposed to use glDeleteVertexArrays, https://www.opengl.org/sdk/docs/man/html/glDeleteVertexArrays.xhtml.
The error you posted says it's with libffi, so I don't know if this makes sense. Would a GPU mis-access cause a seg fault? Could it bubble up?
Hey everyone, I hope you had a merry Christmas! :)
Quote from: shivshank on December 24, 2014, 01:56:47
Hmm, Umami, I looked again: in Loader.destroy(26), you wrote GL30.glDeleteFramebuffers(i). A VAO is not a frame buffer, I believe you're supposed to use glDeleteVertexArrays, https://www.opengl.org/sdk/docs/man/html/glDeleteVertexArrays.xhtml.
The error you posted says it's with libffi, so I don't know if this makes sense. Would a GPU mis-access cause a seg fault? Could it bubble up?
The error happens as soon as I try to create a new VAO:
val vaoID:Int = GL30.glGenVertexArrays()
Crashes my program.
I'm not sure why, though. My drivers should support OpenGL 3 just fine.
Quote
OpenGL version string: 3.0 Mesa 10.3.5
I'm playing a lot of games with the open source drivers and some of them use OpenGL 3 features (at least to my knowledge) and everything works like a charm.
@spasi:
Tried to build the repo-code but it's assuming I use Java 1.6, which I don't and hence the compilation fails :(
I will try the OpenJDK 7, but not the OracleJDK tho.
Quote from: Umami on December 25, 2014, 16:09:20Tried to build the repo-code but it's assuming I use Java 1.6, which I don't and hence the compilation fails :(
You should be able to build with any JDK version >= 6. What error did you get exactly?
Ah, well, my bad. I just had a reeeeeally quick look at the build.xml
Anyway
/home/umami/lwjgl-test/lwjgl3/build.xml:101: The following error occurred while executing this line:
/home/umamil/lwjgl-test/lwjgl3/build.xml:106: /home/umami/lwjgl-test/lwjgl3/${env.JAVA_HOME}/jre/lib does not exist.
I think I've found a bug. This occurred to me on the startup.
2014-12-26 11:58:10.967 java[1955:36431] An uncaught exception was raised
2014-12-26 11:58:10.967 java[1955:36431] *** Collection <__NSSetM: 0x7f9b6506d400> was mutated while being enumerated.
2014-12-26 11:58:10.968 java[1955:36431] (
0 CoreFoundation 0x00007fff8f31a64c __exceptionPreprocess + 172
1 libobjc.A.dylib 0x00007fff8c1b86de objc_exception_throw + 43
2 CoreFoundation 0x00007fff8f319ee5 __NSFastEnumerationMutationHandler + 309
3 AppKit 0x00007fff8d01b59b -[NSView trackingAreas] + 278
4 AppKit 0x00007fff8d109a1a -[NSView(NSInternal) _enableOrDisableTrackingAreas] + 108
5 AppKit 0x00007fff8d114027 -[NSView _windowChangedKeyState] + 665
6 AppKit 0x00007fff8d113ced -[NSFrameView _windowChangedKeyState] + 97
7 AppKit 0x00007fff8d6bc631 -[NSThemeFrame _windowChangedKeyState] + 47
8 AppKit 0x00007fff8d113887 -[NSWindow _setFrameNeedsDisplay:] + 156
9 AppKit 0x00007fff8d10a346 -[NSWindow _makeKeyRegardlessOfVisibility] + 98
10 AppKit 0x00007fff8d10a2ae -[NSWindow makeKeyAndOrderFront:] + 27
11 ??? 0x0000000106e134d4 0x0 + 4410389716
)
2014-12-26 11:58:10.969 java[1955:36431] *** Terminating app due to uncaught exception 'NSGenericException', reason: '*** Collection <__NSSetM: 0x7f9b6506d400> was mutated while being enumerated.'
*** First throw call stack:
(
0 CoreFoundation 0x00007fff8f31a64c __exceptionPreprocess + 172
1 libobjc.A.dylib 0x00007fff8c1b86de objc_exception_throw + 43
2 CoreFoundation 0x00007fff8f319ee5 __NSFastEnumerationMutationHandler + 309
3 AppKit 0x00007fff8d01b59b -[NSView trackingAreas] + 278
4 AppKit 0x00007fff8d109a1a -[NSView(NSInternal) _enableOrDisableTrackingAreas] + 108
5 AppKit 0x00007fff8d114027 -[NSView _windowChangedKeyState] + 665
6 AppKit 0x00007fff8d113ced -[NSFrameView _windowChangedKeyState] + 97
7 AppKit 0x00007fff8d6bc631 -[NSThemeFrame _windowChangedKeyState] + 47
8 AppKit 0x00007fff8d113887 -[NSWindow _setFrameNeedsDisplay:] + 156
9 AppKit 0x00007fff8d10a346 -[NSWindow _makeKeyRegardlessOfVisibility] + 98
10 AppKit 0x00007fff8d10a2ae -[NSWindow makeKeyAndOrderFront:] + 27
11 ??? 0x0000000106e134d4 0x0 + 4410389716
)
libc++abi.dylib: terminating with uncaught exception of type NSException
The previous run is fine, and also the next run, this just occurred once to me, and I also cannot reproduce it again.
I'm on OS X and LWJGL3 is asking me to start on the first thread after upgrading to LWJGL Nightly #35. This problem is not present in #34.
java.lang.IllegalStateException: Please run the JVM with -XstartOnFirstThread.
at org.lwjgl.system.macosx.EventLoop.checkFirstThread(EventLoop.java:20)
at org.lwjgl.glfw.GLFW.glfwInit(GLFW.java:426)
at com.shc.silenceengine.core.Display.create(Display.java:215)
at com.shc.silenceengine.core.Game.start(Game.java:157)
at com.shc.silenceengine.tests.SoundTest.main(SoundTest.java:41)
I know that I can add -XstartOnFirstThread to the VM options, and that indeed works, but for my engine, I'll be happy to find a way that doesn't require me to do that. Is there any way I can use Disruptor myself?
I could walk you through the details (send a PM if you're interested), but I really think you'd be wasting your time. OS X and, by extension, GLFW, are not designed to work that way.
-XstartOnFirstThread as a VM option is pretty much the only way to go on OS X, even SWT requires that to function. The problem is the way the JVM is implemented on OS X and that it reserves the first thread by default for AWT, Swing and JavaFX, so until that changes or GLFW gets support for running from other threads there isn't really a clean way to workaround this.
I still had no luck tinkering with OpenGL 3 and lwjgl 3. One more thing I will try: Setting the opengl context explicitely to version 3.
Have to find out how to do that in lwjgl 3 tho.
If that's not working I'll leave it for now and switch to C++ for my initial prototype. Not exactly what I'd want, because I wanted to use Scala, but, well ...
Quote from: Umami on December 31, 2014, 07:30:15I still had no luck tinkering with OpenGL 3 and lwjgl 3. One more thing I will try: Setting the opengl context explicitely to version 3.
Have to find out how to do that in lwjgl 3 tho.
See the glfwWindowHint (http://javadoc.lwjgl.org/org/lwjgl/glfw/GLFW.html#glfwWindowHint(int,%20int)) documentation. Specifically, the CONTEXT_VERSION_MAJOR, CONTEXT_VERSION_MINOR and maybe OPENGL_PROFILE hints.
So, not sure if that was really it, but I had to move
model = loader.loadToVAO(vertices)
into my update method after I create a GLContext.
Still I can't get my simple quad to render with my shaders, but at least it doesn't crash on startup anymore, which is a tiny success after all. :)
After I dumped my newbie code here, I was always searching at the wrong components, blaming other parts of my system to be faulty. Although it's still not very nice that it crashes instead of throwing an exception stating that the opengl context is missing, which it does in other cases.
Quote from: Umami on January 01, 2015, 12:01:11So, not sure if that was really it, but I had to move
model = loader.loadToVAO(vertices)
into my update method after I create a GLContext.
The reason is simple; you cannot use LWJGL's OpenGL bindings before GLContext.createFromCurrent(). Even if there is a context current in the current thread (after glfwMakeContextCurrent), you must let LWJGL know so that function pointers can be initialized, etc. It is not done automatically for you, because a) it's an expensive operation and b) you may want to reuse GLContext instances in some situations.
Quote from: Umami on January 01, 2015, 12:01:11After I dumped my newbie code here, I was always searching at the wrong components, blaming other parts of my system to be faulty. Although it's still not very nice that it crashes instead of throwing an exception stating that the opengl context is missing, which it does in other cases.
I had another look at your code and decided to download Scala and try it out. Another bug I found was the order of calls in your render loop. You're effectively rendering your model, then calling glClear, then glfwSwapBuffers, which means you're always going to get an empty framebuffer.
The model still isn't rendered after fixing that. I'm not getting any OpenGL errors, but you're not setting glViewport or the PROJECT/MODELVIEW matrices, so your model is probably not visible using the default settings.
I also didn't get any crashes, but I tested on Windows + Oracle JDK. It would be great if you could write a simpler test (preferably in Java) that reproduces the crash.
Ya, it makes absolutely sense. As said, I am an OpenGL noob(ie) and afterwards searched for the error elsewhere, which won't happen again.
Quote from: spasi on January 01, 2015, 20:45:46
I had another look at your code and decided to download Scala and try it out. Another bug I found was the order of calls in your render loop. You're effectively rendering your model, then calling glClear, then glfwSwapBuffers, which means you're always going to get an empty framebuffer.
Wow, how nice of you. Thanks! I redownloaded my old example but... I did it like this there
while (glfwWindowShouldClose(id) == GL_FALSE)
{
// Render
renderer.prepare()
// Swap the color buffers
glfwSwapBuffers(id)
// Poll for window events (key callback is only invoked here)
glfwPollEvents()
renderer.render(model)
}
In prepare() of the renderer I clear the color. That's the first thing you want to do in each frame, is it not?
Then I swap the buffers and then I render the model. Not sure what's wrong here, because that's not the order you stated. (Or I am misunderstanding you)
As for the rest: I'll try, but it will take some time.
Quote from: Umami on January 01, 2015, 22:46:58while (glfwWindowShouldClose(id) == GL_FALSE)
{
// Render
renderer.prepare()
// Swap the color buffers
glfwSwapBuffers(id)
// Poll for window events (key callback is only invoked here)
glfwPollEvents()
renderer.render(model)
}
In prepare() of the renderer I clear the color. That's the first thing you want to do in each frame, is it not?
Then I swap the buffers and then I render the model. Not sure what's wrong here, because that's not the order you stated. (Or I am misunderstanding you)
Note that I said "effectively". It's not the order of the code in the loop, but it's the actual order of rendering. Here's what happens:
1) You clear the backbuffer.
2) You swap buffers, the current back buffer (which is empty) becomes the front and the front becomes the back for subsequent rendering operations.
3) You render the model into the back buffer.
4) go to 1)
So, the front buffer, the one you see on the screen, is always empty.
Since this is all very basic stuff when it comes to rendering with OpenGL (or any other rendering API) and have nothing to do with LWJGL, could you please start a new thread if you have any more questions? This forum has plenty of people who would be glad to help. I'd like to keep this thread focused on discussing the evolution of LWJGL 3 and for reporting issues/crashes/etc. If, for example, you have more info on the ffi_closure_free crash (the one you reported on your first post), please reply here.
Running latest LWJGL nightlies on OS X in which -XstartOnFirstThread is now mandated. Noted that touching any AWT seems to cause an instant application lockup on the AWT call. I was using java.awt.Font to load fonts in the app.
I managed to workaround the lockup using -Djava.awt.headless=true
It does throw the message:
"java[30916:1884135] [JRSAppKitAWT markAppIsDaemon]: Process manager already initialized: can't fully enable headless mode." but otherwise works as expected.
Yes, this is the expected behavior, GLFW and AWT cannot work together. When AWT is initialized it tries to start its event loop in the first thread, but that thread is already occupied by GLFW (and the user's main thread).
It's actually great that it works with java.awt.headless, I hadn't tried that. Is there any difference if you init AWT first and GLFW later?
Thanks for your observation @kappa, it actually works, confirmed on Mac OS X Yosemite, however I'm also getting the same message that you got.
2015-01-02 12:44:59.969 java[1291:10205] [JRSAppKitAWT markAppIsDaemon]: Process manager already initialized: can't fully enable headless mode.
Just ignoring this, is working, thanks again for spotting it.
@spasi
I tried initializing AWT first by creating an instance of Toolkit with Toolkit.getDefaultToolkit(); When I create this before launching GLFW, GLFW asks me to use -XstartOnFirstThread, even though I was having that flag enabled. The solution for now is to use the headless mode, but initialize GLFW before any AWT things.
yeh, doesn't work when AWT is run before GLFW as LWJGL throws the exception "Please run the JVM with -XstartOnFirstThread."
Fonts/Text is one of the big hurdles of using OpenGL & Java (especially now without AWT), bitmap fonts can only go so far and are starting to show their limitations, with the advances in high resolutions and use of unicode (massive amount of glyph sets) the font glyph data is getting more and more essential. Maybe in future we could look at the option for a binding to the FreeType (http://www.freetype.org/) library, its small, fast and has a good licence. Should remove one of the big pain points for end users.
I would support the addition of a font rendering library. Its a pain having to use AWT just for the font support.
Quote from: Cornix on January 02, 2015, 11:09:31
I would support the addition of a font rendering library. Its a pain having to use AWT just for the font support.
Once there is an easy way to access/read font glyph data the rest could be left to the users since there are so many different ways to draw fonts in OpenGL, e.g. see freetype-gl (https://github.com/rougier/freetype-gl), very efficient implementation of fonts in OpenGL using freetype which could potentially be ported to Java/LWJGL.
Quote from: spasi on January 01, 2015, 23:13:13
Since this is all very basic stuff when it comes to rendering with OpenGL (or any other rendering API) and have nothing to do with LWJGL, could you please start a new thread if you have any more questions? This forum has plenty of people who would be glad to help. I'd like to keep this thread focused on discussing the evolution of LWJGL 3 and for reporting issues/crashes/etc. If, for example, you have more info on the ffi_closure_free crash (the one you reported on your first post), please reply here.
Of course, I'm sorry.
Regarding the crash: I'm not sure what a more basic version than the one you provide on your website could look like. The example from the website (getting started) crashes for me, if I try to close the window with either escape-key or the window's "close button"
Quote from: kappa on January 02, 2015, 11:20:44
Quote from: Cornix on January 02, 2015, 11:09:31
I would support the addition of a font rendering library. Its a pain having to use AWT just for the font support.
Once there is an easy way to access/read font glyph data the rest could be left to the users since there are so many different ways to draw fonts in OpenGL, e.g. see freetype-gl (https://github.com/rougier/freetype-gl), very efficient implementation of fonts in OpenGL using freetype which could potentially be ported to Java/LWJGL.
I'd second a way to get easy access to font glyphs, the other good thing about awt.Font is it allows you generate a texture for your chosen font (not completely but enough for you to create a ByteBuffer yourself), so something to help out to create bitmap glyphs would be good too. The freetype-gl seems to do this and more so would be good.
Freetype can create bitmaps too (including with antialiasing if needed).
Having a look at the current available Freetype options for Java, came across two:
Firstly LibGDX has a freetype binding (https://github.com/libgdx/libgdx/tree/master/extensions/gdx-freetype), at a glance it seems to be pretty tightly coupled with LibGDX's internals, so not sure how easy it is to use with a non LibGDX project.
Secondly found MatthiasMann's implementation of freetype (http://hg.l33tlabs.org/javafreetype/file/), seems to be using JNA and the implementation looks clean and straightforward (6 classes), however now sure how complete it is or if its still maintained (last change seems to be 3 years ago).
Other than that haven't found any other useful Freetype java libraries (although internally I think AWT also uses Freetype now).
I found this, opentype.js (https://github.com/nodebox/opentype.js), but it is a JavaScript based font loader that has the option to create a path from glyphs, it also loads kerning information. I doubt whether it can be ported to Java.
a long long time ago the developers of freetype offered up some help in creating JNI wrappers for freetype for someone. I wonder if, when LWJGL3 goes fully live, that we could ask them for help in creating some bindings.
Also...I haven't had time recently to look at how to add new bindings to LWJGL, if there was a wiki "how to" page for adding new binding then maybe some of us can help create one.
Libgdx was mentioned but it would be good to have something standalone
Quote from: SHC on January 02, 2015, 07:20:18Thanks for your observation @kappa, it actually works, confirmed on Mac OS X Yosemite, however I'm also getting the same message that you got.
2015-01-02 12:44:59.969 java[1291:10205] [JRSAppKitAWT markAppIsDaemon]: Process manager already initialized: can't fully enable headless mode.
Just ignoring this, is working, thanks again for spotting it.
@spasi
I tried initializing AWT first by creating an instance of Toolkit with Toolkit.getDefaultToolkit(); When I create this before launching GLFW, GLFW asks me to use -XstartOnFirstThread, even though I was having that flag enabled. The solution for now is to use the headless mode, but initialize GLFW before any AWT things.
I spent a few hours trying to figure out what exactly is going on.
- With -Djava.awt.headless=true, AWT after GLFW works, but there's the warning message.
- With -Djava.awt.headless=true, AWT before GLFW does not work for two reasons:
a) The JVM sets the JAVA_STARTED_ON_FIRST_THREAD_<pid> environment variable when -XstartOnFirstThread is specified. AWT then detects it, sets an internal flag and removes the environment variable. When LWJGL checks it (on glfwInit), it's already gone. I think I can replace this check with an alternative implementation.
b) With the check removed, glfwInit fails with "No monitors found".
- Without -Djava.awt.headless, AWT after GLFW does not work. AWT initialization hangs because isRunning (http://hg.openjdk.java.net/jdk7u/jdk7u60/jdk/file/33c1eee28403/src/macosx/native/sun/awt/awt.m#l372) returns NO (for reasons I don't understand).
- Without -Djava.awt.headless, AWT before GLFW does not work because AWT goes into embedded mode (calls it "SWT or SWT/WebStart mode") and when that happens it calls NSApplicationLoad() (https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Miscellaneous/AppKit_Functions/index.html#//apple_ref/c/func/NSApplicationLoad). SWT knows about this and somehow injects its NSApplication implementation, so everything's fine. GLFW obviously fails to initialize properly.
- Without -Djava.awt.headless and with a very small fix inside GLFW, AWT before GLFW works perfectly. I could even have a GLFW window side-by-side a JFrame. Only limitation: any AWT windows must be disposed before GLFW, otherwise the AWT windows hang without an event loop.
Anyway, it's a freaking mess, I don't know why I'm still wasting time on this. This can only reliably work if we make changes to GLFW to work more like SWT.
On freetype, I had a quick look and it seems straightforward. It's a simple C API with great documentation. On font rendering in general, an alternative approach would be building everything you need offline (glyph metrics, kerning info, texture/vector data in a custom binary format) and not have to depend on AWT or anything else at runtime.
QuoteOn font rendering in general, an alternative approach would be building everything you need offline (glyph metrics, kerning info, texture/vector data in a custom binary format) and not have to depend on AWT or anything else at runtime.
This does only work if you know all Font's you are going to use in advance. If you want to give your user the possibility to use any .ttf font and have them select it you will be in trouble.
Right now I use AWT to build my own Glyph-Textures and then I render them with a VBO. But it is a lot of work and a lot of code and it would be nice if there was a helpful utility library available.
But I can understand if this is low priority right now.
Quote from: Umami on January 02, 2015, 11:26:09The example from the website (getting started) crashes for me, if I try to close the window with either escape-key or the window's "close button"
Have you tried with the latest nightly build? If it still crashes, could you please share the full crash log? (you can attach it to a reply)
I tested the Getting Started on my computer, to try to kill two birds with one stone, so to speak. It appears to work, rendering a red square. However, I've noticed that LWJGL is causing GL_INVALID_ENUM and GL_INVALID_OPERATION errors.
In a different test program I wrote, the same errors:
// code inside of main
System.setProperty("org.lwjgl.util.Debug", "true");
GLFW.glfwInit();
GLFW.glfwDefaultWindowHints();
GLFW.glfwWindowHint(GLFW.GLFW_RESIZABLE, GL11.GL_TRUE);
GLFW.glfwWindowHint(GLFW.GLFW_VISIBLE, GL11.GL_TRUE);
long window = GLFW.glfwCreateWindow(800, 600, "GL Test", 0, 0);
GLFW.glfwMakeContextCurrent(window);
GLContext.createFromCurrent();
checkGLError("Before anything:") // my error checking function
I enabled org.lwjgl.util.debug, and here is the programs output:
[LWJGL] Version 3.0.0a | Windows 7 | amd64
Hello LWJGL 3.0.0a!
[LWJGL] MemoryUtil MemoryAccessor: MemoryAccessorUnsafe
[LWJGL] A GL context was in an error state before the creation of its capabilities instance. Error: Enum argument out of range
[LWJGL] Failed to locate address for GL function glVertexArrayVertexAttribDivisorEXT
Before anything:
GL ERROR: GL_INVALID_OPERATION
I read that Invalid Operation will be raised if glGetError is called before the context is current, of course LWJGL won't let me do that (causes IllegalStateException). These errors don't seem to affect my program, though. I can still render triangles with shaders and control the color (though I haven't gotten my texture loader to work, but I think that's my problem.).
I tried looking through the LWJGL source, it appears that the error has to occur inside the GLContext class, but that's as far as I can understand.
Quote from: shivshank on January 02, 2015, 20:01:38[LWJGL] A GL context was in an error state before the creation of its capabilities instance. Error: Enum argument out of range
[LWJGL] Failed to locate address for GL function glVertexArrayVertexAttribDivisorEXT
Before anything:
GL ERROR: GL_INVALID_OPERATION
glGetError is the first OpenGL function LWJGL calls in GLContext.createFromCurrent(). So the error must be coming from something GLFW does. It's also interesting that you get an INVALID_OPERATION right after, so this could be something LWJGL does wrong, though it's really odd that this hasn't happened to anyone else.
Could you share some details about your system? (OS, GPU, driver version, JVM version)
Hm, if I recall correctly the computer is from 2009. If I query the OpenGL version, I think it supports 3.2 now, but the original drivers did not.
GPU: ATI Radeon 5750 HD
Driver: ATI Radeon 5770 HD (v8.680.0.0) - that's not a typo... its apparently using a driver from a different card (November 2009)?
OS: Windows 7 Home Premium
JVM: (I ran java -version)
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b18)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
I just realized I actually have the source on my machine; out of curiosity, which file generates ContextCapabilities.java? I'm digging around trying to understand the GitHub repo, but I was unable to find the file on there.
Quote from: spasi on January 02, 2015, 17:20:43
Anyway, it's a freaking mess, I don't know why I'm still wasting time on this.
Its a challenge, which is always fun :) but yeh best not to continue wasting time on this. Once Java 9 and the jigsaw project are released, I suspect AWT will be phased out pretty quickly.
Quote from: spasi on January 02, 2015, 17:20:43
On freetype, I had a quick look and it seems straightforward. It's a simple C API with great documentation. On font rendering in general, an alternative approach would be building everything you need offline (glyph metrics, kerning info, texture/vector data in a custom binary format) and not have to depend on AWT or anything else at runtime.
The main reasons for the continued AWT usage in LWJGL applications are:
1) Support for multiple windows - This is now addressed in LWJGL3, it was by far the biggest reason people wanted to use AWT with LWJGL2.
2) Image Loading - This is another area where AWT usage was pretty high, LWJGL1 did provide Devil (http://openil.sourceforge.net/) support for a while, however was removed as it was a needless time and effort drain to maintain when such functionality was already built into the JRE/AWT. With the rise of Android and other efforts we've since seen many pure java decoders appearing (notably the MatthiasM PNG/TGA/JPG Decoder series and others), which are faster and skip the unnecessary step of converting from an AWT Image to a NIO buffer. Therefore AWT is no longer required here.
3) Sound Loading - LWJGL use to have a Fmod (http://www.fmod.org/) binding and was removed for the same reasons as above. Again there are now a lot of nice standalone decoders (Wav, Ogg, MP3, XM, etc) which weren't around when LWJGL2 was released therefore again AWT is no longer required for this.
4) Solid and familiar GUI - AWT/Swing usage was pretty entrenched with Java users, however now that we have JavaFX, AWT/Swing is being depreciated, most users are moving away from it. We saw some pretty good and solid OpenGL GUI's with LWJGL2, now with all the new GLFW functionality LWJGL3 can potentially have much more multi-window GUI's that can emulate the functionality of AWT/Swing. In fact its probably even possible to write a clone for the AWT/Swing API running on LWJGL3.
5) Applets - This was another reason AWT was required in LWJGL2. Applets are all but dead now so this no longer applies.
6) Font Loading - This is probably the last area where Java/LWJGL support is weak and a library or binding to assist would really help. Other than the options mentioned previously, AWT is probably the most solid choice ATM to get Glyph information, even the support in JavaFX does not provide the low level details need for OpenGL usage. Freetype seems like the best choice for this as it has support for lots of formats, actively maintained and pretty small.
Quote from: shivshank on January 02, 2015, 21:08:25out of curiosity, which file generates ContextCapabilities.java?
It's src/templates/org/lwjgl/opengl/FunctionProviderGL.kt, see the generateContent() function.
Quote from: kappa on January 02, 2015, 22:22:45Freetype seems like the best choice for this as it has support for lots of formats, actively maintained and pretty small.
I'm currently done with bindings to the Objective C Runtime (needs more work to be user-friendly) and have also started bindings to libOVR (Oculus SDK). I'll work on freetype after those two are done.
Quote from: spasi on January 02, 2015, 23:31:34
I'm currently done with bindings to the Objective C Runtime (needs more work to be user-friendly) and have also started bindings to libOVR (Oculus SDK). I'll work on freetype after those two are done.
super cool stuff :)
Quote from: spasi on January 02, 2015, 17:45:55
Quote from: Umami on January 02, 2015, 11:26:09The example from the website (getting started) crashes for me, if I try to close the window with either escape-key or the window's "close button"
Have you tried with the latest nightly build? If it still crashes, could you please share the full crash log? (you can attach it to a reply)
Sure.
One note: The same thing happens if I compile with Java 7, so it's definitely not the Java-Version.
Quote from: Umami on January 03, 2015, 11:43:03Sure.
One note: The same thing happens if I compile with Java 7, so it's definitely not the Java-Version.
Thank you Umami, the log helped a lot. Please try the current nightly (#37), the problem should be fixed.
Quote from: spasi on January 03, 2015, 20:42:10
Quote from: Umami on January 03, 2015, 11:43:03Sure.
One note: The same thing happens if I compile with Java 7, so it's definitely not the Java-Version.
Thank you Umami, the log helped a lot. Please try the current nightly (#37), the problem should be fixed.
Seems to be fixed, yes! Thanks a lot.
Now I have to understand what I'm doing wrong with my shaders and rendering, but that's not for this thread :)
Came across a pretty cool little project called tiny file dialogs (http://www.reddit.com/r/gamedev/comments/2rxwmp/tiny_file_dialogs_ive_released_a_single_c_file/). There isn't an alternative to LWJGL2 Sys.alert in LWJGL3 and something like this could be useful if such functionality is needed.
In any event, with LWJGL3's new direction not sure if something like the above belongs in there anymore and should instead be requested to be included in GLFW.
I know we've looked at the layout of the natives before, however the directory structure is still a little rigid, most of the launchers for LWJGL2, tools for creating single jars and extracting natives at runtime, rely on the natives being in the same directory (and just simply extract by file extension).
The LWJGL native code is doing something roughly like the following:
String osName = System.getProperty("os.name"); // then trim the name
String arch = System.getProperty("os.arch");
String name = lwjgl; // name of native
String natives = System.getProperty("org.lwjgl.librarypath");
Then loaded by LWJGL as follow:
String path = natives + File.separator + osName + File.separator + arch + File.separator + System.mapLibraryName(name);
The problem for all the launchers is that the code complexity is then passed onto them when extracting natives, they need to either now have code to check the platform, arch, check if such directories exist and then extract the correct natives or they'll need to extract natives and create directories in the layout LWJGL3 uses (i.e. */osName/arch/*).
An alternative approach that LWJGL3 could use is put the osName and arch in the file name instead as follows:
String path = natives + File.separator + System.mapLibraryName(name + "-" + osName + "-" + arch);
In addition to being easily able to identify what os and arch the native is for it would allow bundling the natives in a single directory.
Alternatively we can get away with having just the arch in the file name (and osName can remain a folder), since the extensions for the 3 platforms LWJGL supports are named differently on each OS (*.dll, *.dylib, *.so) and then they could be included in the same folder where needed but distributed using the osName folder structure.
+1 for having all natives in a single folder with the proposed naming scheme.
We currently have to only deal with OpenAL and LWJGL itself. What happens if we later add more and more libraries? It becomes a pita to have to rename every 3rd party library to exactly match the LWJGL naming scheme.
What are the tools that have trouble with the current scheme?
Do you think that LWJGL adds new libraries with such high frequency that updating an automatic renaming script (via Ant or something) would be such a big burden?
Currently LWJGL also has a renaming script, which comes in the form of copying the downloaded files to the respective OS'es arch's folders. So changing that into a simple renaming would not be a big issue, in my honest opinion.
Scripting the actual renaming isn't a problem, but the naming scheme is, for some libraries. For example, the official name of the OpenAL library is OpenAL32.dll on Windows:
LWJGL 3:
windows/x86/OpenAL32.dll
windows/x64/OpenAL32.dll
LWJGL 2:
OpenAL32.dll
OpenAL64.dll (what?)
LWJGL 3 (proposed):
OpenAL32_x86.dll
OpenAL32_x64.dll
Make it ugly and non-standard just because some tool has trouble with extracting files?
But isn't the actual name of a DLL completely irrelevant here?
Personally I find it the most irritating that OpenAL for 64 bit is actually called OpenAL*32*.dll.
I would vote for just changing that and the corresponding ALC.java:35.
Quote from: spasi on January 14, 2015, 18:02:30
What are the tools that have trouble with the current scheme?
Most of the far jar tools namely: Eclipse's built in executable jar tool, One-Jar (http://one-jar.sourceforge.net/), Launch4j (http://launch4j.sourceforge.net/), JarMatey (http://staticvoidgames.com/JarMatey), etc.
Quote from: spasi on January 14, 2015, 18:02:30
We currently have to only deal with OpenAL and LWJGL itself. What happens if we later add more and more libraries? It becomes a pita to have to rename every 3rd party library to exactly match the LWJGL naming scheme.
Yeh good point, naming conventions do differ between native libraries with some including the arch name and others not. Guess it just boils down to picking a convention we want to stick to for LWJGL, but do agree with Kai, native names don't really matter much if they are in our control (unless there are plans to use natives found on a system or something). We should try to go with a convention that allows the most flexibility for users and not stick with one that restricts certain types of use (such as wanting them all in one folder). An option that might keep everyone happy, maybe there could be an option for users to manually set library names (e.g. using System.setProperty) rather than having fixed names.
Why not another system property that selects the naming/layout scheme?
Can there then be an additional build script/target that switches the active library layout scheme? Say it walks the directories, renames, and moves all of the native libraries?
Quotemaybe there could be an option for users to manually set library names (e.g. using System.setProperty) rather than having fixed names
The code is already there for that, is it not:
create(System.getProperty("org.lwjgl.openal.libname", libName));(from ALC.java)
Quote from: shivshank on January 15, 2015, 00:28:28
The code is already there for that, is it not:
create(System.getProperty("org.lwjgl.openal.libname", libName));
(from ALC.java)
Nice, didn't notice that one, just need one for the lwjgl native ("org.lwjgl.libname") before its usable for things like all natives in one directory.
So the following line in org.lwjgl.Sys
private static final String JNI_LIBRARY_NAME = "lwjgl";could be changed to
private static final String JNI_LIBRARY_NAME = System.getProperty("org.lwjgl.libname", "lwjgl");
Quote from: kappa on January 15, 2015, 10:24:47just need one for the lwjgl native ("org.lwjgl.libname")
Added support for this.
Quote from: spasi on January 02, 2015, 17:20:43
- Without -Djava.awt.headless and with a very small fix inside GLFW, AWT before GLFW works perfectly. I could even have a GLFW window side-by-side a JFrame. Only limitation: any AWT windows must be disposed before GLFW, otherwise the AWT windows hang without an event loop.
Any updates on this? (It seems that GLFW 3.1 is nearly there)
I was playing with GLFW / Swing on OSX (only for a OSX menubar). Newer nightly builds now ask me to use -XstartOnFirstThread. If I use it and start GLWF first, AWT/Swing seem not to work. If I start AWT/Swing first they erase the -XstartOnFirstThread flag as you said and GLFW does not load.
Will this small fix become available?
UPDATE:
I tested with the option with -Djava.awt.headless=true, and the result was this:
Exception in thread "AWT-EventQueue-0"
"Application.setDefaultMenuBar() only works with the Aqua Look and Feel"
Then I saw what headless do I realised that it definitively is not a solution for any application other than a single-windowed game (even multi-windowed games, map editors, etc may need auxiliary gui components, floating windows, etc)
--
What JGLFW do different?
"Integration with Swing or AWT is not possible (so, no Applets either).
You can however open Swing and AWT frames besides GLFW windows."
https://github.com/badlogic/jglfw
--
UPDATE 2:
I see the issue is old:
http://www.java-gaming.org/topics/lwjgl3-moves-to-glfw/30793/view.html
I spent a lot of time researching this but the issue is definitively beyond my expertise. I thought I only need to create windows and render stuff in the main thread (i.e. whatever thread started launched my application). If I have my app running before any calls to AWT I do not see how it can interfere with GLFW unless, if I understood correctly, the JVM reserves a thread for AWT and launches your app in a secondary thread (if you do not use -XstartOnFirstThread).
Before the changes you guys did in EventLoop.java it seemed to work. (Actually, I did not understood why lwjgl would needed to initialise AWT in the old version)
Quick question, I am querying GL_MAX_TEXTURE_SIZE (https://www.khronos.org/opengles/sdk/1.1/docs/man/glGet.xml) using GL11.glGetInteger which according to the OpenGL docs returns 1 value.
IIRC in LWJGL2 you were required to provide glGetInteger a 16 int buffer e.g.
IntBuffer buffer = BufferUtils.createIntBuffer(16);
glGetInteger(GL_MAX_TEXTURE_SIZE, buffer);
return buffer.get(0);
Noticed that in LWJGL3, you can use BufferUtils.createIntBuffer(1); without any exception being thrown, is this a change now allowed or is it still recommended to use a 16 int buffer?
Quote from: advanced_set on January 18, 2015, 20:06:51Any updates on this? (It seems that GLFW 3.1 is nearly there)
I was playing with GLFW / Swing on OSX (only for a OSX menubar). Newer nightly builds now ask me to use -XstartOnFirstThread. If I use it and start GLWF first, AWT/Swing seem not to work. If I start AWT/Swing first they erase the -XstartOnFirstThread flag as you said and GLFW does not load.
Will this small fix become available?
I'm afraid not. I would love to be proven wrong, but I've spent a lot of time trying to make GLFW+AWT work together and could not find a clean solution.
Keep in mind that we're currently in the process of finalizing LWJGL 3.0. Any feature added officially will be a burden throughout the library's lifetime. Right now AWT integration feels hacky, broken, inelegant. Even if that's true for only one of the 3 OSes we support, if we officially enable AWT integration the support pain will be extremely painful. Just like it was with LWJGL 2. LWJGL 3 has been designed to allow for such additional features to be layered on top of the base library, there's basically nothing that LWJGL does internally that you can't do externally. If someone figures out a decent solution, it doesn't really have to be part of the official distribution.
Quote from: advanced_set on January 18, 2015, 20:06:51I spent a lot of time researching this but the issue is definitively beyond my expertise. I thought I only need to create windows and render stuff in the main thread (i.e. whatever thread started launched my application). If I have my app running before any calls to AWT I do not see how it can interfere with GLFW unless, if I understood correctly, the JVM reserves a thread for AWT and launches your app in a secondary thread (if you do not use -XstartOnFirstThread).
Before the changes you guys did in EventLoop.java it seemed to work. (Actually, I did not understood why lwjgl would needed to initialise AWT in the old version)
The problem is the inherent design of OS X. You cannot have two threads driving a GUI event loop, it must be only one and it also has to be the first thread of the process. So, you need 1 event loop driving two different libraries. AWT and SWT have explicit support (i.e. nasty hacks) for such a cooperation, but GLFW is entirely oblivious to that. A working solution would require modifications to GLFW, rules for which library is initialized first, destroyed last, etc. I firmly believe this is outside the scope of LWJGL 3 and we don't have the people or time to support such a solution.
If I were building a GLFW + Swing/JavaFX app right now, I would use a different process for the GLFW window(s). The first thread limitation only applies per-process and you could use an ultra-fast IPC mechanism (e.g. Disruptor) to communicate between the two processes.
Quote from: kappa on January 27, 2015, 11:09:19Noticed that in LWJGL3, you can use BufferUtils.createIntBuffer(1); without any exception being thrown, is this a change now allowed or is it still recommended to use a 16 int buffer?
Yes, the check has been changed from 16 values to 1. The logic behind that decision is that there's nothing LWJGL can do to completely eliminate possible crashes, especially with OpenGL. Instead of pretending that we're a somehow "safe" library, we prefer convenience and never impose artificial limitations that don't exist in the native API.
Thanks for the reply. This reduces a bit the scope of the library but I agree you're going the right direction. Cleaner and smaller is better.
Quote from: spasi on January 27, 2015, 12:23:01
If I were building a GLFW + Swing/JavaFX app right now, I would use a different process for the GLFW window(s). The first thread limitation only applies per-process and you could use an ultra-fast IPC mechanism (e.g. Disruptor) to communicate between the two processes.
Hum... I 'll have a look, this could work.
Quote from: spasi on January 27, 2015, 12:29:07
Yes, the check has been changed from 16 values to 1. The logic behind that decision is that there's nothing LWJGL can do to completely eliminate possible crashes, especially with OpenGL. Instead of pretending that we're a somehow "safe" library, we prefer convenience and never impose artificial limitations that don't exist in the native API.
Nice, this approach is much better. In any event, the layer of code above LWJGL should be checking and catching these things anyway.
Also its more memory efficient now, yay :) (not that a couple of extra int's make that much difference on today's systems)
Hi, what is the best approach to have the same decorated functionality (re-sizing, moving, maximize, etc.) when its off ? Im currently using libgdx scene2d for UI stuff and wonder is there is a easy solution to mimic it.
Quote from: spasi on January 02, 2015, 23:31:34
I'll work on freetype after those two are done.
Just want to ask, is there any progress on this? It would be really helpful for me to have freetype available.
I'm afraid I'm still super busy at work and haven't had any free time lately. Once the storm passes, I'll focus first on doing the 3.0a release (which is long overdue) and then work on new features.
Question:
Running an empty loop gives me about 50.000.000 execution per second, but after adding glfwSwapBuffers its slowed down to only 250 executions per second; is that how it suppose to work? (Take in mind i'm not rendering anything). I'm using lastest LWJGL3 stable version.
My current hardware is:
CPU: Intel I7 950.
GPU: NVIDIA GTX 570
Driver: Lastest Nvidia drivers.
OS: Windows 8.1 Home Premium.
java version "1.8.0_31"
Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)
UPDATE: Set GLFW.DOUBLE_BUFFER to false and now i get upto 30.000 executions per second (Desired) just using glfwSwapBuffers, is that a bug? shouldn't DOUBLE_BUFFER be deactivated by default?
Dear LWJGL users,
I'm excited to announce that LWJGL 3.0a is ready to be released. Please, if you've got the time, download (http://www.lwjgl.org/download) the current nightly build (#45) and give it a spin. If no problems are reported, it will be promoted as the first official release.
Latest noteworthy changes:
- Java methods now have the same postfixes as the corresponding native functions (see this thread (http://forum.lwjgl.org/index.php?topic=5746.0) for details).
- Updated the GLFW and OpenAL Soft binaries to the latest versions. LibFFI is on 3.1.1, newer revisions are still broken on MSVC.
- Added support for the Objective-C Runtime. With the existing LibFFI bindings, you now have a (disgustingly horrible) way to use Cocoa APIs, if you have to.
- Added support for libOVR, the C API of the Oculus Rift SDK. The bindings are up-to-date with the recently released 0.5.0.1-beta SDK.
- The build is now "modular", which means that if you decide to manually build LWJGL, you have the option to include or exclude any bindings you like. For example, if you never use OpenCL, you can exclude it from the build. Currently, the default build includes all modules, except libOVR.
- There's been much effort to simplify the build process and make it easier for contributors to get started. The IntelliJ project should now work out-of-the-box. If you're a Rift user and would like to build LWJGL with libOVR enabled, all you have to do is extract the Oculus SDK somewhere and point to it in config/build-modules.xml.
- The dynamically linked libraries that LWJGL must load at runtime have all been moved to the same location (see this discussion (http://forum.lwjgl.org/index.php?topic=4800.msg29988#msg29988)). The old "/os/arch/" structure is now gone. The x64 binaries are simply named (e.g. lwjgl.dll, OpenAL.dll), while the x86 binaries have a "32" postfix (e.g. lwjgl32.dll, OpenAL32.dll).
Features coming soon:
- Gradle build + Maven deployment
- Mantle bindings
Features coming later:
- Support for all (still relevant) OpenGL extensions
- EGL and OpenGL ES bindings
- Vulkan bindings (when the spec is released)
- D3D12 bindings
There will be a post on the LWJGL blog with more details.
I'm just updating my code to #45 from #41, and my code did break at some places, but I think most of them are intended. Here are the differences that I have noticed.
- The post suffix fv for glUniformMatrix4 calls.
- The natives file locations
- The GLFWgammaramp class seems to have missing out the malloc(short, short, short, int) method. It's now taking long variables instead.
- The getSize method of the GLFWgammaramp class seems returning 256 when there are only 128 elements in the buffer.
(http://i.imgur.com/mQYS1vz.png)
I'm creating the arrays with length returned from the getSize method. Can you please give me clarity on what maybe wrong here?
Everything else is fine with this build.
The postfixes and new native file locations are intended, as explained above.
GLFWgammaramp never had a malloc(short, short, short, int), it was malloc(long, long, long int) (https://github.com/LWJGL/lwjgl3-generated/blob/6e44d4fd03701bd5ba0a915bf60d1573799f29f4/java/org/lwjgl/glfw/GLFWgammaramp.java#L84). That method is now gone (https://github.com/LWJGL/lwjgl3-generated/blob/master/java/org/lwjgl/glfw/GLFWgammaramp.java) though, there's only malloc(ByteBuffer, ByteBuffer, ByteBuffer, int).
getSize returns the value stored in the GLFWgammaramp.size field, which should be 256 (http://www.glfw.org/docs/latest/group__monitor.html#ga583f0ffd0d29613d8cd172b996bbf0dd).
Thanks for clearing it, but the returned buffers only have 128 elements? That's what I'm not able to understand.
I'm guessing here, but I think you're calling the getRed(int), getGreen(int), getBlue(size) methods and pass the value returned from getSize() there. Then, you're probably converting the ByteBuffers to ShortBuffers.
The problem is that getSize() returns the number of elements in each buffer, but the getR/G/B methods expect a byte size. So, if getSize() returns 256, you should pass 256*2 = 512 to the getR/G/B methods.
Thanks a lot, that worked awesome. There are no other issues, everything is fine.
oh, nice changes, upgraded fine here (only minor code changes needed) and works nicely.
Good job.
This is a good opportunity to mention that structs in general will be redesigned before the final 3.0 release (most likely in a breaking way). In GLFWgammaramp's case, we should either change the getters/setters to use ShortBuffers instead of ByteBuffers, or change the size argument to always mean elements instead of bytes.
I have not been happy with the current situation and Java (the language) doesn't help at all. There hasn't been much feedback or suggestions from users either. I'm also planning to improve Javadoc generation for structs, so that non-obvious fields can be documented. Note that new APIs, like Mantle and Vulkan, make heavy use of structs (vs having tons of methods, like in OpenGL). We didn't have to worry about this in LWJGL 2, but in 3 we'll have to provide a decent solution. For example, an (optional) integration with LibStruct (https://github.com/riven8192/LibStruct) would be nice.
Are the Projects Valhalla (http://openjdk.java.net/projects/valhalla/) or Panama (http://openjdk.java.net/projects/panama/) going to be of any help to LWJGL's structs implementation? If so, might be worth waiting for them as an official solution.
Just curious, is the Mantle library even relevant anymore or worth implementing? given that its specific to AMD hardware (and the Windows OS, unlikely to come to Mac or Linux now) and most companies are throwing their weight behind Vulkan (including AMD) and will likely do what Mantle does but better.
Quote from: kappa on April 26, 2015, 17:59:00Are the Projects Valhalla (http://openjdk.java.net/projects/valhalla/) or Panama (http://openjdk.java.net/projects/panama/) going to be of any help to LWJGL's structs implementation? If so, might be worth waiting for them as an official solution.
Valhalla, no. Anything they do will be heap-based for sure. Super-interesting and useful if you're doing server programming, but does nothing for native interop. Panama is more promising, but we're talking Java 10 (at best). LWJGL 4 will be out when that's mainstream enough.
Quote from: kappa on April 26, 2015, 17:59:00Just curious, is the Mantle library even relevant anymore or worth implementing? given that its specific to AMD hardware and most are now throwing their weight behind Vulkan (including AMD) and will likely do what Mantle does but better.
Yes, for a few reasons:
- It won't affect the official LWJGL build. The Mantle bindings will be an optional module and you'll have to manually build LWJGL to use it. It's currently Windows-only anyway.
- Mantle is not dead. AMD will use it as a faster way to get exciting new features to customers. Like NV's CUDA. If you only care about Mantle 1.0 features, then obviously Vulkan will be better (and that's AMD's suggestion too).
- I think many people are excited about Vulkan and Mantle is a very nice way to get a glimpse of what's coming. The two APIs are very similar and you can start preparing for Vulkan right now.
just tested LWJGL3.0a on Windows XP, 32bit but getting the following exception on startup:
Quote
[LWJGL] Version 3.0.0a | Windows XP | x86
[LWJGL] MemoryUtil MemoryAccessor: MemoryAccessorUnsafe
INFO: Initialising sounds..
Exception in thread "main" java.lang.ExceptionInInitializerError
at org.lwjgl.openal.ALDevice.create(ALDevice.java:71)
at org.lwjgl.openal.ALDevice.create(ALDevice.java:60)
at org.ninjacave.mech.audio.SoundStore.createAL(SoundStore.java:80)
at org.ninjacave.mech.audio.SoundStore$1.run(SoundStore.java:294)
at java.security.AccessController.doPrivileged(Native Method)
at org.ninjacave.mech.audio.SoundStore.init(SoundStore.java:291)
at org.ninjacave.mech.Sound.<init>(Sound.java:54)
at org.ninjacave.game.topjump.GameState.init(GameState.java:34)
at org.ninjacave.mech.App.initStates(App.java:208)
at org.ninjacave.mech.App.init(App.java:171)
at org.ninjacave.mech.App.start(App.java:152)
at org.ninjacave.game.topjump.TopJump.main(TopJump.java:14)
Caused by: java.lang.RuntimeException: Failed to load library: C:\Documents and Settings\computer\workspace\myapp\native\OpenAL32.dll (error code = 0)
at org.lwjgl.system.windows.WindowsPlatform.windowsThrowException(WindowsPlatform.java:34)
at org.lwjgl.system.windows.WindowsLibrary.<init>(WindowsLibrary.java:33)
at org.lwjgl.system.APIUtil.apiCreateLibrary(APIUtil.java:54)
at org.lwjgl.LWJGLUtil$2.load(LWJGLUtil.java:403)
at org.lwjgl.LWJGLUtil$2.load(LWJGLUtil.java:400)
at org.lwjgl.LWJGLUtil.loadLibrary(LWJGLUtil.java:411)
at org.lwjgl.LWJGLUtil.loadLibraryNative(LWJGLUtil.java:371)
at org.lwjgl.openal.ALC.create(ALC.java:55)
at org.lwjgl.openal.ALC.create(ALC.java:48)
at org.lwjgl.openal.ALC.<clinit>(ALC.java:27)
... 12 more
Quote from: kappa on April 27, 2015, 09:49:33just tested LWJGL3.0a on Windows XP, 32bit but getting the following exception on startup:
Thanks, I cleaned-up the synchronization scrips for CI and forgot the fixes (https://github.com/LWJGL-CI/openal-soft/commit/d22007b02504ce369203ecb708bc778346841f79#diff-af3b638bc2a3e6c650974192a53c7291) for Windows XP. Build #46 is up and should work fine.
Quote from: spasi on April 26, 2015, 17:41:01In GLFWgammaramp's case, we should either change the getters/setters to use ShortBuffers instead of ByteBuffers, or change the size argument to always mean elements instead of bytes.
For now, I have renamed (https://github.com/LWJGL/lwjgl3-generated/commit/29b826a73a951a10af8aed85b7f0e946d87f2547#diff-cf61b58243d2d32a8075d012f896028f) the "size" parameter to "byteLen". This avoids the confusion with the struct's size field and makes it clear that you must specify a length in bytes for the returned ByteBuffer.
Quote from: spasi on April 27, 2015, 13:39:22
Thanks, I cleaned-up the synchronization scrips for CI and forgot the fixes (https://github.com/LWJGL-CI/openal-soft/commit/d22007b02504ce369203ecb708bc778346841f79#diff-af3b638bc2a3e6c650974192a53c7291) for Windows XP. Build #46 is up and should work fine.
Thanks, can confirm that it works fine now.
The LWJGL3.0a natives in the release total at about 5mb (about 5 times the size of the 1mb lwjgl.jar) which is not bad.
However I recalled that Mazon used to use UPX (http://upx.sourceforge.net/) on official releases. So had a quick go at UPX'ing the LWJGL3 natives and it pretty much shrinks them to about half the size. The four windows natives went from 1.81mb down to 951kb (plus shrinks further when compressed into a zip file to 683kb). The four linux natives went from 2.22mb down to 1.05mb (and 644kb when inside a zip file).
UPX works on LWJGL's 32/64 windows and linux natives (OS X 64 natives support isn't there yet) and can be run on the all natives from a single OS.
Although not much saving in the grand scheme of things, I'd say its a good thing to maintain for official releases as natives are often kept outside zip/jar files and it keeps the perception of the LWJGL library being small and compact (making the jar and natives total at just over 1mb for each platform arch).
Thanks kappa, support for UPX has been added (https://github.com/LWJGL/lwjgl3/commit/63e38753d813de004cca3d6e7416ec6b757b7b4a). It is optionally enabled with:
Quoteant compile-native -Dorg.lwjgl.upx=<path to folder that contains the UPX executable>
The build servers have been updated and it will be done automatically from now on. I've also updated 3.0.0a with the compressed binaries. The final .zip didn't change by much, but we'll provide separate downloads for binaries, source and documentation in the near future.
Spasi is GLFWCursorPosCallback being invoked by it self every 1 sec when there is no mouse movements?
I was updating libgdx backend and I detected this. Is it a bug or its normal?
It shouldn't happen. On what platform(s) did you test? If you can build LWJGL locally, try the Events demo:
Quoteant demo -Dclass=org.lwjgl.demo.glfw.Events
and see if it behaves similarly.
LWJGL3a is in pretty good shape, with stb we've got pretty much all we need to write fully featured GUI applications now.
The one thing lacking is the ability to display a message box or alert dialog (like LWJGL2's Sys.alert()).
A reason you would need this is for systems where there is no OpenGL and therefore you can't create a GLFW window or display anything, in these cases it'd be useful to be able to show a simple alert message about no opengl being available or that the drivers need to be updated.
A really cool library seems to be tiny file dialogs (http://sourceforge.net/projects/tinyfiledialogs/) which is designed to complement GLFW. Its really small (single C file, just a few kb's), crossplatform, 6 function calls (in fact we only need one of the calls and could remove the others, although they would be cool to keep too).
QuoteA single C file (add it to your C or C++ project) with 6 modal function calls
- message box & question box
- input box & password box
- save file dialog
- open file dialog & multiple files
- select folder dialog
- color picker.
Would make a useful addition to LWJGL3?
It would be useful, yes, I'll have a look. Do you know if it supports unicode?
Quote from: spasi on May 27, 2015, 22:07:41
It would be useful, yes, I'll have a look. Do you know if it supports unicode?
hmm, doesn't look like unicode is supported. Anyway having looked further into it, I think I might be able to implement a similar thing for Linux and Mac in pure java without JNI. Will have a go at it tonight.
Had an initial go at the above and got a basic dialog box working for Mac and Windows using just standard OS features and without any JNI. Will look at Linux implementation tonight as its a little more tricky due to there being no single dialog utility or method.
Implementation looks like this so far:
import java.io.File;
import java.io.IOException;
import java.io.PrintWriter;
public class MessageBox {
private static void winAlert(String title, String message) {
// create random file name for script
String filename = "dialog" + (int)(Math.random() * 100000);
File file = null;
try {
// store script in temporary location
file = File.createTempFile(filename, ".vbs");
PrintWriter writer = new PrintWriter(file, "UTF-8");
writer.println("msgbox \"" + message
+ "\"" + ",vbOKOnly + vbSystemModal, "
+ "\"" + title + "\"");
writer.close();
// run script
try {
Runtime runtime = Runtime.getRuntime();
Process process = runtime.exec("wscript " + file.getAbsolutePath());
process.waitFor();
}
catch (InterruptedException e) {
e.printStackTrace();
}
} catch (IOException e) {
e.printStackTrace();
}
finally {
file.delete(); // clean up script
}
}
private static void macAlert(String title, String message) {
Runtime runtime = Runtime.getRuntime();
String[] args1 = { "osascript",
"-e",
"tell app \"System Events\" to display dialog "
+ "\"" + message + "\""
+ "with title \"" + title + "\""
+ "buttons {\"OK\"}"
+ "default button \"OK\""
};
try {
Process process = runtime.exec(args1);
process.waitFor();
} catch (IOException e) {
e.printStackTrace();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
private static void linuxAlert(String title, String message) {
// TODO
}
public static void alert(String title, String message) {
String osName = System.getProperty("os.name");
if (osName.startsWith("Win")) {
winAlert(title, message);
} else if (osName.startsWith("Mac") || osName.startsWith("Darwin")) {
macAlert(title, message);
}
else if (osName.startsWith("Linux") || osName.startsWith("Unix")) {
linuxAlert(title, message);
}
}
public static void main(String[] args) {
alert("Dialog", "HELLO WORLD!");
System.out.println("DONE");
}
}
Perhaps you should throw some kind of RuntimeException in case the dialog could not be displayed. A user might want to do some own error handling.
Finished the linux implementation too, implemented dialogs using Zenity (Gnome/GTK), Kdialog (KDE), notify-send and finally a console output. That should pretty much cover the majority of linux distro's.
Therefore the code now allows showing a message dialog across platforms, supports unicode, is a single java class (5kb compiled) without any JNI use :)
A simple dialog should be enough but if there is a need, shouldn't be too much of a stretch to also add support for native open/load/save file dialogs, question dialogs, input/password dialogs, etc in a similar fashion.
Final code:
import java.io.File;
import java.io.IOException;
import java.io.PrintWriter;
public class MessageBox {
private static void winAlert(String title, String message) {
// create random file name for script
String filename = "dialog" + (int)(Math.random() * 100000);
File file = null;
try {
// store script in temporary location
file = File.createTempFile(filename, ".vbs");
PrintWriter writer = new PrintWriter(file, "UTF-8");
writer.println("msgbox \"" + message
+ "\"" + ",vbOKOnly + vbSystemModal, "
+ "\"" + title + "\"");
writer.close();
// run script
try {
Runtime runtime = Runtime.getRuntime();
Process process = runtime.exec("wscript " + file.getAbsolutePath());
process.waitFor();
return;
}
catch (InterruptedException e) {
e.printStackTrace();
}
} catch (IOException e) {
e.printStackTrace();
}
finally {
file.delete(); // clean up script
}
consoleOutput(message, title);
}
private static void macAlert(String title, String message) {
Runtime runtime = Runtime.getRuntime();
String[] args = { "osascript",
"-e",
"tell app \"System Events\" to display dialog "
+ "\"" + message + "\""
+ "with title \"" + title + "\""
+ "buttons {\"OK\"}"
+ "default button \"OK\""
};
try {
Process process = runtime.exec(args);
process.waitFor();
return;
} catch (IOException e) {
e.printStackTrace();
} catch (InterruptedException e) {
e.printStackTrace();
}
consoleOutput(message, title);
}
private static void linuxAlert(String title, String message) {
try {
if (runKdialog(message, title)) return;
if (runZenity(message, title)) return;
if (runNotifySend(message, title)) return;
} catch (InterruptedException e) {
e.printStackTrace();
}
// if all fails output to console
consoleOutput(message, title);
}
private static boolean runZenity(String message, String title) throws InterruptedException {
String[] args = {"zenity", "--info", "--text", message, "--title", title};
try {
Process process = Runtime.getRuntime().exec(args);
process.waitFor();
} catch (IOException e) {
return false;
}
return true;
}
private static boolean runKdialog(String message, String title) throws InterruptedException {
String[] args = {"kdialog", "--msgbox", message, "--title", title };
try {
Process process = Runtime.getRuntime().exec(args);
process.waitFor();
} catch (IOException e) {
return false;
}
return true;
}
private static boolean runNotifySend(String message, String title) throws InterruptedException {
String[] args = {"notify-send", title, message};
try {
Process process = Runtime.getRuntime().exec(args);
process.waitFor();
} catch (IOException e) {
return false;
}
return true;
}
private static void consoleOutput(String message, String title) {
System.out.println("Title: " + title);
System.out.println("Message: " + message);
}
public static void alert(String title, String message) {
String osName = System.getProperty("os.name");
if (osName.startsWith("Win")) {
winAlert(title, message);
} else if (osName.startsWith("Mac") || osName.startsWith("Darwin")) {
macAlert(title, message);
}
else if (osName.startsWith("Linux") || osName.startsWith("Unix")) {
linuxAlert(title, message);
}
}
public static void main(String[] args) {
alert("MsgBox", "HELLO WORLD!");
System.out.println("DONE");
}
}
I am *very* excited about the upcoming Mantle support!
I'd love to get started with it asap. Any idea when an early release might be available?
Quote from: spasi on April 26, 2015, 18:12:23
Quote from: kappa on April 26, 2015, 17:59:00Are the Projects Valhalla (http://openjdk.java.net/projects/valhalla/) or Panama (http://openjdk.java.net/projects/panama/) going to be of any help to LWJGL's structs implementation? If so, might be worth waiting for them as an official solution.
Valhalla, no. Anything they do will be heap-based for sure. Super-interesting and useful if you're doing server programming, but does nothing for native interop. Panama is more promising, but we're talking Java 10 (at best). LWJGL 4 will be out when that's mainstream enough.
Quote from: kappa on April 26, 2015, 17:59:00Just curious, is the Mantle library even relevant anymore or worth implementing? given that its specific to AMD hardware and most are now throwing their weight behind Vulkan (including AMD) and will likely do what Mantle does but better.
Yes, for a few reasons:
- It won't affect the official LWJGL build. The Mantle bindings will be an optional module and you'll have to manually build LWJGL to use it. It's currently Windows-only anyway.
- Mantle is not dead. AMD will use it as a faster way to get exciting new features to customers. Like NV's CUDA. If you only care about Mantle 1.0 features, then obviously Vulkan will be better (and that's AMD's suggestion too).
- I think many people are excited about Vulkan and Mantle is a very nice way to get a glimpse of what's coming. The two APIs are very similar and you can start preparing for Vulkan right now.
LWJGL 3 now has full EGL and OpenGL ES bindings. All core versions and extensions are supported. Like in LWJGL 2, the plan for now is to not include them in the official builds. There are two reasons for this:
- GLFW currently can only work with EGL/GLES if it is statically compiled for it and you cannot compile GLFW with both EGL/GLES and desktop OpenGL support. LWJGL also statically links with GLFW, which complicates things further. This is going to change in GLFW 3.2 and you'll be able to select the API at runtime. GLFW itself will dynamically load the necessary libraries, just like LWJGL does. Not sure when this is going to be implemented, you can follow this issue (https://github.com/glfw/glfw/issues/145) if interested.
- It would make the binaries quite big. I have a plan that, when implemented, will reduce the binary sizes considerably. I cannot estimate the reduction in advance, but if it's big enough, I may consider having a single build with both EGL/GLES and desktop OpenGL bindings.
With that said, I have locally tested EGL/GLES with a custom build and it works great. If someone cannot wait for GLFW 3.2 and must use GLES now, let me know and I'll provide instructions on how to build GLFW/LWJGL.
API breaking change: The latest build (3.0.0b #11) has implemented the hybrid solution mentioned at the end of this post (http://forum.lwjgl.org/index.php?topic=4800.msg29616#msg29616). Specifically, the LWJGL generator now supports mixing AutoType and MultiType modifiers in the same function. To explain this, I'll first give an example, using GL20.glVertexAttribPointer. The generator template looks like this (Kotlin code, with irrelevant stuff removed):
void(
"VertexAttribPointer",
GLuint.IN("index"),
GLint.IN("size"),
AutoType("pointer", GL_FLOAT) _ GLenum.IN("type"),
GLboolean.IN("normalized"),
GLsizei.IN("stride"),
ARRAY_BUFFER _ MultiType(DATA_SHORT, DATA_INT) _ const _ void_p.IN("pointer")
)
Note the AutoType on the "type" argument and the MultiType on the "pointer" argument. This generates the following Java code:
// This is the standard method, matching the native signature
void glVertexAttribPointer(int index, int size, int type, boolean normalized, int stride, ByteBuffer pointer)
// This is generated because of the ARRAY_BUFFER modifier on "pointer"
void glVertexAttribPointer(int index, int size, int type, boolean normalized, int stride, long pointerOffset)
// This is generated by the AutoType on "type". GL_FLOAT is passed automatically to the "type" argument of the native function.
void glVertexAttribPointer(int index, int size, boolean normalized, int stride, FloatBuffer pointer)
// The following two are generated by the MultiType on "pointer".
void glVertexAttribPointer(int index, int size, int type, boolean normalized, int stride, ShortBuffer pointer)
void glVertexAttribPointer(int index, int size, int type, boolean normalized, int stride, IntBuffer pointer)
Before this change, the Short/Int versions were also AutoTyped, but an extra virtual "unsigned" argument was generated. This is now gone and you must specify the type explicitly. So for example you can use the ShortBuffer overload with a GL_HALF_FLOAT type, or the IntBuffer one with GL_INT_2_10_10_10_REV. Previously, you were limited to GL_SHORT/GL_UNSIGNED_SHORT and GL_INT/GL_UNSIGNED_INT respectively.
The GL_FLOAT AutoType remains, because there's no other data type you can use with floating point data. The same applies to other functions with very specific types, for example GL11.glDrawElements, only AutoType is used there.
Let me know if you have any feedback on the above changes. With the addition of EGL/GLES bindings, we're now very close to the 3.0.0 beta release and an API freeze.
Hmm I foresee potential (unusual perhaps) situations of having a FloatBuffer I want to pass in which contains data which is not actually floats at all underneath but just a view on some mixed data with appropriate strides... Mostly it's the slight discrepancy in the APIs which is a little painful on the eye though. Just my 2p.
Cas :)
Indeed, the discrepancy is ugly. Two options:
a) Use the unsafe version, i.e.
FloatBuffer data = ...
nglVertexAttribPointer(index, size, type, normalized, stride, memAddress(data));
b) We stop mixing AutoType/MultiType in the same function. In this case, the FloatBuffer version will get an explicit type argument.
If we got with b, do you think we should also drop AutoType support completely? I mean even for functions that are exclusively AutoTyped, like glDrawElements.
How about a version that simply takes a Buffer rather than memAddress(buffer)? So at least you're not accidentally passing in some random long that compiles.
As for autotype... perhaps explicity generating methods with an 'a' suffix could provide autotyped versions of the "unsafe" methods:
FloatBuffer data = ...
glVertexAttribPointera(index, size, normalized, stride, data);
IntBuffer moreData = ...
glVertexAttribPointera(index, size, GL_UNSIGNED_INT, stride, data);
which would give us the choice of just going low-level without checks or higher-level and let LWJGL do a bit more type and parameter checking. At the cost of bloating the API a tiny bit.
Cas :)
Quote from: princec on August 10, 2015, 09:46:51How about a version that simply takes a Buffer rather than memAddress(buffer)? So at least you're not accidentally passing in some random long that compiles.
The problem with Buffer is that you cannot scale the current .position() by the element size (without instanceof checks). The memAddress method is overloaded to handle this.
Quote from: princec on August 10, 2015, 09:46:51As for autotype... perhaps explicity generating methods with an 'a' suffix could provide autotyped versions of the "unsafe" methods:
FloatBuffer data = ...
glVertexAttribPointera(index, size, normalized, stride, data);
IntBuffer moreData = ...
glVertexAttribPointera(index, size, GL_UNSIGNED_INT, stride, data);
which would give us the choice of just going low-level without checks or higher-level and let LWJGL do a bit more type and parameter checking. At the cost of bloating the API a tiny bit.
I'm not sure how this is different from what we have now. You don't want to mix low-level and high-level versions when auto-completing?
My thinking was along the lines of:
If you have to wrap every call that takes a Buffer with a memAddress(buffer) then you may as well make Buffer the signature and unwrap its address inside LWJGL instead.
As for autocomplete - well, yes, I would like to see them both if they were available, and then I'd choose :) And if I got really sick of some of them I'd just get autocomplete to filter out the ones I don't like. The explicit addition of a new method suffix eg. 'a' would at least help to differentiate the calls.
CAs :)
Used IntelliJ auto-complete to do a few mockups, see the attachments. 1st is the current LWJGL state, 2nd is without AutoType, 3rd is princec's suggestion, 4th is princec's without AutoType.
In terms of aesthetics, I like the 2nd and 4th. But I absolutely hate the 'a' postfix and I can't think of anything nice to use there. Personally, it doesn't bother me that the high-level overloads are mixed with the lower-level ones in #2.
In terms of usability, the use-case with the mixed data in the same buffer that you suggested, can be handled in two ways:
- Use a ByteBuffer for everything.
- Use a ByteBuffer for the raw data and the OpenGL call, but use a FloatBuffer view on top of it to fill fp data at the appropriate offsets.
In any case, I don't think the Buffer version is a good tradeoff. If we're willing to pay the price of runtime type discovery*, we might as well remove the other overloads (see the attachment).
* Depending on how we write this, the JVM may able to statically identify the type used at a given call site. But I'm afraid the increased bytecode size will affect inlining at a higher level. Will have to do some testing.
The latest build (3.0.0b #14) features the new OpenGL extensions announced today at Siggraph. Nvidia has released a driver (https://developer.nvidia.com/opengl-driver) that supports all the new extensions.
#14 also features OpenGL ES 3.2 support.
Thinking that on reflection, no pun intended, that #2 might just be the most intuitive, and let the user sort out passing the correct gl_type in whether they're passing in FloatBuffers or IntBuffers or whatever. Which could allow some amusing "casting".
Cas :)
Build 3.0.0b #16 deduplicates JNI methods that are binary compatible. This was possible because LWJGL 3 did nothing in JNI calls, other than casts and the actually native function call. The JNI methods in bindings are now gone and there's a new org.lwjgl.system.JNI (https://github.com/LWJGL/lwjgl3-generated/blob/master/java/org/lwjgl/system/JNI.java) class that includes the distinct set of JNI methods, shared across all bindings. The JNI class is auto-generated, based on the active bindings (https://github.com/LWJGL/lwjgl3/blob/master/config/build-bindings.xml) at build time.
This change had a significant impact on the native binary sizes:
liblwjgl.dylib: 474KB, down from 659KB
liblwjgl.so: 249KB, down from 465KB
liblwjgl32.so: 239KB, down from 439KB
liblwjgl.dll: 271KB, down from 416KB
liblwjgl32.dll: 241KB, down from 395KB
(the Linux and Windows binaries are upx (http://upx.sourceforge.net/) compressed)
Wow, that is really awesome! Like! :)
Makes high anticipation for a modular custom build that really only contains the necessary things and keeps the generated artifacts lean and mean.
EDIT: Hmm... for me, the 64-bit lwjgl.dll shrunk a bit more to just 247,808 bytes with default "ant" build, recent glfw head and upx -9.
Quote from: princec on August 12, 2015, 08:30:37Thinking that on reflection, no pun intended, that #2 might just be the most intuitive, and let the user sort out passing the correct gl_type in whether they're passing in FloatBuffers or IntBuffers or whatever. Which could allow some amusing "casting".
API breaking change: Build 3.0.0b #17 implements #2, all FLOAT "autotyped" methods have been replaced with methods that require an explicit type argument.
Quote from: Kai on August 17, 2015, 23:53:20EDIT: Hmm... for me, the 64-bit lwjgl.dll shrunk a bit more to just 247,808 bytes with default "ant" build, recent glfw head and upx -9.
Most likely because you're building with VS2013. The CRT (which is statically built into LWJGL) has changed significantly in VS2015.
Quote from: spasi on August 17, 2015, 23:27:27
..
This change had a significant impact on the native binary sizes:
liblwjgl.dylib: 474KB, down from 659KB
liblwjgl.so: 249KB, down from 465KB
liblwjgl32.so: 239KB, down from 439KB
liblwjgl.dll: 271KB, down from 416KB
liblwjgl32.dll: 241KB, down from 395KB
...
oh nice, this is a super awesome change, much more features than LWJGL2, faster and now smaller too.
It seems that all the previous mentions of adding Mantle support have been removed... :(
Does this mean that the Mantle support will not be moving forward?
I still think it would be very nice to have (optional) Mantle support in LWJGL. Please consider reviving the plan!
Quote from: Hooji on June 17, 2015, 22:40:54
I am *very* excited about the upcoming Mantle support!
I'd love to get started with it asap. Any idea when an early release might be available?
Quote from: spasi on April 26, 2015, 18:12:23
Quote from: kappa on April 26, 2015, 17:59:00Are the Projects Valhalla (http://openjdk.java.net/projects/valhalla/) or Panama (http://openjdk.java.net/projects/panama/) going to be of any help to LWJGL's structs implementation? If so, might be worth waiting for them as an official solution.
Valhalla, no. Anything they do will be heap-based for sure. Super-interesting and useful if you're doing server programming, but does nothing for native interop. Panama is more promising, but we're talking Java 10 (at best). LWJGL 4 will be out when that's mainstream enough.
Quote from: kappa on April 26, 2015, 17:59:00Just curious, is the Mantle library even relevant anymore or worth implementing? given that its specific to AMD hardware and most are now throwing their weight behind Vulkan (including AMD) and will likely do what Mantle does but better.
Yes, for a few reasons:
- It won't affect the official LWJGL build. The Mantle bindings will be an optional module and you'll have to manually build LWJGL to use it. It's currently Windows-only anyway.
- Mantle is not dead. AMD will use it as a faster way to get exciting new features to customers. Like NV's CUDA. If you only care about Mantle 1.0 features, then obviously Vulkan will be better (and that's AMD's suggestion too).
- I think many people are excited about Vulkan and Mantle is a very nice way to get a glimpse of what's coming. The two APIs are very similar and you can start preparing for Vulkan right now.
I had much less time this summer to work on LWJGL than I was expecting. I had to revise my plans and focus on fixing issues, finalizing the public APIs and releasing the beta. After that's done, I'll work on bindings again. Though we're getting very close to the Vulkan release now and I'm not sure it's useful having Mantle bindings anymore.
LWJGL has always supported a few system properties (e.g. -Dorg.lwjgl.util.Debug=true) that could be used to configure its behavior. In LWJGL 3 there are several more and it was starting to get out of hand. Passing several JVM launch arguments isn't the most convenient way to configure a library.
There is now support for programmatic runtime configuration with the org.lwjgl.system.Configuration (https://github.com/LWJGL/lwjgl3/blob/master/modules/core/src/main/java/org/lwjgl/system/Configuration.java) class. This works in addition to the system properties, they can still be used. The new class is an enum of all the available options and they should be adequately documented. Let me know if something needs clarification. Example usage:
public static void main(String[] args) {
Configuration.LIBRARY_PATH.set("libs"); // equivalent to -Dorg.lwjgl.librarypath=libs
Configuration.DEBUG.set(true); // equivalent to -Dorg.lwjgl.util.Debug=true
// start using LWJGL
}
It's available in nightly build 3.0.0b #37.
Almost 3.5 years after the original post in this thread, the current LWJGL 3.0 nightly build is the first release candidate.
Now is the time to try it out and raise any issues you might have with the API. See this post (http://forum.lwjgl.org/index.php?topic=6157.0) for changes since 3.0.0b.