Well, I've finally got around to putting a binary build of my project Praxis up at http://code.google.com/p/praxis/  Whether the project as a whole is of interest may depend on quite how wide your definition of games is  , but as this forum has been a great help I thought I'd at least post it here.

So, what is it??? Praxis is a framework for playing with a range of media (video/image, audio, MIDI, etc).  I use it for creating interactive things in real physical spaces, as well as occasionally for audio(-visual) performances.  You can get a rough sense of what I mean from this video (http://video.google.com/videoplay?docid=-1631892283027158552) - an interactive space using webcam movement detection to control audio and image (this was actually created with Praxis's predecessor), or this performance (http://www.youtube.com/user/richardbolam#p/u/1/1zZfSWjcWAI - second one in).

At its heart, Praxis satisfies two needs I had.  Firstly, it's a framework based around a loose mix of dataflow / actor model, allowing proper communication back and forth between various media threads (synchronized really is evil in this scenario!).  Secondly, it's completely configurable at runtime - it has it's own simple scripting language which hides all the complexity of passing messages back and forth, and also uses Janino to allow embedded fragments of Java code.

As a whole it's GPLv3 (to satisfy various dependencies).  However, I'm trying to release various modules from it under more liberal licences where possible (either GPL w/CPE or LGPL).  At the moment, there's various audio server and audio processing stuff under more liberal licences, as well as a binding for the JACK audio library using JNA.  There should be more to come - the audio routing library could probably be with CPE too.  Although everything's built as a NetBeans module, as Praxis uses the NetBeans runtime container, only the player module depends on NetBeans API's so the library JARs should just work.

It's still got a way to go.  Next on the list is a hardware accelerated video pipeline (using Slick most likely), better live coding API and a graphical patcher environment.  Oh, and better documentation 

Feedback is appreciated, but feel free to ignore if it's not your thing! 

Best wishes,

Neil

Looks really neat! Great job

It is rather a LWJGL renderer.......

According to someone else, I'm Stallman's bot. According to you, I'm a JOGL bot. I only pointed out some inaccurate words about your renderer and I'm coherent, I have never written that I use any OpenGL renderer because there is a difference between using OpenGL and using a Java binding of OpenGL as a Java binding contains some features about windowing system (as far as I know neither LWJGL nor JOGL contains a complete binding of GLUT). I'm not a bot, I'm a human being, I may disagree with some JGO members, it does not mean that I'm a silly bot, I may have some real reasons to disagree with them.

It is not irrational, you have just forgotten my rational objections especially about less good performances than JNI, I spoke about the mechanism used by JNA on Microsoft Windows... I don't fear JNA, I just don't use it, I prefer using GlueGen.

I don't mix up anything as JOGL and LWJGL have their own windowing system and they can still interoperate with AWT and Swing. My wording was intentionally accurate. Actually, when using a renderer relying on these bindings, you mainly have the choice between using the windowing systems or toolkits provided by Java itself or using their windowing system... except if you really want to create a binding of GLUT or if you prefer using directly the windowing system of a given platform. What's wrong with that?

I remind you that I had spoken about Microsoft Platform Invoke (which is used by JNA on Microsoft Windows) and its bad impact on performances in the C# binding of OpenGL in OpenTk (previously in Tao Framework). Sorry for the off topic.

@gouessej

Thanks for derailing my thread!    I understand, and am already aware, of the points you're making.  However, I still intend to use the term "OpenGL renderer".  Even if the term "LWJGL renderer" might be more accurate at this particular time, and I still disagree that it is, I don't think it's in any way more understandable to people here or the project's wider audience.  It's not like I'm hiding the fact that it's implemented with LWJGL.  Other projects in the same space (Field / Processing) using JOGL also use the term OpenGL renderer, though interestingly Field is currently converting to LWJGL.

In regards to JNA, it has nothing to do with Platform Invoke, which AFAIK is a CLR technology anyway.  JNA is implemented using libffi.  Still, I know you've already been told this ... 

@SimonH

Thanks for lightening the mood around here!    Perhaps a case of mercury poisoning?!

The only thing I can find on that suggests it was removed in 2001!  Are we really taking over 10 year old performance as accurate of today, because ... gee ... this Java thing ain't half slow! 

If you really want to argue the merits either way of all this, please start a new thread.  I only mentioned JNA in the first place because I knew it was the other choice you'd disapprove of!  Personally, I'll use what works best for me - which means easy to develop and deploy as well as good performance.  Unless or until I or anyone else has a specific performance issue with Praxis or the various libs being released from it, then I have no interest in changing.  And I'd rather help contribute to making JNA faster, which (in a minor way) I've just done!