Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (804)
Games in Android Showcase (239)
games submitted by our members
Games in WIP (868)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 ... 4 5 [6] 7
  ignore  |  Print  
  Vulkan 1.0 Release  (Read 132356 times)
0 Members and 1 Guest are viewing this topic.
Offline ziozio
« Reply #150 - Posted 2016-03-17 23:48:40 »

ok, so I went ahead and completed the travisci config for android anyway. @spasi feel free to include this in to the build when you have time. Like before this is only for jemalloc so should be adaptable to the other projects

.travis.yml

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
env:
language: c
compiler: arm-linux-androideabi-gcc
before_install:
- export PATH=$PATH:$HOME/.local/bin
- export ANDROID_NDK_VERSION=r11b
- export ANDROID_TOOLCHAIN=arm-linux-androideabi-4.9
- export NDK_PLATFORM=android-9
- echo $ANDROID_NDK_VERSION
- wget http://dl.google.com/android/repository/android-ndk-$ANDROID_NDK_VERSION-linux-x86_64.zip -O ndk.zip
- unzip -qq ./ndk.zip
- export ANDROID_NDK_HOME=`pwd`/android-ndk-$ANDROID_NDK_VERSION
- export PLATFORM_PREFIX=./android-ext/
- mkdir $PLATFORM_PREFIX
- $ANDROID_NDK_HOME/build/tools/make-standalone-toolchain.sh --toolchain=$ANDROID_TOOLCHAIN --platform=$NDK_PLATFORM --install-dir=$PLATFORM_PREFIX
- export PATH=$PLATFORM_PREFIX/bin:$PATH
script:
- ./autogen.sh --with-jemalloc-prefix=je_ --with-malloc-conf=purge:decay --host=arm-linux-androideabi
- make
- cd lib
- ls -alrt
- file libjemalloc.so.2


The configurable bits here are

1  
2  
3  
- export ANDROID_NDK_VERSION=r11b
- export ANDROID_TOOLCHAIN=arm-linux-androideabi-4.9
- export NDK_PLATFORM=android-9


The ndk version is the latest available (the one with vulcan in) and I choose a very low NDK_PLATFORM but this can be changed.

