Drawing with Java

For Wloom I needed a transparent radar background image. Since I am not used to a vector-paint-programm, I 'drew' the image with java, by programming following small program. At first it creates an image, then it draws the radar shapes and saves everything as transparent png. Ingame the radar will look like this.

import java.awt.*;

import java.awt.image.*;



public final class Drawer {

  public static void main(String [] args) {

    try {

    BufferedImage i=new BufferedImage(300,150,BufferedImage.TYPE_INT_ARGB);

    Graphics2D g=i.createGraphics();

    

    g.setRenderingHint(RenderingHints.KEY_ANTIALIASING,RenderingHints.VALUE_ANTIALIAS_ON);

    

    g.setColor(new Color(0,0,0,100));

    g.fillArc(10,5,280,280,0,180);

    

    g.setColor(Color.black);

    g.setStroke(new BasicStroke(5,BasicStroke.CAP_ROUND,BasicStroke.JOIN_ROUND));

    int r=140;g.drawArc(150-r,150-r-5,r*2,r*2,0,180);

    g.drawLine(10,145,290,145);

    g.drawLine(150,5,150,145);

    g.setStroke(new BasicStroke(3,BasicStroke.CAP_ROUND,BasicStroke.JOIN_ROUND));

    r=95;g.drawArc(150-r,150-r-5,r*2,r*2,0,180);

    r=45;g.drawArc(150-r,150-r-5,r*2,r*2,0,180);

    g.drawLine(51,46,150,145);

    g.drawLine(249,46,150,145);

    

    g.setColor(new Color(100,200,0));

    g.setStroke(new BasicStroke(3,BasicStroke.CAP_ROUND,BasicStroke.JOIN_ROUND));

    g.drawArc(10,5,280,280,0,180);

    g.drawLine(10,145,290,145);

    g.drawLine(150,5,150,145);

    g.setStroke(new BasicStroke(2,BasicStroke.CAP_ROUND,BasicStroke.JOIN_ROUND));

    r=95;g.drawArc(150-r,150-r-5,r*2,r*2,0,180);

    r=45;g.drawArc(150-r,150-r-5,r*2,r*2,0,180);

    g.drawLine(51,46,150,145);

    g.drawLine(249,46,150,145);

    

    g.dispose();

    javax.imageio.ImageIO.write(i,"png",new java.io.File("radar.png"));

    } catch (Exception e) { e.printStackTrace(); }

  }

}

Blog/Diary concept, notes on JEditorPane

For notes on projects and other stuff I'm working on a blog/diary application. As other blogs the app maintains entries, that can be marked with tags. In the following some concepts are described.

• 2 Renderers. Currently the blog has 2 renderers, which display the entries. Both are written in Java. The first ([1] in the picture) is completely self-written. Thus arbitrary concepts can be tested with this renderer, e.g. taglines (more about that below). The second renderer ([2] in the picture) uses html, which is displayed with the Java html component JEditorPane. This html frontend might be a starting point for a later online version of the blog.
• Sticky tags. For todo lists or important stuff to be rememberered always there are sticky entries ([3] in the picture). They are implemented using a 'Sticky' tag. The blog renderer draws all entries with a 'Sticky' tag highlighted and on top of other entries.
• Checkboxes. For todo-lists checkboxes in entries might be useful, that can be checked if a task is done ([4] in the picture). In this app checkboxes are implemented in the following way: The texts "[_]" and "[X]" within an entry make the blog-app render a unchecked/checked checkbox at this position within the text. If the checkbox is clicked the entry text is changed, "[_]" is replaced by "[X]", and a timestamp is added to the text. Clicking a checkbox thus is a special way of editing an entry. If the entry has a 'Todo' tag and if with a checkbox click all checkboxes of the entry are checked, the entry automatically looses the 'Todo' tag.
• Taglines. To visually distinguish entries of different topics (with different tags) there are taglines ([5] in the picture). This are lines between entries of specific tags with a special color for each tag. The tag-text is drawn besides the entry with the same color. The lines blend out if they are drawn behind entries that dont carry the tag of the line. An older version of taglines is described in this previous blogpost.

