Java-Gaming.org Hi !
Featured games (84)
games approved by the League of Dukes
Games in Showcase (550)
Games in Android Showcase (139)
games submitted by our members
Games in WIP (593)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1] 2 3 ... 27
1  Java Game APIs & Engines / Engines, Libraries and Tools / Re: GLFW 3.1 is out on: 2015-01-20 15:25:14
I expected that it would bring the icon changing feature, but it didn't.. Hoping that in a future release.

Setting window icons is scheduled for GLFW 3.2.

I'm currently quite busy and lost precious time with the 2.9.3 release, but I'll try to have 3.0a ready this weekend.

I know LWJGL include an hybrid version but i hope it will include this one soon !! I found GLFW a great library.

The LWJGL nightly builds contain all GLFW 3.1 features. Only some of the latest fixes are missing.
2  Java Game APIs & Engines / OpenGL Development / LWJGL 2.9.3 on: 2015-01-19 00:49:17
LWJGL 2.9.3 has just been released, with a few bug fixes that didn't make it to LWJGL 2.9.2. Details here.

It includes an important fix for cursor movement behavior on Windows, when the mouse is grabbed. Whenever a keyboard key was held down (and repeat events fired), the cursor would stutter/drift horribly. This behavior was mostly noticeable with high repeat rates, with vsync enabled and/or with low frame rates. It also significantly affected Minecraft users (very noticeable in a 1st person view). With 2.9.3 cursor movement is now perfectly smooth.
3  Java Game APIs & Engines / OpenGL Development / Re: [SOLVED]Lwjgl Error: Failed to load the native library: lwjgl on: 2015-01-09 15:53:53
I'm pretty sure that if it determined the arch. from the JVM, and someone used a x86 JVM on x64 system, it shouldn't work, because it uses wrong natives on the machine.

A x86 JVM on a x64 machine requires x86 binaries.
4  Java Game APIs & Engines / OpenGL Development / Re: [SOLVED]Lwjgl Error: Failed to load the native library: lwjgl on: 2015-01-09 09:42:30
Which architecture can be resolved automatically? Do you talk only about the "bitness"?

Whether to use x86 or x64 binaries.
5  Java Game APIs & Engines / OpenGL Development / Re: [SOLVED]Lwjgl Error: Failed to load the native library: lwjgl on: 2015-01-09 08:20:07
Also, as of LWJGL 3, you need to specify a folder by 32bit vs 64bit.

That was a temporary limitation, you now only have to specify the base folder. The OS and CPU architecture are resolved automatically.
6  Game Development / Newbie & Debugging Questions / Re: Is LWJGL 3 stable enough for use? on: 2015-01-06 21:26:23
Incidentally, has there been any movement on that front since your lwjgl/jfx integration demo? Or are you going to wait and see what happens with the interop feature request?

I think that request will be very low priority for the JavaFX team. Also, it's only about embedding OpenGL into JavaFX; though technically possible, it will be limited to non-gaming applications imho. The other way around, rendering JavaFX content inside a native window, is much more interesting (to me at least) and should be easier to implement.

I haven't had any more time to work on the LWJGL integration demo. But I'm hoping that there's somehow a way to get inside the JavaFX runtime, such that GPU-to-GPU copies are made possible. It will probably end up being very hacky and platform-specific, but if we could build a decent demo, the JavaFX engineers might get interested.
7  Game Development / Newbie & Debugging Questions / Re: Is LWJGL 3 stable enough for use? on: 2015-01-06 13:38:14
i did not catch the full info on the LWJGLX features but afaik swing is not planned, right ?

Correct, it is not planned for 3.0. If there's enough free time after 3.0, I'm still interested in exploring interop solutions, especially for JavaFX. Obviously, I'll be glad to help if you need assistance.

Note that LWJGL 3 exposes all platform-specific context management functions and you can even call anything missing using libFFI. There will also soon be bindings to the Objective C Runtime (for interacting with Cocoa).
8  Game Development / Newbie & Debugging Questions / Re: Is LWJGL 3 stable enough for use? on: 2015-01-06 12:47:40
You can think of LWJGL 2 as two parts; the bindings to native libraries and the cross-platform window/context/input/controller API.