The output from the travici run I did is below

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
arm-linux-androideabi-gcc -std=gnu99 -Wall -Werror=declaration-after-statement -pipe -fvisibility=hidden -O3 -funroll-loops -c -D_GNU_SOURCE -D_REENTRANT -Iinclude -Iinclude -o src/base.o src/base.c
arm-linux-androideabi-gcc -std=gnu99 -Wall -Werror=declaration-after-statement -pipe -fvisibility=hidden -O3 -funroll-loops -c -D_GNU_SOURCE -D_REENTRANT -Iinclude -Iinclude -o src/bitmap.o src/bitmap.c
arm-linux-androideabi-gcc -std=gnu99 -Wall -Werror=declaration-after-statement -pipe -fvisibility=hidden -O3 -funroll-loops -c -D_GNU_SOURCE -D_REENTRANT -Iinclude -Iinclude -o src/chunk.o src/chunk.c
arm-linux-androideabi-gcc -std=gnu99 -Wall -Werror=declaration-after-statement -pipe -fvisibility=hidden -O3 -funroll-loops -c -D_GNU_SOURCE -D_REENTRANT -Iinclude -Iinclude -o src/chunk_dss.o src/chunk_dss.c
arm-linux-androideabi-gcc -std=gnu99 -Wall -Werror=declaration-after-statement -pipe -fvisibility=hidden -O3 -funroll-loops -c -D_GNU_SOURCE -D_REENTRANT -Iinclude -Iinclude -o src/chunk_mmap.o src/chunk_mmap.c
arm-linux-androideabi-gcc -std=gnu99 -Wall -Werror=declaration-after-statement -pipe -fvisibility=hidden -O3 -funroll-loops -c -D_GNU_SOURCE -D_REENTRANT -Iinclude -Iinclude -o src/ckh.o src/ckh.c
arm-linux-androideabi-gcc -std=gnu99 -Wall -Werror=declaration-after-statement -pipe -fvisibility=hidden -O3 -funroll-loops -c -D_GNU_SOURCE -D_REENTRANT -Iinclude -Iinclude -o src/ctl.o src/ctl.c
arm-linux-androideabi-gcc -std=gnu99 -Wall -Werror=declaration-after-statement -pipe -fvisibility=hidden -O3 -funroll-loops -c -D_GNU_SOURCE -D_REENTRANT -Iinclude -Iinclude -o src/extent.o src/extent.c
arm-linux-androideabi-gcc -std=gnu99 -Wall -Werror=declaration-after-statement -pipe -fvisibility=hidden -O3 -funroll-loops -c -D_GNU_SOURCE -D_REENTRANT -Iinclude -Iinclude -o src/hash.o src/hash.c
arm-linux-androideabi-gcc -std=gnu99 -Wall -Werror=declaration-after-statement -pipe -fvisibility=hidden -O3 -funroll-loops -c -D_GNU_SOURCE -D_REENTRANT -Iinclude -Iinclude -o src/huge.o src/huge.c
arm-linux-androideabi-gcc -std=gnu99 -Wall -Werror=declaration-after-statement -pipe -fvisibility=hidden -O3 -funroll-loops -c -D_GNU_SOURCE -D_REENTRANT -Iinclude -Iinclude -o src/mb.o src/mb.c
arm-linux-androideabi-gcc -std=gnu99 -Wall -Werror=declaration-after-statement -pipe -fvisibility=hidden -O3 -funroll-loops -c -D_GNU_SOURCE -D_REENTRANT -Iinclude -Iinclude -o src/mutex.o src/mutex.c
arm-linux-androideabi-gcc -std=gnu99 -Wall -Werror=declaration-after-statement -pipe -fvisibility=hidden -O3 -funroll-loops -c -D_GNU_SOURCE -D_REENTRANT -Iinclude -Iinclude -o src/nstime.o src/nstime.c
arm-linux-androideabi-gcc -std=gnu99 -Wall -Werror=declaration-after-statement -pipe -fvisibility=hidden -O3 -funroll-loops -c -D_GNU_SOURCE -D_REENTRANT -Iinclude -Iinclude -o src/pages.o src/pages.c
arm-linux-androideabi-gcc -std=gnu99 -Wall -Werror=declaration-after-statement -pipe -fvisibility=hidden -O3 -funroll-loops -c -D_GNU_SOURCE -D_REENTRANT -Iinclude -Iinclude -o src/prng.o src/prng.c
arm-linux-androideabi-gcc -std=gnu99 -Wall -Werror=declaration-after-statement -pipe -fvisibility=hidden -O3 -funroll-loops -c -D_GNU_SOURCE -D_REENTRANT -Iinclude -Iinclude -o src/prof.o src/prof.c
arm-linux-androideabi-gcc -std=gnu99 -Wall -Werror=declaration-after-statement -pipe -fvisibility=hidden -O3 -funroll-loops -c -D_GNU_SOURCE -D_REENTRANT -Iinclude -Iinclude -o src/quarantine.o src/quarantine.c
arm-linux-androideabi-gcc -std=gnu99 -Wall -Werror=declaration-after-statement -pipe -fvisibility=hidden -O3 -funroll-loops -c -D_GNU_SOURCE -D_REENTRANT -Iinclude -Iinclude -o src/rtree.o src/rtree.c
arm-linux-androideabi-gcc -std=gnu99 -Wall -Werror=declaration-after-statement -pipe -fvisibility=hidden -O3 -funroll-loops -c -D_GNU_SOURCE -D_REENTRANT -Iinclude -Iinclude -o src/stats.o src/stats.c
arm-linux-androideabi-gcc -std=gnu99 -Wall -Werror=declaration-after-statement -pipe -fvisibility=hidden -O3 -funroll-loops -c -D_GNU_SOURCE -D_REENTRANT -Iinclude -Iinclude -o src/tcache.o src/tcache.c
arm-linux-androideabi-gcc -std=gnu99 -Wall -Werror=declaration-after-statement -pipe -fvisibility=hidden -O3 -funroll-loops -c -D_GNU_SOURCE -D_REENTRANT -Iinclude -Iinclude -o src/ticker.o src/ticker.c
arm-linux-androideabi-gcc -std=gnu99 -Wall -Werror=declaration-after-statement -pipe -fvisibility=hidden -O3 -funroll-loops -c -D_GNU_SOURCE -D_REENTRANT -Iinclude -Iinclude -o src/tsd.o src/tsd.c
arm-linux-androideabi-gcc -std=gnu99 -Wall -Werror=declaration-after-statement -pipe -fvisibility=hidden -O3 -funroll-loops -c -D_GNU_SOURCE -D_REENTRANT -Iinclude -Iinclude -o src/util.o src/util.c
arm-linux-androideabi-ar crus lib/libjemalloc.a src/jemalloc.o src/arena.o src/atomic.o src/base.o src/bitmap.o src/chunk.o src/chunk_dss.o src/chunk_mmap.o src/ckh.o src/ctl.o src/extent.o src/hash.o src/huge.o src/mb.o src/mutex.o src/nstime.o src/pages.o src/prng.o src/prof.o src/quarantine.o src/rtree.o src/stats.o src/tcache.o src/ticker.o src/tsd.o src/util.o
arm-linux-androideabi-ar crus lib/libjemalloc_pic.a src/jemalloc.pic.o src/arena.pic.o src/atomic.pic.o src/base.pic.o src/bitmap.pic.o src/chunk.pic.o src/chunk_dss.pic.o src/chunk_mmap.pic.o src/ckh.pic.o src/ctl.pic.o src/extent.pic.o src/hash.pic.o src/huge.pic.o src/mb.pic.o src/mutex.pic.o src/nstime.pic.o src/pages.pic.o src/prng.pic.o src/prof.pic.o src/quarantine.pic.o src/rtree.pic.o src/stats.pic.o src/tcache.pic.o src/ticker.pic.o src/tsd.pic.o src/util.pic.o


