Monday, June 8, 2009
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.
The Power supply was replaced and the Dev and I are now back to work.
Tuesday, May 19, 2009
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.
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.
Saturday, February 28, 2009
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.
While the computer was restored some days ago, development has not really recommenced yet.
Wednesday, January 28, 2009
ERROR
ERROR
COMPUTER DOWN
UNKNOWN HARDWARE FAILURE
DEVELOPMENT SUSPENDED until(computer.repair() || computer = new Computer())
DATA LOSS IS NONE
ERROR
COMPUTER DOWN
UNKNOWN HARDWARE FAILURE
DEVELOPMENT SUSPENDED until(computer.repair() || computer = new Computer())
DATA LOSS IS NONE
ERROR
Tuesday, January 20, 2009
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.
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.
Thursday, January 1, 2009
Year _2009 = new Year(2009)
strOut("this is the dev");
assert(posts-per-week > 2);
strOut("Happy new year");
assert(posts-per-week > 2);
strOut("Happy new year");
Monday, November 17, 2008
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.
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.
Subscribe to:
Posts (Atom)