Model Viewer in WebGL

As HTML5/WebGL was picking up some momentum earlier this year, I started experimenting with it, naively thinking that it would be the new standard for browser gaming. Little by little I added some code to the small project whenever I remembered it. However it has been sitting on the back burner for a few months without any update. Now that Flash 11 has been release, it's finally time to part with this little project, which could be viewed with Firefox (not guaranteed with any other browsers). External Link Here

Usage: AWSD to move the camera and mouse drag to rotate it.

How it is done:
First I found an open source linear-algebra library called glMatrix.js, which serves as the foundation to all math done here. JSON is a no-brainer for the mesh format because Javascript supports it natively. Pretty much everything else is built from scratch, for example shaders.

A few reasons that HTML5 might not be very feasible for gaming:
1. Lacks a comprehensive IDE for development such as Flash Builder, and thus
auto-completion and spelling check(in Javascript spelling something wrong is fatal)
2. Cross-browser compatibility has a huge question mark(it's still called experimental-webgl), with IE falling behind.
3. Performance concerns. Flash is compiled while Javascript is not, and how(if any) the browsers speed up this is totally up to them.
4. Javascript as a language sucks.

Added May/7/2012

Let's see how Epic's Tim Sweeney sees Adobe Flash and HTML5:

So what about the browser? That's something that relates more to something specific that you guys are working on with Unreal Engine. Where do you see the future of the browser in games?

TS: Well, we would like to see the web browser as another platform. You should be able to take any game -- a PlayStation 3 or iOS game, for example -- and just go to that and play it from any web browser.
We're slowly heading in that direction as an industry. One thing that's happened recently is Adobe Flash. For a decade or more, Adobe Flash was a little scripting language for creating more interactive webpages using a proprietary browser plug-in, but more recently Adobe created a translator.
You give it any C++ program, like Unreal Engine 3, and it translates it to a platform-independent application that can run within Flash, within any web browser or on any platform where Flash runs.

And so now any browser that supports Flash can play any web game that's built with Unreal Engine 3, or any other engine that's cross-compatible with Flash. That's an awesome breakthrough; it shows you the possibilities.

But I think the next step in that is cross-compiling games from C++ or whatever and directly running them as native HTML5 and JavaScript applications within any standard web browser. And you can do that in theory today, but it ends up being slow and unstable just because of the early state of JavaScript implementations, and limited performance, and current web browsers.
In another few years, I think that's going to be a very realistic scenario. And so the web will generally be a platform, and you can have a real application with a full feature set that runs within a web browser; that'll be very welcome. The web is a fairly awkward experience when you use a platform that's not the majority of the install base, and I think we're going to see big improvements 

Handwriting Recognition API

A while ago I was thinking of an iOS project that would utilize handwriting recognition elegantly, and thus better interacts with the user just like Professor Layton series. Then as I looked for robust algorithms that tackle this particular problem I came across this awesome open source library called Zinnia, which not only makes good use of SVM but also provides some ready-to-use training sets including Japanese. Using the library is as straightforward as follows:

recognizer = zinnia.Recognizer()
recognizer.open("C:\Python26\handwriting-ja.model")
character = zinnia.Character()
character.clear()
character.set_width(self.width)
character.set_height(self.height)
counter = 0
for curve in self.curves:
   for x, y in curve:
      character.add(counter, x, y)
   counter+=1
result = recognizer.classify(character, 10)
print unicode(result.value(0), "utf-8")

Where recognizer.open() opens the training module to compare the user mouse strokes against. Then we use set_width(), set_height() to set the canvas size, add() to add the mouse strokes as (x,y) positions. Finally we can pass the character along with the desired number of potential matches to classify(), and print out the most possible UTF-8 string with result.value(0).

Break the Language Barrier Series - Chapter Java

Recently I was asked to do some work on JNI for Java programmers to have low-level access
to the underlying systems, such as Win32 API and Cocoa Framework.
Then I ran into some interesting technologies called JNA and JInvoke, both of which claim to provide dll import for Java. However, on the official website of JInvoke they claim to be 10X faster than JNA. According to them, it compares to the performance of JNI, and even native C code's LoadLibrary from Win32 API.
Since I've been so curious about their statement, I decided to run a benchmark on all 3 approaches. To achieve this, we would create a very simple function that takes 5 input parameters and returns a sum of 5 numbers. The reason behind this is that the performance is only measurable from invoking the function and observing its overhead. So now let's take a look at all 3 implementations:

1. JNA

package com.talent;
import com.sun.jna.Library;
import com.sun.jna.Native;
public class MyJNA {
 public static int nLoops = 5000000;
 public interface CLibrary extends Library{
  int fnSpeedtest(int a, int b, int c, int d, int e);
 }
 public static void main(String[] args)
 {
  CLibrary clib = (CLibrary) Native.loadLibrary("C:/jni/Speedtest.dll", CLibrary.class);
  long startTime = System.currentTimeMillis();
  for(int i = 0 ; i < nLoops; i ++)
  {
   int sum = clib.fnSpeedtest(1, 2, 3, 4, 5);
  }
  long timeElapsed = System.currentTimeMillis() - startTime;
  System.out.println(nLoops + " Loops took JNA " + timeElapsed + " milliseconds to complete.");
 }
}

2. JInvoke

package com.talent;
import com.jinvoke.CallingConvention;
import com.jinvoke.JInvoke;
import com.jinvoke.NativeImport;
public class MyJInvoke {
 public static int nLoops = 5000000;
 @NativeImport(library="C:/jni/Speedtest.dll", convention=CallingConvention.CDECL)
 public static native int fnSpeedtest(int a, int b, int c, int d, int e);
 public static void main(String[] args)
 {
  JInvoke.initialize();
  long startTime = System.currentTimeMillis();
  for(int i = 0 ; i < nLoops; i ++)
  {
   int sum = fnSpeedtest(1,2,3,4,5);
  }
  long timeElapsed = System.currentTimeMillis() - startTime;
  System.out.println(nLoops + " Loops took JInvoke " + timeElapsed + " milliseconds to complete.");
 }
}

3. JNI

package com.talent;
import java.io.*;

class SpeedtestJNI{
 public static int nLoops = 5000000;
 static {
  try{
   System.loadLibrary("Speedtest");
                }
                catch(UnsatisfiedLinkError e){       
                 System.out.println(e.getMessage());
                 e.printStackTrace();   
                }
        }
        public static native int fnSpeedtest(int a, int b, int c, int d, int e);
        
        public static void main(String s[]){
         long startTime = System.currentTimeMillis();
         for(int i = 0 ; i < nLoops; i++)
         {
          int sum = fnSpeedtest(1,2,3,4,5);
         }
         long timeElapsed = System.currentTimeMillis() - startTime;
  System.out.println(nLoops + " Loops took JNI " + timeElapsed + " milliseconds to complete.");
        }
}

Finally the chart that compares the 3 of them:

5000000 Loops took JNA 43656 milliseconds to complete.
5000000 Loops took JInvoke 5615 milliseconds to complete.
5000000 Loops took JNI 297 milliseconds to complete.

I don't understand the nature of this performance discrepancy, but it still holds true that JInvoke is about 8 times faster than JNA. Although it's nowhere comparable to JNI, let alone pure C code. Interested readers can get the dll file here.
In the following weeks(hopefully) I will also explore the differences between C++ Interop, PInvoke, and COM Interop, when it comes to .NET calling C libraries.