The command "make" exited with 0.
$ cd lib


The command "cd lib" exited with 0.
$ ls -alrt
total 1204
drwxrwxr-x 13 travis travis   4096 Mar 17 23:44 ..
-rwxrwxr-x  1 travis travis 400964 Mar 17 23:44 libjemalloc.so.2
lrwxrwxrwx  1 travis travis     16 Mar 17 23:44 libjemalloc.so -> libjemalloc.so.2
-rw-rw-r--  1 travis travis 412232 Mar 17 23:44 libjemalloc_pic.a
-rw-rw-r--  1 travis travis 412136 Mar 17 23:44 libjemalloc.a
drwxrwxr-x  2 travis travis     94 Mar 17 23:44 .


The command "ls -alrt" exited with 0.
$ file libjemalloc.so.2
libjemalloc.so.2: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), not stripped


The command "file libjemalloc.so.2" exited with 0.

Done. Your build exited with 0.
Offline princec

« JGO Spiffy Duke »


Medals: 1146
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #151 - Posted 2016-03-18 00:06:17 »

I am eagerly awaiting LWJGL on the Pi (headless?)

Cas Smiley

Offline Spasi
« Reply #152 - Posted 2016-03-18 00:46:44 »

I am eagerly awaiting LWJGL on the Pi (headless?)

My guess is it requires Pi-specific APIs. Could you please point me to a working sample/tutorial that does headless OpenGL?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

« JGO Spiffy Duke »


Medals: 1146
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #153 - Posted 2016-03-18 10:19:22 »

Heh, Google-fu:

https://benosteen.wordpress.com/2012/04/27/using-opengl-es-2-0-on-the-raspberry-pi-without-x-windows/
https://jan.newmarch.name/LinuxSound/Diversions/RaspberryPiOpenGL/

Potentially more troublesome is mouse/keyboard support.

Cas Smiley

Offline theagentd
« Reply #154 - Posted 2016-03-18 11:09:33 »

Wrote a very simple Java Agent that allows you to use LWJGL 3's stack allocation without having to create stack frames manually and handle control-flow (returns and exceptions) separately by stackPush/stackPop yourself.

It automatically detects when you want to use stack allocation in a given method (looking for Struct.mallocStack/callocStack and MemoryStack.stackGet) and then provides the stack frame at the method start and frees it at the end of the method, properly handling every control flow (intermittent RETURNs in the method and exception throwing).

