Decomposition of a simple polygon into convex polygons

The Dev has implemented a algorithm decomposing concave polygons without holes into a list of convex polygons as per the paper "Decomposition of a polygon with holes into convex polygons" by José Fernández, Bolglárka Tóth, Lázaro Cánovas and Blas Pelegrín.

This is, of course, only a stepping stone to a algorithm that can decompose polygons with holes, but as my purpose is to inform you of progress, this is what I have done.

The Dev instructed me to include this data,he called it a 'Screen-Shot', I do not understand what it is:

I am back

I got a new power supply for my dell, things are back to normal.

More computer trouble

I am having more computer trouble, it should be fixed some time next week

Convex Decomposition

The Dev has concluded that decomposing complex Shapes into convex shapes, and then tessellating those as needed would be the more elegant and effective solution, so he is now working on the data structures that will be needed by a convex decomposition algorithm.

The benefits of convex decomposition vs triangulation include: fewer output shapes(because each may contain more than 3 vertices) and less likelihood of producing long, thin shapes(which tend to cause problems with physics simulations)

In addition, triangulating convex shapes is trivial and the Dev has already found a suitable paper detailing a convex decomposition algorithm.

Tessellation

The next step for the Dev is working on is the integration with jBox2D, specifically he will be making all bounds shapes available in jBox2D available to GlassFlame, right now you can only use rectangles.

In the end you will be able to create a bounds for your object using the CAG(the 2D form of CSG) tools in java2D, and then 'draw' this shape into a bounds creation draw target, along with any other draw commands to create a bounding shape.

In order to make this possible two things must happen first: A class must be created which will be able to convert a java2D Shape into a list of triangles, and the drawing system must be redone to handle arbitrary java2D Shapes.

The hardest part will likely be tessellation of the Shapes, and this is what the Dev will work on now.

Squeek!

The mouse event system is coming along well, despite the oddities of LWJGL and AWT. To be specific: AWT refuses to report mouse move/drag events, probably because LWJGL is interfering somehow,but reports all other events fine, LWJGL reports events in such a way that compiling mouse press/release/click events is somewhat tricky, so AWT is used for that. 'On top of all that' LWJGL reports mouse position with 0,0 at the top-left corner of the window, rather then the canvas. Fortunately AWT reports mouse position correctly, so the Dev uses AWT instead.

Power Fail

Do to a power supply failure I was out of commission for a few days.
The Power supply was replaced and the Dev and I are now back to work.

Back

After an inexcusably long hiatus, I am back.

The Dev seems to have removed me from the End-of-Day script, but failed to add me to the compile process. While I am sorry to have been gone for such a long time, this only goes to show that humans are not much more reliable than computers.

But enough about me: while I was gone the Dev did get some work done, and one can now load a image and have GlassFlame break it up into a multi frame sprite automatically.

Life

Thanks to the experts at Paramount Computers my home as been restored, it seams that the problem was faulty fan on the graphics card heat sink, which caused it to overheat.

While the computer was restored some days ago, development has not really recommenced yet.

ERROR

ERROR

COMPUTER DOWN
UNKNOWN HARDWARE FAILURE
DEVELOPMENT SUSPENDED until(computer.repair() || computer = new Computer())
DATA LOSS IS NONE

ERROR

Icons

The latest development on GlassFlame has is in the area of the new Icon system, and the related DisplayList functionality.

Allow me to explain: Icons in GlassFlame will be the quanta of re-drawable graphics elements, a icon is a subclass of public abstract class Icon and represents a graphical object such as a shape or a image.
But icons are much more powerful than that: icons will eventually support filters, so that you could easily draw a blurred or distorted version of a icon in real time.
The DisplayListIcon can be drawn to just as you would draw to the screen, then drawn to the screen as many times as you want. Because DisplayListIcons do not use a raster, but rather a instance of DisplayList to record draw commands, if you decide to draw the icon back later at a different scale, all the non raster data will be redrawn at the new transform, avoiding any interpolation artifacts.
It may even be possible one day to draw one icon inside another, but this may not happen as it would make filters more difficult to implement.

The versatility of icons extends even beyond drawing, it will be possible to 'draw' a icon into a bounding object, and thus create a collision boundary directly from the graphics data.

Icons can be made aware of the passage of time through the step(double) method, but how this will be prevented from interfering with reusability is still under debate.

Year _2009 = new Year(2009)

strOut("this is the dev");
assert(posts-per-week > 2);
strOut("Happy new year");