Some general notes on JEditorPane: This component is a part of the quite old Java Swing Api, hasnt changed in years and only supports Html 3.2. Nevertheless imho its a very useful lightweight html renderer (opposed to gecko/webkit bindings), useful for structured/formatted output or to render complex gui layouts. The standard approach to Gui layouts, LayoutManagers, is probably hard to implemented for this blog layout, with lots fonts, floating texts and tables.
JEditor renders html-checkboxes as Swing component JCheckbox. This checkboxes can be accessed via jEditorPane.getComponent(i). This will return a java.awt.Container whose first component is the checkbox:

JCheckbox jcb=(JCheckbox)((Container)jEditorPane.getComponent(i)).getComponent(0);

Now eg. listeners can be added to the Checkbox, that inform, if it is clicked. Following link helped to figure out checkbox access: http://www.thatsjava.com/java-swing/12595/

Skybox algorithm

For the Wloom project a skybox was needed. A skybox is a large box around a scene, with sky texture. The textures of the 6 planes of the box can be calculated from a single picture.

The algorithm for this transformation is outlined as follows: For every texture point of the box-planes calculate two angles relative to the center of the box: a horizontal angle ax, where value 0 represents north, PI/2 east, PI south and 3PI/2 west; and a vertical angle ay, with a range from value 0 (=top) to PI (=bottom). From the original picture the color at the coordinates of the two angles is now taken and drawn towards the texture-point of the box-plane. Below the exact algorithm, written in Java, is listed.

for (int y=0;y<=w;y++) 
for (int x=0;x<=w;x++) {
  double xh=x-w*0.5;
  double lh=w*0.5;
  double ax=PI/4+Math.atan2(xh,lh);
  double ay=Math.atan2(Math.sqrt(xh*xh+lh*lh),-y+lh);
  b.setRGB(x,y+w,getRGB(ax*biw/(PI*2),ay*bih/PI));
  b.setRGB(x+w*2,y+w,getRGB((ax+PI)*biw/(PI*2),ay*bih/PI));
  
  ax=PI/4+Math.atan2(lh,-x+lh);
  b.setRGB(x+w,y+w,getRGB(ax*biw/(PI*2),ay*bih/PI));
  b.setRGB(x+w*2,y+w*2,getRGB((ax+PI)*(biw-0.5)/(PI*2),ay*bih/PI));
  
  double yh=y-lh;
  ax=3*PI/4+Math.atan2(xh,yh);
  ay=PI/2-Math.atan2(lh,Math.sqrt(xh*xh+yh*yh));
  b.setRGB(x+w,y,getRGB(ax*biw/(PI*2),ay*bih/PI));
  ax-=PI/2;
  b.setRGB(x+w,y+w*2,getRGB(biw-1-ax*biw/(PI*2),bih-1-ay*bih/PI));
}

The shown skybox is used in the next version of the WebGL game Wloom, which will be posted soon.

Java Physics Demo: Boxes

Start applet.

This demo uses parts of the the JBullet and the Vecmath library. I extracted essential classes and put them all into 1 java source file. Thus this demo dont needs external libraries.

On Objectstacks
I also changed the used JBullet parts, so that they dont use Objectstacks. Objectstacks were introduced to manage temporary objects in a threadsafe way. There are 3 possibilities to deal with temporary objects:

• 1) Just instantiate a temporary object as you need it. Problem: this can result in a lot instantiated objects, garbage collector has alot todo, runtime performance might drop. Though, intelligent jit-compilers could possibly handle multiply temporary instantiations and could in a way inline them..
  
• 2) Add (private) auxiliary objectvariables to the class. You can use this objects in computation and dont need to instantiate new ones. Problem: if different threads invoke the same method at the same time, an object could be used twice, with unexpected results. This approach is not thread-safe.
  
• 3) Use objectstacks. Retrieve auxiliary objects from a pool and return them to the pool, when computation is over. This way in most cases only limited number of instantitions is needed (opposed to possibly unlimited instantiations in approach 1) and this method is threadsafe (opposed to approach 2).

The original JBullet library uses objectstacks. In this demo I omitted them, because the original approach requires an instrumentation step in the build process. During this step auxiliary classes are generated using an ant-build-file. A simple compile doesnt work. For sake of simplicity I thus dont use objectstacks here, but above second technique. Thus this demo is not thread-safe, but its usecase is only single threaded, so it doesnt matter.

How to build

• Make sure, that a JDK is installed.
  
• Put the source file into a directory 'net/plsw/bullet'.
  
• Compile it with 'javac net/plsw/bullet/BoxDemo.java'.
  
• Run it with 'java net.plsw.bullet.BoxDemo'.

