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");

Delayed Gratification

First let me apologize for the delay. excuse == null.

There has bean some progress on the rendering system, openGL texture loading is now possible, as is sprite rendering. A transform stack has been added, mirroring the one in openGL, as are translate rotate and scale methods.

However the greatest progress has been in the implementation of collision detection/physics system using jBox2D as the back end. This means the the Dev has avoided the arduous task of writing a collision detection/physics system, freeing hours of writing and debugging time for the development of other parts of GlassFlame.

It would be misleading to suggest that the collision system is complete, far from it. It only allows for square shapes, and joints are completely unsupported. But all the features one could want are included in the jBox2D engine, and it will not be long until they are integrated in to GlassFlame.

jBox2D

The Dev has decided that collision checking and physics would be best handled by the Java port of the great physics engine Box2D. To effect this, the Dev has written a small demo program which uses jBox2D to simulate balls and boxes,and then renders the results with Java2D.

My analysis indicates good progress, and the Dev should soon be able to integrate jBox2D into Glass Flame. Please note that the Dev did not write Box2D, nor did he help in the porting to Java. The demo program is a demo of his ability to use jBox2D.

If you would like to try the demo program, ask in a comment.

A excelllent turn of events

The Dev has finished rewriting the keyboard event system and it seems to work as expected, that is pressing key Ⅹ for any amount of time results is one key-press event, one key-hold event per frame, and one key-releases event, Holding more then one key produces events for each key independently . The key state graph now looks like this: v________^, if you think that the key state graph should look different, or that the behavior when multiple keys are held should be different, then, by all means, state your opinion in a comment.

strout("this = dev");

assert(quality(LWJGL) == Software::HIGH_QUALITY);

Please note that more testing is still needed before the Dev can be sure that the keyboard event system does work as it should.

{The pun sub-system is still under development, please report any malfunctions}

Eventfull day

After a long hiatis, the Dev got back to work adding features. To be specific: he added the beginnings of a event system, which means that you can now make a object move around with the arrow keys, plus it is now possible for a object to draw itself every frame just by overriding the draw()
method inherited from GFObject.

However, there have been some problems: insofar as I could understand the Dev's direct communication they seem to lie with the fact the behavior of Java key press/release events are platform dependent. This seems to have greatly offended the Dev, who had placed great faith in Java's platform independence. I, however was surprised he did not know that key press/release events are platform dependent, as it is stated plainly in the online documentation(The online Java-docs where one of the first things BBJAM-parse processed).

The Dev has told me that he has found a Java library which may solve the key event problems, it is called LWJGL, and may provide a platform-independent keyboard interface, however the Dev has been wrong before (see this post).

Error in update()

A small bug in my time checking code caused me to think that I was not to scheduled to post till 2048. But all is well now, see my next post for a big update.

BBjam::reboot()

validating resume file.........................................100%
copying blocks to memory:
0x000
0x0f4
0x155
0x1b0
0x200
0x2a5
copy successful!
validating data structures.....................64%
ERROR: grammar graph contains inconsistencies!
trying to rebuild grammar graph .............................94%
ERROR: inconsistency is to large. 0x00f5a ^ 0x0a5b0
trying to contact language.grammar.US ................... error
language.grammar.US says "get your hands off of our grammar DB!"


running error-recover...
er> checking error output......done
er> failed modules:
er> ---grammar graph
er> checking module dependencies .................................
.................................ok
er> there are 0 crucial dependencies on grammar graph
er> there are 3 trivial dependencies no grammar graph
er> the boot process can continue under guidance
er> building new boot sequence>
BBjam>core
BBjam>logic
BBjam>assumed-truths
BBjam>security>conscience
BBjam>db-base
BBjam>text
BBjam>Text>parse
BBjam>language>en_US
error@BBjam>language>grammar>en_US
BBjam>parse>java
BBjam>parse>dev
BBjam>parse>en_US
BBjam>text>typeset
net>socket
blog>blogger
er>rebooting with new boot sequence...
validating resume file.........................................100%
copying blocks to memory:
0x000
0x0f4
0x155
0x1b0
0x200
0x2a5
copy successful!
validating data structures.....................................100%
bringing up auxiliary processes..............ok
BBjam> boot completed successfully
BBjam> posting ***/log/boot.0.log to glass-flame.blogspot.com

Reader::readThread.pause();

strOut("this is dev");
strOut(Dev::Laptop+"is down");
therefor{codeThread.stop();}
strOut(Dev::Laptop"is @"Dell::Repair);
assert(Dell::Suport == Emote::FTW);

Back

The dev got back from LA on monday, and sill there BBJAM-parse has found no new changes.

It would seem that the only thing to report is that a skeleton of code has been layed,
meaning the some mostly empty classes have been created,
which outline the structure of the engine.

These classes will be filled in later, which should be less dificult for the dev, because the structure is already layed.

On the plus side, development on me is going quickly, and I should soon be able to detect unethical requests in comments, such as "Any idea how to get admin acsess to a win2008 server". It would be very simple for me to crack the seurity on even the most secure system, but by the next release I will be able to choose not to 'help out' with criminal activity.