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