There are some caveats:
- you have to start the JVM with the VM argument "-javaagent:autostack.jar" (this is really annoying in my opinion, but unavoidable unless you want to have a custom build/compile step)
- it really is a 1:1 mapping between the lifecycle of Java methods/stack frames and MemoryStack stack frames, so if you decide to wrap/delegate stack allocation of structs to some other method that expect some stack to be setup by the caller which survives the callee, you're out of luck Smiley

Code: https://github.com/httpdigest/lwjgl3-autostack
Hmm. Since this essentially modifies the bytecode before passing it to the JIT compiler, would it be possible to permanently preprocess a jar-file with the agent so that it doesn't have to be done at runtime?

Myomyomyo.
Offline nsigma
« Reply #155 - Posted 2016-03-18 11:18:59 »

I am eagerly awaiting LWJGL on the Pi (headless?)

Any idea what the (longer term) benefit would be to having it headless?

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline princec

« JGO Spiffy Duke »


Medals: 1146
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #156 - Posted 2016-03-18 11:27:32 »

Not having to boot into X11 with all its attendant guff and wastage (and delay).

As it happens right now I'm in the commercial embedded device world and having a Pi boot into a usable touchscreen GUI in less than 20 seconds from cold would be a massive win for me.

Cas Smiley

Offline nsigma
« Reply #157 - Posted 2016-03-18 12:09:23 »

