C++: string tokenzier

This function splits a string into substrings. It uses a list of delimiter characters to find the boundaries of the substrings.

void tokenize(const std::string &str, 
              std::vector<std::string> &tokens, 
              const std::string &delimiters = " ") {
  string::size_type lastPos = str.find_first_not_of(delimiters, 0);
  string::size_type pos = str.find_first_of(delimiters, lastPos);

  while (std::string::npos != pos || std::string::npos != lastPos) {
    tokens.push_back(str.substr(lastPos, pos - lastPos));
    lastPos = str.find_first_not_of(delimiters, pos);
    pos = str.find_first_of(delimiters, lastPos);
  }
}

Usage:

vector<std::string> tokens;
tokenize("I want to tokenize this!", tokens);

tokenize("2012-02-20", tokens, "-");

Tools: Installing WebDAV support in TotalCommander 64 bit

After I switched to the 64 bit beta version of Total Commander, I noticed that I could no longer connect to my WebDAV server. The problem was the WebDAV plugin for Total Commander. It was a 32 bit version and could not be loaded into the 64 bit Commander.
The plugins page still has the 32 bit plugin for download. I think this is ok, because the 64 bit version of Total Commander is still in beta. A 64 bit plugin has already been written. You have to go to the forums and dig around a little bit to find the link.
After installling the beta plugin everything worked fine again.

Download WebDAV 64 bit plugin for Total Commander

Java Slick game development - 64 bit problems

When setting up my project and writing the simple basic application Slick crashed on me with an error:

java.lang.UnsatisfiedLinkError: Drones\lib\lwjgl.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform

I'm running Windows 7 on a 64 bit system and I have the 64 bit Java VM installed. You will not see this error if you are running the 32 bit version of Java on your 64 bit system.

To solve this problem I had to download the current version of LWJGL from their site and copy the windows DLLs and the lwjgl.jar that is included in the download into my project lib directory. This will replace the lwjgl.jar that came with the Slick distribution.

So now my project looks like this in the project explorer:

Java: Slick game development - Part #2 The first program

After setting up the project in my last post, we now create a very simple sample application that we will extent in the future.

The following code creates a new Slick game. It is not much yet - just a black window. But this window is already an OpenGL frame.

package codebrocken.drones;

import org.newdawn.slick.AppGameContainer;
import org.newdawn.slick.BasicGame;
import org.newdawn.slick.GameContainer;
import org.newdawn.slick.Graphics;
import org.newdawn.slick.SlickException;

public class Drones extends BasicGame {

 public Drones(String title) {
  super(title);
 }

 @Override
 public void render(GameContainer arg0, Graphics arg1) throws SlickException {
  // TODO Auto-generated method stub

 }

 @Override
 public void init(GameContainer arg0) throws SlickException {
  // TODO Auto-generated method stub

 }

 @Override
 public void update(GameContainer arg0, int arg1) throws SlickException {
  // TODO Auto-generated method stub

 }

 public static void main(String[] args) {
  try {
   AppGameContainer appContainer = new AppGameContainer(new Drones("Drones"));
   appContainer.start();
  } catch (SlickException e) {
   e.printStackTrace();
  }
 }
}

The class itself is derived from BasicGame, which does a lot of work for us. We just have to implement a few methods that will do our actual work later. The main method creates a new AppGameContainer and initializes it with our game.

Java: Slick game development - Part #1 Setting up Eclipse

Slick is a 2D game library for Java. It uses OpenGL for rendering. It also contains a lot of utility functions. I want to do a little bit of game programming so instead of writing my own engine (as I would do normally), this time I'm testing Slick.

Step #1: Download Slick libraries

You can get the Slick libraries here. Just download the complete package. It includes the LWJGL libraries that provide the OpenGL layer.

Step #2: Create a new Eclipse project

Create a new Java project in Eclipse and amed it Drones.Nothing fancy at this point.


Step #3: Import the libraries

I created a new lib folder, that will contain all my libraries. I copied the slick.jar and lwjgl.jar from the Slick archive into that folder. To add them to the build you have to open the properties of the project and select "Build Path". Then click "Add JARs..." and select the two JAR archives from the lib folder.


Step #4: Import the native libraries

The LWJGL library needs a native runtime library. On windows systems this is the lwjgl.dll you can find in the root folder of the Slick archive. I copied the DLL into the lib folder too. You can choose a "native" subfolder as you like.
You now have to open the "Referenced Libraries" branch in the package explorer and right click the lwjgl.jar to open its properties. In the properties dialog select "Native Library". Here you can select the "Location path" where Eclipse will look for native libraries, when it starts the application. Just select our lib directory here.
Under the hood this step sets the java.library.path property to point to the lib directory. This property defines where Java searches for native libraries.

