| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
using our OpenJFK 9 x86_64 and arm64 build.
Test demo class is 'com.jogamp.opengl.demos.ios.Hello',
residing in the new demo folder 'src/demos/com/jogamp/opengl/demos/ios/Hello.java'.
This commit does not yet include a working NEWT
specialization for iOS, but it shall followup soon.
Instead this commit demonstrates JOGL operating on
native UIWindow, UIView and CAEAGLLayer as provided by
Nativewindow's IOSUtil.
Test Video https://www.youtube.com/watch?v=Z4lUQNFTGMI
+++
Notable bug: The FBO used and sharing the COLORBUFFER RENDERBUFFER
memory resources with CAEAGLLayer to be displayed in the UIView
seemingly cannot handle GL_DEPTH_COMPONENT16, GL_DEPTH_COMPONENT24
or GL_DEPTH_COMPONENT32 depth buffer - none at all (Device + Simulation).
Therefor the default demo GLEventListener chosen here
don't require a depth buffer ;-)
This issue can hopefully be mitigated with other means
than using a flat FBO sink similar to FBO multisampling.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
oculusvr-sdk java distortion-mesh calculation if available
StereoDeviceFactory support new GenericStereoDeviceFactory, with it's GenericStereoDevice and GenericStereoDeviceRenderer.
GenericStereoDevice maintains different configurations, triggered either by passing a GenericStereoDevice.Config
instance directly or by the device-index parameter:
- 0: monoscopi device: No post-processing
- 1: stereoscopic device SBS: No post-processing
- 2: stereoscopic device SBS + Lenses: Distortion post-processing
(only available w/ oculusvr-sdk sub-module)
Producing a 'GenericStereoDevice.Config' instance is self containing
and may extend if supporting more device types like top-bottom, interlaced etc.
StereoDemo01 handles all use-cases and may be used as a test-bed
to add and experiment with stereoscopy, devices and settings.
|
|
|
|
| |
jogl-test-java-src.zip
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bring-up test only initializes the ovrHmdHandle
data structure by OVR native code.
See com.jogamp.oculusvr.OVRVersion
Current evaluation build compiles all OVR-SDK source
files itself w/o using provided libovr.a.
We also skip the GL dependent renderer of the SDK,
i.e. we prefer to utilize our JOGL 'barrel distortion' renderer.
This eases the 'chicken-egg' problem of OVR SDK dependencies,
i.e. libGL, libGLESv2 .. etc
Since the OVR source code is C++, we may still have to figure out
how to / and whether we shall link libstdc++ statically
to remove platform dependencies.
Right now we link libstdc++ statically if using GCC,
see make/build-oculusvr.xml (hackish .. TODO: better way to include all symbols).
Same consideration applies to GNU/Linux and libudev.so dependency,
since there are:
- libudev.so.0 and (Older distri's)
- libudev.so.1 (Debian8, ..)
...
Produced JAR artifacts are
- jar/atomic/oculusvr.jar
- jar/atomic/oculusvr-natives-<os.and.arch>.jar
i.e. only in 'atomic' variants to not bloat the default 'all' JAR files.
....
make/build-oculusvr.xml Notes:
- Currently native build only enabled on GNU/Linux (isLinux)
- Force disable native build via property 'c.build.oculusvr.skip'
|
|
|
|
|
|
|
| |
See GlueGen commits:
- c06288d2a12586ab8df3715cf130549fdd7499fb
- 64615f17a8c63f692159235e169dbdd14d30b737
- 1a504fa682e6f28c5543da4d5885c7f2ff4ed3f1
|
|
|
|
|
|
| |
- Adding 'plugin3-public' jar and sources for Applet3 support, copied from icedtea-web3
- Added com.jogamp.newt.util.applet.JOGLNewtApplet3Run capable to run Applet3
|
|
|
|
|
|
|
|
| |
Relying on junit 4.11 + hamcrest 1.2 (deployed in Gluegen junit.jar)
See gluegen commits:
- 10a28c860bd3f4ccecef156c9bbbc88087bf568d
- 70c9ba258c5ba3d78f0f52faf37d88b4c62d0c96
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note: May be relocated to external project later!
Assumption:
gluegen/
joal/
jogl/
For OpenAL / JOAL code:
- use the package jogamp.opengl.openal (like jogamp.opengl.android)
- will be build _before_ the other 2nd pass java files
- do not expose OpenAL/JOAL APIs, if being used by other packages,
since only this package is being compiled w/ JOAL jar files!
|
|
|
|
|
|
|
|
| |
Android API 14 MediaPlayer impl of GLMediaPlayer.
Android API 14 MediaPlayer allows usage of OMX AL direct decode to texture via libstagefright (OMX AL usage included).
Status: Untested, not working - Need to fix native OMX IL (stream detect and split) and/or GStreamer implementation.
|
|
|
|
|
|
|
|
| |
0cfc7847c58b51c9a26b50d905b592d1fc4c8578)
- Remove jogl.android-launcher.apk in favor of generic jogamp.android-launcher.apk
- All Android test code resides in jogl.test.apk (initial launcher and delegated 'real' one)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
separation ; android cleanup
remaining all-in-one jnlp's / jars:
jogl-all-awt.jnlp -> jogl.all.jar
jogl-all-noawt.jnlp -> jogl.all-noawt.jar
jogl-all-mobile.jnlp -> jogl.all-mobile.jar
native for all above: jogl-all-natives-linux-amd64.jar
jogl.all-android.apk jogl.all-android.jar
more may follow for each supported platfrom
++++
- newt: proper 'driver' separation
- all drivers reside now in jogamp.newt.driver.*
- remove intptr.cfg / use gluegen's
|
| |
|
| |
|
|
|
|
|
| |
This has to be handled through the user library for SWT or it
won't work on multiple platforms.
|
| |
|
|
|
|
|
|
|
| |
The new target just omits final JAR creation and file copying for
extra speed within an IDE. We also change where Eclipse looks for
the native libraries, since this new target doesn't copy them
to jogl/build/lib.
|
|
|
|
|
|
|
| |
Removed the Java builder, since it was rebuilding stuff the Ant build
had already done. Turned on the Ant build for incremental builds.
Changed the classpath of com/jogamp/opengl/impl/gl2/fixme/ to
jogamp/opengl/gl2/fixme/ to reflect the recent move.
|
|
|
|
|
|
| |
This addition makes it possible to run the SWT unit tests from
within Eclipse (once the user sets up the appropriate user
library as explained in the wiki).
|
|
Created the Eclipse project files needed to build jogl.
These files don't contain any absolute paths, but they do
depend on the user setting up the JRE and Ant properly
inside Eclipse.
|