Java-Gaming.org Hi !
Featured games (84)
games approved by the League of Dukes
Games in Showcase (558)
Games in Android Showcase (150)
games submitted by our members
Games in WIP (602)
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  Discussions / General Discussions / Re: The Khronos Group announces "Vulkan": the successor to OpenGL on: 2015-03-05 12:31:04
Repo doesn't appear to up yet so I haven't had the chance to see if there are any strings attached.

You need to register to gain access.
2  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Java OpenGL Math Library (JOML) on: 2015-02-20 11:17:26
Relevant post on angles.
3  Discussions / General Discussions / Re: What's your day job? on: 2015-02-16 14:56:12
I'm a co-owner at WebHotelier, we launched in 2008 and I've been working there ever since. Well, from home actually, the company HQ is 800km from where I live. It's nothing exciting technology-wise, even though it's a JVM based platform, I have most fun doing SQL magic (yes, there is such a thing). For the past year or so I've also been doing extensive research on a "next-gen" re-architecture of the whole thing, which should be keep things interesting. We'll need it too, since we're currently expanding internationally.

In my free time, I work on LWJGL and (try to) raise a little girl.
4  Game Development / Newbie & Debugging Questions / Re: Byte buffer crashing on: 2015-02-11 16:24:48
The latest nightly build (#39) now returns null instead of a ByteBuffer pointing at 0L.

oh, that's new in 3.x ?

correct me but with 2.9.x ngl methods are not really available and even if, native methods already return a bytebuffer .. right ? or am i blind again ?

All the 'n' methods are publicly available in LWJGL 3. At the native side these are direct calls to the native function, there's no magic happening, only casts from JNI types to native types. In theory, you could write your own high-level API on top of those and ignore anything LWJGL does at the Java side. Pointer values are mapped to long primitive values obviously. LWJGL creates ByteBuffer instances in Java, using Unsafe instead of JNI's NewDirectByteBuffer.
5  Game Development / Newbie & Debugging Questions / Re: Byte buffer crashing on: 2015-02-11 12:29:27
What's with drivers that do not expose that debug output extension?

Are there such drivers? Note, this is for development only, the deployed application does not have to require a debug output extension.

Because of this asynchronicity is it then not possible for your program to crash because of a faulty GL call before being able to receive a GL error asynchornously by the driver in time?

If that indeed happens, you can enable GL_DEBUG_OUTPUT_SYNCHRONOUS.
6  Game Development / Newbie & Debugging Questions / Re: Byte buffer crashing on: 2015-02-11 12:17:38
I'm open to returning null, but not because glGetError is "expensive". If the default behavior confuses users or makes debugging harder, then it obviously has to change.

Btw, I never said use glGetError, or fill your code with error checks. There is a reason LWJGL 3 does not have a "debug jar" like LWJGL 2, manual checking is obsolete now that we have the *_debug_output extensions and OpenGL 4.3+. Note that the error checking itself is not (more) expensive, the driver has to do it in any case, it's reporting the error that causes performance problems. This issue goes away with debug output, because the debug callbacks may be called asynchronously (i.e. not in the same thread that called the OpenGL function and triggered an error) and you also have full control of the level of error/issue reporting.
7  Game Development / Newbie & Debugging Questions / Re: Byte buffer crashing on: 2015-02-11 11:33:40
LWJGL 3 indeed by default returns a ByteBuffer pointing at 0L. If you enable debug mode (-Dorg.lwjgl.util.Debug=true) you will get an exception instead.

You could argue that it's a problem with LWJGL, but this is an application bug really. You're using the result of MapBuffer without checking for OpenGL errors. Which I'm sure what is happening here, otherwise you wouldn't be getting a null pointer back.

I highly recommend setting up a debug message callback while developing your application. It's particularly easy in LWJGL 3:

1  
debugProc = GLContext.createFromCurrent().setupDebugMessageCallback();

Don't forget to store the returned Closure somewhere, like GLFW callbacks. You may also have to create a debug context (see the GLFW_OPENGL_DEBUG_CONTEXT window hint).
8  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.
9  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.
10  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.
11  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.
12  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.
13  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.
14  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).
15  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
16  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.
17  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
18  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.
19  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.
20  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.
21  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!
22  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.
23  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.
24  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.
25  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.
26  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
27  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.
28  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.
29  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).
30  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.
Pages: [1] 2 3 ... 27
 
Pippogeek (16 views)
2015-03-05 14:36:23

Pippogeek (13 views)
2015-03-05 13:56:12

Pippogeek (11 views)
2015-03-05 13:55:41

Pippogeek (13 views)
2015-03-05 13:23:02

Pippogeek (14 views)
2015-03-05 13:15:28

Pippogeek (9 views)
2015-03-05 13:15:04

Pippogeek (17 views)
2015-03-05 13:13:24

Pippogeek (21 views)
2015-03-05 13:11:33

BurntPizza (46 views)
2015-02-27 06:09:35

BurntPizza (35 views)
2015-02-27 05:56:17
How to: JGO Wiki
by Mac70
2015-02-17 20:56:16

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