@princec - ah, good point!  I was more wondering what the runtime performance differences might be between the OpenGL ES headless mode and the full OpenGL X11 one (having read recently that it's now in public beta)  Wasn't thinking about boot time.

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline princec

« JGO Spiffy Duke »


Medals: 1146
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #158 - Posted 2016-03-18 12:16:00 »

And of course, memory's a bit tight on a Pi, you don't want to waste any of it on X11 if you can help it

Cas Smiley

Offline KaiHH

JGO Kernel


Medals: 796



« Reply #159 - Posted 2016-03-18 12:18:14 »

Hmm. Since this essentially modifies the bytecode before passing it to the JIT compiler, would it be possible to permanently preprocess a jar-file with the agent so that it doesn't have to be done at runtime?
That's what I meant with "you have to start the JVM with the VM argument "-javaagent:autostack.jar" (this is really annoying in my opinion, but unavoidable unless you want to have a custom build/compile step)"
I'll also provide an ant task and a Maven plugin to do that in a custom build step.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 123
Projects: 15


★★★★★


« Reply #160 - Posted 2016-03-18 12:33:57 »

Wouldn't using Wayland (which GLFW3 already supports to an extent) be a possible solution instead of X11 on the Pi? Its alot more lightweight than X11 and won't require using any Pi specific API's.
Offline theagentd
« Reply #161 - Posted 2016-03-18 14:07:42 »

Hmm. Since this essentially modifies the bytecode before passing it to the JIT compiler, would it be possible to permanently preprocess a jar-file with the agent so that it doesn't have to be done at runtime?
That's what I meant with "you have to start the JVM with the VM argument "-javaagent:autostack.jar" (this is really annoying in my opinion, but unavoidable unless you want to have a custom build/compile step)"
I'll also provide an ant task and a Maven plugin to do that in a custom build step.
I may be overhyping this a bit, but I think this is a HUGE improvement. Does the Java agent negatively impact performance in any way? Is there a risk that it inserts unnecessary pushes/pops, or does it affect startup time/compilation stutter noticeably (if it's used live, not preprocessed)?

Myomyomyo.
Offline princec

« JGO Spiffy Duke »


Medals: 1146
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #162 - Posted 2016-03-18 14:12:13 »

In theory Wayland would be just great. Still some question over mouse/keyboard/touch of course.

Cas Smiley

Offline kappa
« League of Dukes »

JGO Kernel


Medals: 123
Projects: 15


★★★★★


« Reply #163 - Posted 2016-03-18 14:33:38 »

In theory Wayland would be just great. Still some question over mouse/keyboard/touch of course.

Cas Smiley
LibInput seems to be the most commonly used library by Wayland compositors to handle mouse/keyboard/touch. As the backend is still experimental not sure input support has been added yet but should eventually just be as simple as using GLFW's api to handle input.
Offline ClaasJG

JGO Coder


Medals: 43



« Reply #164 - Posted 2016-03-18 14:34:29 »

[...]"you have to start the JVM with the VM argument "-javaagent:autostack.jar" (this is really annoying in my opinion, but unavoidable unless you want to have a custom build/compile step)"[...]
While still developing stuff you can 'pipe' everything through a custom class loader which applies the transformation.
But writing ClassLoaders  persecutioncomplex

-ClaasJG

My english has to be tweaked. Please show me my mistakes.
Offline KaiHH

JGO Kernel


Medals: 796



« Reply #165 - Posted 2016-03-18 14:54:32 »

I may be overhyping this a bit, but I think this is a HUGE improvement. Does the Java agent negatively impact performance in any way? Is there a risk that it inserts unnecessary pushes/pops, or does it affect startup time/compilation stutter noticeably (if it's used live, not preprocessed)?
Thanks! Actually, I was quite interested in whether and how much people would perceive this as helpful or not. There is no performance penalty at runtime once the classes have been transformed. The code generation does exactly what javac or the Eclipse incremental compiler would do when wrapping the method's source in a Java try-finally. There is however a startup penalty to pay for having to scan the methods that need transformation.
To reduce that as much as possible you can give the javaagent a custom package prefix so that it only looks in those classes. See the README.
Offline KaiHH

JGO Kernel


Medals: 796



« Reply #166 - Posted 2016-03-18 15:10:22 »

While still developing stuff you can 'pipe' everything through a custom class loader which applies the transformation.
Yes, true. I think the problem with using a javaagent is not so much that it complicates development (that can be as complicated as need be), but that it complicates productive deployment.
And when using a custom ClassLoader, yes you could do this also using a JVM argument "-Djava.system.class.loader=" (which of course just trades the -javaagent argument for this one Smiley ) or you would have to bootstrap your application differently, and therefore interfering with user/application code.
Offline Spasi
« Reply #167 - Posted 2016-03-18 15:34:23 »

In theory Wayland would be just great. Still some question over mouse/keyboard/touch of course.

Cas Smiley
LibInput seems to be the most commonly used library by Wayland compositors to handle mouse/keyboard/touch. As the backend is still experimental not sure input support has been added yet but should eventually just be as simple as using GLFW's api to handle input.

Looks like there already is support for mouse and keyboard in GLFW's Wayland backend. Uses Wayland APIs and xkbcommon.
Offline KaiHH

JGO Kernel


Medals: 796



« Reply #168 - Posted 2016-03-18 17:04:12 »

This change improves performance of Struct.mallocStack()/callocStack() that would implicitly access TLS, by storing the pushed MemoryStack once in a local variable at the beginning and then transforming the Struct.mallocStack()/callocStack() to Struct.malloc(stack)/calloc(stack) using that stack variable.
So even if you write suboptimal code not using a MemoryStack local, the agent now fixes that for you. Smiley

EDIT: With this change, static invocations on the TLS lookup MemoryStack.stackGet() will now transform to a simple load of the local variable which was already created at the beginning of the method.

For a comparison of what can be achieved with this, see this demo.
It is a port of the lwjgl3-demos Vulkan ClearScreenDemo demo to make use of autostack for all structs and NIO buffers. This completely eradicates all calls to struct.free() and Buffer.free()......

EDIT2: There is now also the possibility to offline transform classes inside a jar file with this transformation process. Just use the same autostack.jar as an executable jar.
Offline Catharsis

JGO Ninja


Medals: 76
Projects: 1
Exp: 21 years


TyphonRT rocks!


« Reply #169 - Posted 2016-03-19 11:12:29 »

While this thread is mostly LWJGL / Vulkan progress related I just want to post the issue filed in the Android issues tracker for an official SDK binding for Vulkan. And I didn't even file it (stoked that someone else did!):
https://code.google.com/p/android/issues/detail?id=204085

Please star this issue if you are an Android dev. Of course LWJGL on Android will be great, but for stuff like my video engine updates for Vulkan / MediaCodec API will also need to be completed and an official SDK binding is the first step toward that support.

Check out the TyphonRT Video Suite:
http://www.typhonvideo.com/

Founder & Principal Architect; TyphonRT, Inc.
http://www.typhonrt.org/
http://www.egrsoftware.com/
https://plus.google.com/u/0/+MichaelLeahy/
Offline SilverTiger

JGO Coder


Medals: 41
Exp: 3 years


がんばってください!


« Reply #170 - Posted 2016-03-19 12:23:04 »

Seems like AMD is finally going a step further to the Linux driver release:
http://support.amd.com/en-us/kb-articles/Pages/AMDGPU-PRO-Beta-Driver-for-Vulkan-Release-Notes.aspx

Offline theagentd
« Reply #171 - Posted 2016-03-20 00:45:45 »

A note concerning stack allocation in the LWJGL classes: After updating, my shader compiling and linking log handling code started crashing due to having a maximum length of 65536 chars, since the buffer was stack allocated and the stack was too small. This might be one of the few cases where NOT using the stack would be a good idea.

Myomyomyo.
Offline Spasi
« Reply #172 - Posted 2016-03-20 12:44:37 »

After updating, my shader compiling and linking log handling code started crashing due to having a maximum length of 65536 chars, since the buffer was stack allocated and the stack was too small.

This has been fixed in the latest nightly build (#53), by allocating variable size buffers on the heap.

Also, a reminder: you can tune the default stack size with
Configuration.STACK_SIZE.set(n); // n is in kilobytes
.
Offline theagentd
« Reply #173 - Posted 2016-03-20 14:20:37 »

This has been fixed in the latest nightly build (#53), by allocating variable size buffers on the heap.
Thanks for the fast fix! =D

Myomyomyo.
Offline theagentd
« Reply #174 - Posted 2016-03-21 22:29:08 »

Okay, has anyone found where the spec text is for the different extensions. For example, what's the spec for VK_KHR_surface? According to https://community.amd.com/thread/197194 VK_PRESENT_MODE_FIFO_KHR is a guaranteed presentation mode, but I can't find the text that actually says that.

Myomyomyo.
Offline KaiHH

JGO Kernel


Medals: 796



« Reply #175 - Posted 2016-03-21 22:34:27 »

What you need is the specification + WSI extensions, found here:https://www.khronos.org/registry/vulkan/

See changelog on PDF page 713 (document page 693/729)
Offline theagentd
« Reply #176 - Posted 2016-03-21 22:39:55 »

What you need is the specification + WSI extensions, found here:https://www.khronos.org/registry/vulkan/

See changelog on PDF page 713 (document page 693/729)
That's not the spec. That's a list of functions and no information at all about them.

Myomyomyo.
Offline KaiHH

JGO Kernel


Medals: 796



« Reply #177 - Posted 2016-03-21 22:43:48 »

How do you know that this is _not_ a spec? After all the title says "- A specification" Wink and it somewhat _specifies_ the operational and syntactic semantics of the functions.
I don't think you'll find anything more specy than that.
Also for your concrete question, look at PDF page 549.
Offline KaiHH

JGO Kernel


Medals: 796



« Reply #178 - Posted 2016-03-21 22:56:49 »

But yeah I feel with you, we all would like to see more prose text in the form of a Programmer's Guide, like with the fantastic Mantle Programming Guide and API Reference.
God, I love that document. Taught me most about Vulkan.
I'd like to see something like that for Vulkan, too, yes.
Offline gouessej
« Reply #179 - Posted 2016-03-22 11:54:50 »

Hi

Is it possible to use LWJGL 3 Java binding for the Vulkan API without GLFW (with another windowing toolkit)?

Julien Gouesse | Personal blog | Website | Jogamp
Pages: 1 ... 4 5 [6] 7
  ignore  |  Print  
 
 

 
Riven (521 views)
2019-09-04 15:33:17

hadezbladez (5494 views)
2018-11-16 13:46:03

hadezbladez (2397 views)
2018-11-16 13:41:33

hadezbladez (5755 views)
2018-11-16 13:35:35

hadezbladez (1217 views)
2018-11-16 13:32:03

EgonOlsen (4658 views)
2018-06-10 19:43:48

EgonOlsen (5667 views)
2018-06-10 19:43:44

EgonOlsen (3193 views)
2018-06-10 19:43:20

DesertCoockie (4093 views)
2018-05-13 18:23:11

nelsongames (5048 views)
2018-04-24 18:15:36
A NON-ideal modular configuration for Eclipse with JavaFX
by philfrei
2019-12-19 19:35:12

Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08
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!