Please login or register.

Login with username, password and session length
Pages: 1 [2] 3 4 ... 10
 on: March 08, 2018, 15:33:51 
Started by Misterpin - Last post by spasi
First of all, read Memory management in LWJGL 3.

The methods that struct classes support for creating new instances (using GLFWImage as an example):

Code: [Select]
// Constructor, struct backed by whatever memory is backing the specified container
GLFWImage(ByteBuffer container)

// Uses memAlloc to allocate an uninitialized struct. The struct must be freed explicitly.
GLFWImage GLFWImage.malloc()
// Uses memCalloc to allocate a zero-filled struct. The struct must be freed explicitly.
GLFWImage GLFWImage.calloc()
// Uses ByteBuffer.allocateDirect to allocate a zero-filled struct
GLFWImage GLFWImage.create()
// Returns a struct that wraps the specified pointer address (unsafe)
GLFWImage GLFWImage.create(long address)

// Same as above, but an array of structs is returned
GLFWImage.Buffer GLFWImage.malloc(int capacity)
GLFWImage.Buffer GLFWImage.calloc(int capacity)
GLFWImage.Buffer GLFWImage.create(int capacity)
GLFWImage.Buffer GLFWImage.create(long address, int capacity)

// Same as above, but the struct is backed by "stack" memory. If the current stack frame goes away, the struct goes away automatically.
GLFWImage GLFWImage.mallocStack(MemoryStack stack)
GLFWImage GLFWImage.callocStack(MemoryStack stack)
GLFWImage.Buffer GLFWImage.mallocStack(int capacity, MemoryStack stack)
GLFWImage.Buffer GLFWImage.callocStack(int capacity, MemoryStack stack)

You may use any of the above, depending on the use-case. It helps to have a good mental model of the methods that allocate memory. In terms of performance, from fastest to slowest:

- mallocStack
- callocStack
- malloc
- calloc
- create

And in terms of convenience, from more easiest to hardest:

- create (GCed automatically)
- malloc/callocStack (use the MemoryStack API to manage "stack frames", usually with try-with-resources blocks)
- malloc/calloc (must call .free() explicitly when the memory is no longer used)

 on: March 08, 2018, 15:23:00 
Started by Andrew Alfazy - Last post by Andrew Alfazy
thanks for your replay I've found the problems. stupid mistakes from me.sorry  :-[

 on: March 08, 2018, 15:16:23 
Started by Misterpin - Last post by Misterpin
Good afternoon!
I notice that each class has a constructor called Testclass(ByteBuffer container). And how can I create NkImage, STBImage, GLFWImage?
And how can I create NkContext instance?

 on: March 08, 2018, 15:06:42 
Started by Andrew Alfazy - Last post by spasi
Please make sure you aren't getting any OpenGL errors before the crash. Use:

Code: [Select]
// before creating the window/context

// after the call to GL.createCapabilities();

If that doesn't help, try LWJGLX/debug.

 on: March 08, 2018, 14:48:46 
Started by Andrew Alfazy - Last post by Andrew Alfazy
I'm moving from opengl1.4 to 3.3.
I just can't under stand some things.
should I use this code for windows?
Code: [Select]
if yes so why does my app crush when I call it?
i'm trying to use shaders and my app crush when I call
Code: [Select]
int shaderID = GL20.glCreateShader(GL20.GL_VERTEX_SHADER);Note: I'm on Windows XP, I'v tried VBO(s) and and VAO(s) and it worked will and my gpu ATI Radeon HD 3400 Series.

 on: March 08, 2018, 11:54:42 
Started by Misterpin - Last post by spasi
There's currently no reason to push for a 3.2 release. The release schedule is going well lately and there are fresh updates almost every weekly if you follow the nightly snapshots.

Also, a few notes on versioning:

- This library is called LWJGL 3, but it's a rewrite of LWJGL 2 that came before it. I.e. it's not really the 3rd major release of the LWJGL library, but completely new.
- So, we're currently at LWJGL v3.1.6, but you can think of it as LWJGL3 v1.6.
- I'm saving 3.2/3.3/etc. for major API-incompatible changes. It's like semantic versioning, but shifted to the right by a version number.
- I'm saving 4.0 for whenever Project Panama becomes available. LWJGL 3.x and 4.0 will be maintained in parallel, at least for a while.

 on: March 08, 2018, 11:51:02 
Started by lemmy101 - Last post by lemmy101
Great stuff! Thanks for the info! :) will look into the LWJGL 3 stuff when we finally get the port complete.

 on: March 08, 2018, 11:27:37 
Started by lemmy101 - Last post by spasi
It's possible, easy and safe. There's no difference between a native DLL doing OpenGL calls and LWJGL doing OpenGL calls. Technically it's the same thing, the LWJGL bindings use JNI to delegate the function calling to a DLL. The same function pointers are used, with the same handles and parameter values.

In general, OpenGL functions are "thread-local", they're processed by the OpenGL context that is current in the current thread. You can make a thread current in native code and do OpenGL calls in the same thread from Java, and vice-versa.

being able to use unmanaged native memory more efficiently for blocks of data.

Please note that LWJGL 3 has powerful mechanisms for off-heap memory management. There are three different memory allocators to choose from, there's a stack allocation API for efficient local allocations and there are debugging utilities (e.g. memory leak tracking). More details here:

Memory management in LWJGL 3

 on: March 08, 2018, 10:54:38 
Started by lemmy101 - Last post by lemmy101
Hey all! First of all we've not moved to LWJGL 3 yet, though it's planned in the short to midterm future, so any info on LWJGL 2 would be much appreciated too.

I'm wondering if its possible / easy for a native DLL using openGL directly within a LWJGL project to work alongside LWJGL without conflict?

Basically, I want to write a native renderer backend for dealing with the low level openGL calls with command lists and the like, and while I've considered doing this in java, I would really like to take advantage of c++ language features such as being able to use unmanaged native memory more efficiently for blocks of data.

However, before I start, I'm aware I won't have access to LWJGL from within the native library, and will be interacting with OpenGL directly. Has anyone done this before, and are direct calls to the openGL library going to feed into the same GL context, and if so are they going to conflict or screw with LWJGL in the process by changing states without its knowledge?



 on: March 08, 2018, 09:08:30 
Started by Misterpin - Last post by Misterpin
Thank you! I would like to ask a small question. Soon there was a release of LWJGL 3.2? I hope this should be a great update!

Pages: 1 [2] 3 4 ... 10