LLG plan

Well, getting the next version of the Lunar Lander game out the door for Christmas isn't going to happen.

The LLG plan is to free up CPU cycles from the graphics by switching from 2D to 3D. Which is counter intuitive. In 3D, the game can better access the graphics hardware via Open GL (on Java).

That path is panning out, but 3D is a pain in the neck. Quaternion multiplication is not commutative, (p*q) != (q*p).

I'd describe the situation as vector math being so powerful -- so much is accomplished with such simple expressions (like a*b) -- that the ideas implied must be held quite firmly in mind. But once one has got 3D coordinate spaces and transformations firmly in hand, it's a lot of fun. At least it's a lot of fun just getting there.

The software that I've found in the world for developing 3D applications isn't quite what I'm looking for. So I'll write some. And as "what I don't know" has a possible equivalence with "what unknown future applications will do", I'm just writing tools to open the doors on GL programming for web centric applications for myself.

The LLG game will be a first demo, flying a model. Then there's a list of things to do next.

As I get my head into 3D, all the world of web data applications looks like, "why aren't we doing this in 3D, now?".

I think there's a contribution to be made, here, in what we're looking for and how we're reaching for it.

Save energy, and see the stars

The COP15 conference was blogged by Alex Csete on youtube. 

Made me think.  I thought of Light Pollution.

Top to bottom media for data

Project building from data into renderers and actors presents the application development process with a very convenient structure.

This process is implicit in the use of binding and templating tools.

Partial work is bound and working partially, while fundamentally the data roots and programming leaves of the development process continuously guide iterations of inspection and discovery.

This self guided process of discovery is highly productive, and natural and fun.

The many layers of Fv3: Data handling and binding

As begun in "Boot loader", and continued in "Toolkit", data handling and binding is a central issue in many kinds of systems -- not least of all in Fv3.

First, Fv3 is a data parallel environment in service of the data parallel architecture of modern computer graphics hardware and its GL interface. In order to efficiently feed diverse and arbitrary data needs, Fv3 implements a file cache for web content. Over this file cache, Fv3 employs both memory buffering and file mapping strategies for loading data.

For example, the Fv3ds model loader employs file mapping to minimize the load time of large models transferred in this highly efficient file format. For this reason, the 3ds file format will be one of the most efficient ways to store and display large models in Fv3.

Data binding refers to the association of data with named or active elements of a system. Fv3 will use data binding from XML onto Java programming classes -- similarly to what WTKX did with conventional Java 2D graphics. This binding will configure a world, region or model into the screen view almost like a web HTML page does.

Unlike HTML, the Fv3 JBX files will be endlessly extensible for producing systems and applications.

Underlying the Fv3 data binding architecture are two processes. One binding XML onto Java Beans in JBXML, and the other binds Java Beans into template processing for source code generation in Hapax3. Static Design Time, and Dynamic Run Time source code generation and compilation are both open avenues for work and exploration in the future of Fv3.

Among other open topics in this work is the planned review of Jela, a part of JBX that adds Java Programming Language functions to JBXML. Currently, Jela functions add a layer of java method invocation to the execution path. While fast, this will inhibit the performance of Fv3. In future, Jela functions will be bound into a target component subclass for the runtime performance of normal plain old java code.

The many layers of Fv3: Toolkit

As begun in "The many layers of Fv3: Boot Loader", the Fv3Tk toolkit provides an OpenGL screen via JOGL-2.

OGL is a common software interface to the graphics hardware on your computer. These days computers and many of the latest cell phones come with powerful graphics computing hardware capable of rendering 3D graphics and video at full live action frame rates (24 frames per second and more).

Fv3Tk is intended to deliver graphics output, keyboard and joystick input, and audio subsystems to Fv3 applications as an independent layer over the JNLP Loader.

Using JOGL-2/NEWT before it's first release leaves us with some problems to solve, but it's all fun.

The many layers of Fv3: Boot Loader

Layers in software architecture are well known in the domain of operating systems, where system prom, device drivers and kernel are the first three layers to deliver applications over the operating system.

Layers are critical to software architecture. The design of each layer in a system is the beginning of the fight against bugs or issues in the software system. Ideally, each layer performs one role exceedingly well on behalf of the other layers in the system.

In an operating system, the boot prom or firmware tests the hardware when the power is turned on, and identifies the removable components attached to the hardware system. Having performed this task successfully, this built- in software program will load the operating system (kernel) from its storage in persistent memory, into transient memory, and run it.

Fv3 includes such a loader in jnlp-loader. The JNLP Loader installs and runs Fv3 from its persistent storage on the web, into a transient location on the desktop.

Test Fv3Tk

Mentioned in Fv3 Demo Apps, fv3tk needs testing.

For Windows, Linux, Solaris, MacOSX 10.5 Leopard...

If you know how to kill a process manually, then please test this for killing itself
on key ESC or keys Alt-F4.
{{{
 http://fv3tk.googlecode.com/svn/web/fv3tk-gears-loader-0.0.1.jar
}}}
And make a note here.. OS, Arch, Version, (run 
{{{
 java -classpath fv3tk-gears-0.0.1/cache/ fv3tk.Os
}}}

...works, not?

many thanks

Fv3 Demo Apps

My dreams, today, include

Lunar Lander version "G"

WebSDR

GPredict

Open Rocket

Feeds

and my "Mission Builder", an original composition and physics programming environment. Actually, it's almost the same idea as Open Rocket -- but completely different.

Of course, LLG is scheduled for Christmas.

Help LLG meet its schedule.. test fv3tk if you know how to kill a process manually (test exit failsafe).

LXL 1.0.3 begin

The lxl-coder project has been initialized, in support of Fv3.

The lxl-coder.jar library includes the io, net, beans, and hapax3 packages optimized for the lxl stream into jbxml and fv3.

lxl-coder generates java source classes from Hapax3 templates and ODL schematics.

An ODL schematic describes this

package test;
public class Test {
    public int a;
}

with

package test;
class Test {
 int a;
}

which is very useful as the output source text gets complex and continues to evolve over a large collection.

In building Fv3, the simple first target for this work is the description and programming package.

And then in extending Fv3, we have use of many more DOM like packages from sound to collada.