Version 3.2.3

William Bittle // Sep 4, 2016 8:41:14 PM

This release fixes issues with the getRadius(Vector2) method for the Slice, Capsule, Ellipse, and HalfEllipse shapes under local rotation and fixes the detect(AABB) method in the Sap broadphase.

Sadly, the getRadius(Vector2) method for the Ellipse classes boils down to a maximization/root finding problem.  Thankfully, the method should be called rarely so should have negligible performance impact.




Version 3.2.2

William Bittle // Jun 20, 2016 5:49:41 AM

This release is primarily for a new collision shape called Link. This shape extends the existing Segment shape and provides for smooth sliding across chains of Links.

There were some minor fixes and code clean up as well.




Version 3.2.1

William Bittle // Nov 24, 2015 3:38:22 AM

This is a maintenance release to fix a few critical bugs in the Polygon, Rectangle, and Segment classes for local rotations (see this post for details).

This release also contains some small enhancements (a few new methods) to some of the joints and a complete rewrite of all the joint class javadoc documentation.  The documentation should be much easier to read and should explain common use.




Version 3.2.0

William Bittle // Oct 1, 2015 6:00:06 AM

The primary goals for this release were performance enhancements and API clean up.  It took a lot longer than I had expected but I’m very happy with the results.  Highlights include improvements in the performance of collision detection and ray casting operations and a much cleaner public API and more thorough javadoc comments.Turbo Meme

The API has been changed a good bit and you’ll find some breaking changes.  Most, if not all, should be simple find/replace changes, the behavior should remain the same.  Those of note are:

  1. Body.setMass() was deprecated.  Use Body.setMass(MassType) instead.
  2. Mass.Type was renamed to MassType.
  3. MouseJoint was renamed to PinJoint.

All this got me thinking of the old days of the Turbo button which funny enough did the opposite of what you’d think…

 




Processing 3 is running for the first time on a Raspberry Pi using Eric Anholt's Mesa3D VC4 driver

xerxes // Jul 10, 2015 12:32:28 PM

Processing 3 is running for the first time on a Raspberry Pi using Eric Anholt's Mesa3D VC4 driver!

Video of the Processing 3 RGB cube demo running on the Raspberry Pi using Eric Anholt's Mesa3D VC4 OpenGL 2 driver:
/jogamp/vc4/video20150710_113912325.mp4

Thanks to the free software Mesa3d vc4 driver, the raspberry pi suddenly turned from a mobile opengl es 2 system into a "desktop" opengl 2 system.

Processing 3 is using JogAmp JOGL to tap into OpenGL hardware acceleration on the armv6 Raspberry Pi 1 and armv7 RaspberryPi 2 systems.

Hold on what is going on here, how can I setup the free software vc4 driver on my Raspberry Pi system?

This is a collaboration with Eric Anholt, anholt, and Gottfried Haider, gohai, to get Processing 3 running on the Raspberry Pi.

Eric Anholt has worked about a year to implement a full OpenGL 2 Mesa3D driver for use on the Raspberry Pi by using the Video Core 4, VC4, GPU.
http://anholt.livejournal.com/

Getting Eric Anholt's Mesa3D VC4 driver running on a Raspberry Pi is easily done thanks to the work by gohai.
gohai started out roughly following Eric's notes here: http://dri.freedesktop.org/wiki/VC4/
And then put together a buildbot in Python, to produce system images for use on the Pi or Pi2.

Kernel, Mesa, XServer packages & dependencies are from git. System image produced using gohai's buildbot
https://github.com/gohai/vc4-buildbot

gohai publish daily builds using his bot at:
http://sukzessiv.net/~gohai/vc4-buildbot/build/

Myself I have contributed to fix corner-cases in JogAmp JOGL OpenGL initialization to get it all running.

What was the problem using the proprietary OpenGL ES vc4 driver on the Raspberry Pi system?

The OpenGL ES standard do not cover how the native window is initialized.
When you initialize opengl es then you must pass a platform specific EGLNativeWindowType, EGLNativePixmapType and EGLNativeDisplayType depending on the OS you use.

If you read the Khronos header for eglplatform.h you will notice that the EGLNativeWindowType is different for
Windows: typedef HWND EGLNativeWindowType;
Mac: typedef void *EGLNativeWindowType;
Android: typedef struct ANativeWindow* EGLNativeWindowType;
Unix X11: typedef Window EGLNativeWindowType;

Creating an on-screen EGL rendering surface requires you to to use the eglCreateWindowSurface function, which takes a EGLNativeWindowType parameter. On the Raspberry Pi, however this is implemented as a EGL_DISPMANX_WINDOW_T struct, which is defined in eglplatform.h as:

typedef struct {
DISPMANX_ELEMENT_HANDLE_T element;
int width; /* This is necessary because dispmanx elements are not queriable. */
int height;
} EGL_DISPMANX_WINDOW_T;

As you can see RaspberryPi using the properitary binary drivers uses a Broadcom unique native window type that is incompatible with X11.
This is the reason why we cant use the Processing code as is to pass a Java AWT Unix X11 Window to initialize OpenGL ES, EGL will return an error that you have passed an incompatible structure to eglCreateWindowSurface.

When using Eric Anholt's Mesa3D vc4 driver then EGL will expect a Unix X11 Window for its EGLNativeWindowType and this is why processing will work out of the box when Erics Mesa3D vc4 driver in use. Eric's vc4 driver also implements OpenGL 2 that can be initialized using GLX. GLX allows you to run Processing with OpenGL acceleration across remote X11 network connections!

Cheers
Xerxes Rånby




dyn4j Moved to GitHub

William Bittle // Mar 14, 2015 7:07:35 AM

Due to Google’s decision to drop Google Code, I’ve moved the project to GitHub.  In truth, I’ve been contemplating this for a while now, but have had reservations about lost version history.  I feel this will help others contribute bug fixes and allow them to create their own forks and branches easier than before.

I haven’t fully check the revision history, but it looks like everything came over as expected.  I had to manually move all the wiki pages, but I was planning to do this anyway as well.  You can find them under Documentation on dyn4j.org.




JogAmp Release 2.3.0

Sven // Mar 12, 2015 12:00:36 PM

Release 2.3.0 has been published:

The test applets.

Overview of notable fixed bugs:

+++

This is a NON BACKWARD COMPATIBLE release,
introducing API CHANGES.
It CAN NOT be used as a binary/jar drop-in replacement.

API Changes
Extracted from our GlueGen and JOGL semantic versioning unit tests!

See Semantic Version Numbers

+++




Version 3.1.11

William Bittle // Jan 31, 2015 9:28:24 PM

This is a maintenance release of dyn4j that includes a bug fix for a StackOverflowException thrown from the raycast(Ray, double, boolean, boolean, List) method.  This release also includes some very minor performance tweaks. See the change detail in the release notes.

The Sandbox app was updated to fix a bug in the Java code exporter (Rays were not being exported).




Version 3.1.10

William Bittle // Jul 20, 2014 6:53:26 PM

This is a maintenance release of dyn4j that includes some major bug fixes.  See the change detail in the release notes.

The Sandbox app was not updated in this release.




Version 3.1.9

William Bittle // Mar 29, 2014 6:39:14 PM

This release of dyn4j includes some major bug fixes for the SweepLine class and other related convex decomposition classes.  It also includes some enhancements to the World.detect methods.  See the change detail in the release notes.

A new release of the Sandbox was published for this release for a small bug fix.