Now you are done with setting up Eclipse. You should have a structure that looks something like this:

Tools: Total Commander and TortoiseSVN

I'm a Total Commander fanatic. It is the program, that always run when I'm working on my computer. Even when I'm not working. But recently I had a problem with TortoiseSVN and Total Commander. When you open a SVN folder in Windows Explorer Tortoise will overlay the icon according to the modification state of the contents. This way you can see if there are some modification in your folder and you need to commit them. But Total Commander would not show those icons and the context menu would not contain the SVN commands.

This problem is caused by my new machine being a 64 bit system. As this article details the 32 bit version of Total Commander cannot access the functions of the 64 bit TortoiseSVN. There are two possible solutions:

• Install both 32 and 64 bit versions of Tortoise. That should work, but I find that very ugly.
• Install the new 64 bit beta version of Total Commander. Yes it is beta, but it works.

I did the second options and am now very happy with a state of the art Total Commander and SVN support. Windows Explorer can again Rest In Peace on my computer!

C++: String trim function

This function removes leading and trailing characters from a string. The default character is a space, but you can use any combination of characters, that should be trimmed.

std::string trim(std::string &str, const std::string &trimChars = " ")
{
  std::string result = str.erase(str.find_last_not_of(trimChars) + 1);
  return result.erase(0, result.find_first_not_of(trimChars));
}

Usage:

string s = trim("Hello World!    ");
std::cout << s;
// prints: Hello World!

s = trim("xxx Hello World! xxx", "x");
std::cout << s;
// prints: Hello World!

webOS: Detecting Enyo on phones

With the trojan horse maps update for all webOS devices, every device has the option of running Enyo applications. Which is great, but how can you determine whether the user has updated his phone or not?

Arthur Thornton posted a very nice solution in the webOS developer forums.

In the likely situation that no update to older devices is pushed out including enyo, here is a solution...it isn't pretty, but it will get the job done.

The very first thing you need to do is mention in your app description that your app requires "updated system software" included in the Maps app. This way, the users should know to expect this as a requirement, and even though many users don't read the description (grr...) you're still covered by mentioning this.

Then use the following code in your app:

index.html

Code:
<!doctype html>
<html>
  <head>
    <title></title>
    <meta name="viewport" content="height=device-height" />
    <script src="C:\Program Files (x86)\HP webOS\SDK\share\framework\enyo\1.0\framework\enyo.js" type="text/javascript"></script>
  </head>
  <body>
    <script type="text/javascript">
      if (typeof enyo == "undefined")
        window.location = "./requiresEnyo.html";
      else
        new MyApp().renderInto(document.body);
    </script>
  </body>
</html>

requiresEnyo.html

Code:
<!doctype html>
<html>
  <head>
    <title>Install Maps and Enyo</title>
    <meta name="viewport" content="height=device-height" />
    <script src="/usr/palm/frameworks/mojo/mojo.js" type="text/javascript" x-mojo-version="1" />
  </head>
  <body>
    <div style="padding: 5px">
      Attention: This application requires an updated version of the system software which is not available on your phone. To install this updated software, you must install the updated Maps app by tapping the below button (will open the App Catalog):
    </div>
    <div class="palm-button" onclick="installEnyo()">Install</div>
    <script>
      window.onload = function() {
        PalmSystem.stageReady(); // required for page to load
      };
      function installEnyo() {
        window.location = "http://developer.palm.com/appredirect/?packageid=com.palm.app.maps";
      }
    </script>
  </body>
</html>

Note that this loads Mojo (which will obviously be on the device) in a separate HTML file *if* enyo isn't already on the device (i.e. a Pre2). This was tested to work on my Pre2.

Also note that to put enyo in your app, your users must be using webOS 1.4.5 or newer because the maps app has a minimum webOS version of 1.4.5 (and thus, users prior to 1.4.5 won't see it in the Catalog and won't be able to update) due to (I'm assuming) using the version 2.0 packaging format.

If you have your app currently deployed to users running webOS versions prior to 1.4.5, you will have to retain a Mojo version in it (because the app can still be updated even if you change minimum OS version to 1.4.5 unless changes have recently gone into effect to fix that; this doesn't cause issues for the Maps app because technically, that app is not update-capable on devices prior to the Pre3 without the workaround they came up with).

Arthur Thornton
webOS Application Engineer
Appstuh