The bindings in LWJGL 2 are a very thin layer on top of the native libraries they expose. The bindings in LWJGL 3 are just as thin (thinner actually) and are very compatible with LWJGL 2. They are not 100% compatible because of some bug fixes here and there and the OpenCL bindings redesign. They are much nicer though; you get unsafe bindings (direct access to the JNI functions), more convenient overloads and, best of all, inline documentation.

The rest of LWJGL 2 is (relatively) a lot of code, written in both Java and C/ObjC. It is what it is, does the job for which is was designed well, but has the known problems and limitations. LWJGL 3 on the other hand, does not have anything like that. There are some classes, like the GLContext and the ContextCapabilities, but that's it. There is nothing there to be stable or not. Everything related to windows, monitors, contexts, keyboard, mouse and controllers is being done with GLFW. Which is yet another library binding in LWJGL 3. So, the real question is if GLFW is mature enough. Well, it's a library almost as old as the original LWJGL, but has been rewritten in version 3.0, just like LWJGL. We're currently close to the 3.1 release and I'll quote its developer:

Quote
GLFW 3.1 has closed more issues than every previous release combined since GLFW moved to its current home on GitHub. Two issues remaining.

Other than, I'll just say you're going to have to try it and judge for yourselves. Disclaimer: GLFW does everything (much) better than LWJGL 2. There is only one feature missing and that's setting window icons programmatically. It will be added in GLFW 3.2.

With that said, I'll repeat here that LWJGL 3.0 has not been released yet. There's not even an official "alpha" build available. There are many users trying the nightly builds though and many platform/environment-specific issues have been resolved. I'm pretty confident that the first official release (scheduled for when GLFW 3.1 is out) will be stable enough for everyone to enjoy. Of course, it would be irresponsible to say right now that you should start porting your applications to LWJGL 3. The bindings are incomplete (e.g. many OpenGL extensions and OpenGL ES are missing, OpenAL needs work) and we'd like to be open to feedback for the rest of the API right until the final 3.0 release (the API will freeze then). The non-binding API is so small though, that any breaking changes will have minimal impact to early-adopters.

My unofficial/personal/humble opinion is: If you don't need AWT/applet interop, there is no reason whatsoever to stick with LWJGL 2. Smiley
9  Discussions / General Discussions / Re: System requirements for Oculus Rift? on: 2015-01-05 12:12:11
I'd like to add that LWJGL 3 will soon have libOVR bindings (currently WiP). Also, here's an unfinished guide on how to use GLFW with libOVR to detect an Oculus Rift.
10  Game Development / Newbie & Debugging Questions / Re: GLFW input handling not smooth on: 2014-12-31 23:25:55
Try changing:

1  
mouseDown = (action == GLFW.GLFW_PRESS);

to

1  
mouseDown = (action != GLFW.GLFW_RELEASE); // either PRESS or REPEAT
11  Game Development / Newbie & Debugging Questions / Re: GLFW input handling not smooth on: 2014-12-31 22:14:35
1) In the GLFWMouseButtonCallback, you don't have to use glfwGetMouseButton(). The action parameter tells you the button state.

2) The action parameter has 3 possible values: GLFW_PRESS, GLFW_RELEASE and GLFW_REPEAT. If you're only interested in RELEASE events, check for that explicitly. This is probably what's causing your issue.

3) Not sure why you're doing that, but you should not have to check the button state and handle click events in the GLFWCursorPosCallback. Only doing it in GLFWMouseButtonCallback should work fine.
12  Java Game APIs & Engines / Engines, Libraries and Tools / Re: [GLFW] keyboard layout on: 2014-12-29 23:32:57
I think what you're looking for is glfwGeyKeyName, which has not been added to 3.1 yet, see issue #117.
13  Java Game APIs & Engines / Engines, Libraries and Tools / Re: [GLFW] keyboard layout on: 2014-12-29 22:44:29
LWJGL 3 uses a custom GLFW build with all features/fixes added in 3.1. Which means it includes the fix for #114.

With that said, you should never have to map keys between keyboard layouts. There are two separate ways to handle keyboard input:

a) Physical keys. For example, you want the default keys for moving around to be WASD (as they appear on a QWERTY keyboard, which is how GLFW understands it). You use GLFW_KEY_W/A/S/D. Now, lets say a user with an AZERTY keyboards tries your application. When they press ZQSD, you'll still get GLFW_KEY_W/A/S/D in the key callback. The mapping is automatic, you don't have to do anything. The only thing to worry about is writing your app so that it works with the physical layout of a US keyboard.