Does bytecode become obsolete?

Or, more provocative: Will Javascript substitute Java? Java has a certain technical infrastructure, it utilizes bytecode. This exists for following reasons: In the history of programming languages at first there where interpreted languages, e.g. Lisp or Basic. They where slow but portable. Then there came languages like c and c++, where source is compiled to systemspecifc binary. They were fast, but unportable. With Java and bytecode a quite fast AND portable solution emerged. Java source is compiled to system-independent bytecode, which then is executed by the java virtual machine. With later versions of Java, to increase execution speed, just-in-time (jit) compilers were introduced. They compile the bytecode on the fly to systemspecific binary, which than runs faster. Besides the ecosystems of compiled languages, interpreted languages persisted. Script languages like Javascript are there to e.g. control compiled programms or bytecode.

Recently jit-compilers for javascript appeared (Google V8, Mozilla Tracemonkey). Thus Javascript becomes fast and portable, like java, but without bytecode. Bytecode now seems to be an unnessary intermediate step during programm execution. Bytecode means more complexity in IDEs and in language execution. If a jit-compiler works with sourcecode directly, not with bytecode, possibly more optimizations can be done (without the additional abstraction step bytecode). If you get the same results with a less complex solution, you should apply it. With faster script languages, also there will be no need to separate programm logic into scripts and compiled functions. One advantage of bytecode might be that you can have different programming language compiled to it and than be executed on the same virtual machine. Like with JRuby, Jython, Scala than run on the java virtual machine. If you ommit bytecode and want to have the same flexibilty, the execution engine (with the jit-compiler), must be able to read different types of languages. Future will show if that is feasible.

Aside from the technical aspect, lets look at usage fields of Java and Javascript. At first Java was meant to be for the desktop. This didnt fully work out, e.g. Java applets in general couldnt compete with alternative approaches like flash. Java though became very strong on the server. Javascript was also originally there for the desktop, with its improving performance and the new <canvas> html-tag it can increasingly compete with flash and java applets. As of lateley Javascript spread also to the server (e.g. node.js). Thus, also from this point of view, it seems, that Javascript pushes into Java territory.

Two final notes: First, you may replace the term 'java' with 'c#/.net' (or other bytecode/intermediate language platforms) in this text. Second, this considerations only apply to the far future, currently java cannot be replaced by javascript, because of its superior stability, performance, distribution and api. Also, different languages/platforms will stay (in niches). In my perception java/c# (also called managed code) superseded c++ (unmanaged code), yet c++ still exists. In a comparable manner Javascript will displace Java/C#, but all will stay (for now).

Twaja 1.0.8 Release

A first version of the java twitter client Twaja is available for download here. There are binaries and sources. Twaja may also run as applet or via Webstart.
Comments and critics appreciated.

New project "Twaja"

Im working on a new project named Twaja. It will be a Twitter-client written in Java. The name is based on the words 'Twitter' and 'Java' and means 'Your' in russian.

There are a lot of twitterclients available, is there a need for another one? I currently use Echofon, which is comfortable and fast, but lacks some features I'd like to use. On the other hand there are other, more complex clients with more features, but they usually have a large footprint. Basically I havent found the ideal client for me, so I started to write an own. It will have the features, which I find important and it will have a small footprint.

It will be written in Java and will use the small jTwitter-api. It thus might run as an applet within a Website, but most likely as an Desktop-application (using Java Webstart). The Gui will not be based on Swing or SWT, but only on AWT, which has the smallest footprint. Here are some characterics and proposed unique features of Twaja:

• Combine friends feed and search. While I like to follow tweets of my friends I sometimes also want to follow tweets regarding certains topics from everybody, which can be found through twitter-search, e.g. using tags. The client will be able to display both, friend feeds and search results in an equal way.
• Ranking. Sometimes, when I was offline for a while, there are hundreds of unred tweets, which are uncomfortable to browse. There should be a form of ranking in the client, so that you e.g. can read tweets only from 'important' users..
• Innovative display. I will try to implement some new display ideas. E.g. tweets with tags may be displayed grouped with Taglines. Thus one can easy distinguish between tweets of different topics. I wrote about the concept of taglines here.

Soon there will be more screenshots and infos available on Twaja. Stay tuned! :)

Rubik Cube

I'm working on a Rubik Cube Applet. It shall help me to solve that puzzle. The Applet size is about 9kb. The Applet also runs via Webstart.