b) Text input. You have to use GLFWCharCallback or GLFWCharModsCallback. These are keyboard layout and locale dependent, and again, you don't have to worry about specific layouts or mappings.
14  Java Game APIs & Engines / OpenGL Development / LWJGL 2.9.2 on: 2014-12-28 20:27:57
LWJGL 2.9.2 has been released today. It adds support for OpenGL 4.5 but it's mostly a bug fix release. Details here.

This will most likely be the last LWJGL 2 release. Pull requests that are well-written and properly tested will still be accepted and nightly builds will stay alive for the time being. If anyone is interested in taking over maintenance of the project, send me a PM (here or in the LWJGL forum).

Many thanks to everyone that has contributed to the project over the years!
15  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3 GLFW_CURSOR_NORMAL hiding the mouse? on: 2014-12-13 10:33:39
I'm not sure if I'm seeing things or not... but in fullscreen, the Gamma ramp seems to be messed up... I guess I could just set the gamma ramp at fullscreen but:
 - why is it messed up?
 - is there anyway to just simply fix it up instead of guessing the correct gamma ramp?

EDIT: just more info... it seems to start alright, but it changes to a brighter gamma ramp.... Im not even sure if it is gamma but from my knowledge it does seem like it...

I'm not seeing anything like that with GLFW, it does not change the gamma ramp unless you explicitly call glfwSetGammaRamp. This may be a driver issue or a bug in your code.
16  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3 GLFW_CURSOR_NORMAL hiding the mouse? on: 2014-12-12 18:54:20
I was able to reproduce this. The fix is to restore GLFW_CURSOR to GLFW_CURSOR_NORMAL on the old window, before destroying it.
17  Java Game APIs & Engines / OpenGL Development / Re: LWJGL 3; how's it getting along? on: 2014-12-08 16:36:38
The LWJGL 3 wiki now has a tutorial section and the first tutorial is up: Ray tracing with OpenGL Compute Shaders (Part I), authored by Kai Burjack.
18  Java Game APIs & Engines / OpenGL Development / Re: LWJGL 3; how's it getting along? on: 2014-12-08 09:39:57
Would I benefit at all from moving to the new LWJGL?

Yes, LWJGL 3 does not force the use of new OpenGL features and works equally well on old hardware. The primary benefit would be moving from the old Display to GLFW.

Just a note about one line of code that is wrong in the Guide

Thanks, fixed.
19  Java Game APIs & Engines / OpenGL Development / Re: LWJGL 3; how's it getting along? on: 2014-12-07 17:55:37
Replace www with legacy, i.e. http://legacy.lwjgl.org/javadoc/index.html?org/lwjgl/input/Mouse.html
20  Game Development / Newbie & Debugging Questions / Re: LWJGL3 no GLFW package? on: 2014-12-07 12:23:22
You'll be able to use OpenGL ES on the desktop and on devices that can run a JVM (so iOS is excluded). Like with LWJGL 2, there won't be any binaries provided for ARM architectures, but we want to make it easy for users to build LWJGL 3 for their target environment, including ARM.
21  Game Development / Newbie & Debugging Questions / Re: LWJGL3 no GLFW package? on: 2014-12-07 12:07:15
The alpha will be released when GLFW 3.1 is ready (should be soon), the beta when OpenGL ES and missing OpenGL/CL extensions are added. The final 3.0 release should not be late after that.
22  Game Development / Newbie & Debugging Questions / Re: LWJGL3 no GLFW package? on: 2014-12-07 11:36:16
Generally, in software development, working with multiples of anything does not make things easier.

The point of LWJGL 3 is that it's up to you, assuming you follow the rules of the binding used (GLFW in this case). One window or multiple windows, one thread or many threads, it's your choice. If you think GLFW's design is not satisfying, feel free to suggest a better alternative or roll you own (LWJGL exposes OS-specific APIs, e.g. Xlib on Linux).
23  Game Development / Newbie & Debugging Questions / Re: LWJGL3 no GLFW package? on: 2014-12-06 09:52:46
Short answer:

1) Yes, it is possible to do multi-threaded rendering with multiple windows, as long as events are handled in the main thread. Here is a sample of doing exactly that with LWJGL 3, from the LWJGL tests module.

2) LWJGL 3 exposes everything in GLFW, including the native APIs.

3) The javadoc problem was probably related to the recent change of the GLFW package. It was moved from org.lwjgl.system.glfw to org.lwjgl.glfw. The javadoc and latest build should be in sync now.

Long answer:

As aldacron said, the main thread limitation exists because of GLFW's design, not LWJGL's. This is not an arbitrary design decision. The primary restriction is the design of OS X: you have no choice there but to do everything in the main thread. If for some reason you need more than one main event loop, the only workaround is to launch multiple processes that communicate via an IPC mechanism. Other OSes are more relaxed, but there are still some restrictions, e.g. on Windows the event loop must run on the same thread that created the window. These issues are all solved neatly by doing what GLFW does, run all window management and event handling functionality in the main thread.

This is not a unique design either, most other (cross-platform) GUI toolkits/frameworks work the same way. For example, we have the event dispatch thread (EDT) with AWT/Swing, which on OS X is forced to be the first thread in the process. This is also why AWT and GLFW are fundamentally incompatible on OS X; they both require that first thread to be the thread in which they run their respective event loops.
24  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - Frequent crashes on: 2014-12-03 17:46:31
I have found the bug btw, will push another build later tonight.
25  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - Frequent crashes on: 2014-12-03 17:45:46
For this particular example, either when you call glfwDestroyWindow or when you call glfwSetWindowPosCallback with another GLFWwindowposfun or NULL.
26  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - Frequent crashes on: 2014-12-03 17:29:13
Please read this post, especially the c) paragraph. You should have strong references to the callback instances and only release them when they are not going to be called anymore.

If you aren't doing that, you should be getting a ClosureError thrown, instead of a crash. I'm currently investigating why this isn't happening on certain configurations.
If you are indeed doing that, then I would like to see some code the reproduces the problem, if you don't mind.
27  Discussions / Miscellaneous Topics / Re: C#, did Microsoft just want to be different? on: 2014-11-27 13:27:19
I would rather just be able to specify something of the form (String, String) => int as the signature.

This is the approach taken by Kotlin, if you'd like to try that in a JVM language.

According to this presentation by Brian Goetz, they started exploring lambdas with functional types and later redesigned it to the current functional interface convention. The reasons are solid and the solution surprisingly suitable for the Java ecosystem. Oracle did a fantastic job with Java 8 imho and I'm nothing short of excited for what's coming next (projects Valhalla & Panama).

The slow but steady progress of Java the language is a good thing. There are also tons of options, so many different JVM languages, if we're just talking about language features. Most have perfect interop, you can just use whatever you need to use to be productive and can always fallback to Java when you have to. Exploring different languages and programming approaches is also a good thing.
28  Java Game APIs & Engines / OpenGL Development / Re: LWJGL 3; how's it getting along? on: 2014-11-25 12:05:10
Are you doing anything with AWT/Swing? Also, what JVM and OS X versions are you running it on?
29  Java Game APIs & Engines / OpenGL Development / Re: LWJGL 3; how's it getting along? on: 2014-11-25 11:58:52
It only occurs occasionally, not always, and I'm not sure of the reason. That is the first function I call in my engine, even before the game loop starts.

Does launching the JVM with
-XstartOnFirstThread
fix the crash?
30  Java Game APIs & Engines / OpenGL Development / Re: LWJGL 3; how's it getting along? on: 2014-11-24 23:03:58
If you need AWT/Swing interop, my advice would be to stick with LWJGL 2.

Technically, you could implement LWJGL 2's interop behavior using LWJGL 3's bindings to OS APIs, but that's such a low priority for 3 that it'll probably have to be a contribution from someone else.
Pages: [1] 2 3 ... 27
 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Archive (29 views)
2015-01-29 04:26:08

theagentd (24 views)
2015-01-28 15:33:52

GamerIDGoesHere (36 views)
2015-01-27 01:23:23

GamerIDGoesHere (37 views)
2015-01-27 01:22:15

CopyableCougar4 (46 views)
2015-01-27 00:34:41

CopyableCougar4 (30 views)
2015-01-26 04:47:56

Olo (23 views)
2015-01-25 21:26:00

Olo (28 views)
2015-01-25 18:44:22

Robo11 (46 views)
2015-01-25 06:14:26

basil_ (38 views)
2015-01-17 22:29:32
2D Dynamic Lighting
by ThePixelPony
2015-01-01 20:25:42

How do I start Java Game Development?
by gouessej
2014-12-27 19:41:21

Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!