406 Not Acceptable

As you may, or may not know, J2ME does not support the ArrayList functionality of standard Java. In addition, as J2ME is based on Java 1.3 it does not feature generics. This means as a developer you are stuck with a choice of using arrays or vectors. Now arrays are fast, but you are stuck with the initial size and a number of other issues. These are things you really do not want to be messing around with, unless speed is of the highest priority.

Whilst Vectors are dynamic, they bring about one annoying issue – you have to cast each entry back from an Object type to its original type on retrieval. This takes up a lot of processor cycles, and on phones processor cycles are a limited commodity. Secondly, you will have to use the Vector enumerator to iterate through your vectors. This is very processor intensive, in NaStar I found this was using around 30% of my cycles! Finally Vectors are synchronised, this means they are thread safe. Now a synchronised collection is much slower than an unsynchonised one; plus, you will most likely not need the safety benefits synchronisation brings. As you will usually be using one thread for acessing your collections in a game (in the main game loop.)

Now the J2ME Polish project gives you the chance to use some Java 1.5 features, most importantly generics are included. Second, an arraylist implementation is included, which uses generics. However, many people have had issues with integrating this plugin to their chosen IDE. I have worked out some fixes for Netbeans J2ME Polish integration, but when coding my project decided against using the tools.

So you now find yourself stuck between no generics, slow vectors, or fixing (and maintaining) a plugin.

If all you want is access to ArrayLists or generics, your best bet is to strip the ArrayList code from J2ME Polish and create your own lists. I guess you could simply find an implementation of ArrayList floating around on the web, but the J2ME Polish code is very good. You will then simply create a number of new ArrayList classes, such as SpriteList, EnemyList, et al. There will be two other classes that the ArrayList depends on, you should also clone these for each implementation; these will let you use for each loops! Let each list only deal with one defined type. Now you will no longer have to deal with Vectors and their iterators and will find your game runs a lot faster! I found around 20 – 60% of processor time was dealing with Iterators; whilst ArrayLists cut this down to under 10%. For my project this was the best performance tweak available.

Before anyone asks, no you can’t play my game! Sadly the rights are held by the University of Birmingham Whilst I doubt they care much about a J2Me game!

I am going to show a basic exclusion collision algorithm for J2ME. Whilst the Sprite class has collision detection methods, they are not very flexible and are useless when checking how objects collide. For example, in a bat and ball game you probably will want to know which edge the ball collides with in order to bet the ball to bounce correctly.

Exclusion collision detection is done by checking where certain parts of the two items are in correspondence to each other. Basically if the highest point of item A is lower than the lowest part of item B, it is not possible for the items to collide.

In addition, you can order your method based on which direction you are expecting collisions to usually occur from. This will then be more efficient than even the box detection method offered by the Sprite class.

public boolean collisionBetween(Sprite a, Sprite b)

{

if (a.getY() > (b.getY() + b.getHeight()))
{
//Not collided b is above a

return false;
}
else
{
if ((a.getY() + a.getHeight()) < b.getY())
{
//Not collided b is below a

return false;
}
else
{
if (a.getX() > (b.getY() + b.getWidth()))
{
//Not collided b is to the left of a

return false;
}
else
{
if ((a.getX() + a.getWidth()) < b.getX())
{
//Not collided b is to the right of a

return false;
}
}
}
}

//There is a collision

return true;

}
There might be a parenthesis error in here, as I did this in notepad at work. So I couldn’t check the syntax! From the formatting — which Wordpress kindly destroyed — it looks fine though.

I’ve decided that it would be best to me to hold back any articles on J2Me until after I have finished my project. I am not doing this because I do not have the time, but instead for plagiarism purposes. After all I would be posting code from my project onto this site and that may flag up on some plagiarism detection program and give me some serious hassle. The bigger issue is if anyone steals the content from this site (unlikely) and that gets picked up… then I’d have even more hassle to deal with.

Anyway, expect this stuff in September/October. I’ll have a few articles written ready for when I finish the project.

What’s really annoying is that some people get an extra 4 days to do their coding… that’s not what I’d be calling fair…

J2ME Polish is a really neat package for J2ME programming. Really all I want it for is to change all my annoying Vectors into ArrayLists for speed. Now there are a few issues with the integration plugin on both Windows and Linux when using Netbeans. Heck it doesn’t even work properly on Netbeans 5.5, never mind Netbeans 6, 6.1, or 6.5…

Now what’s the only thing better than a poor integration plugin? No support, that’s what! A quick check on the J2ME Polish forums and you will find numerous posts asking how to fix these errors. So if you’ve tried going to the forums and had no luck (like everyone else,) you’ve come to the right place.

So here are a list of the problems and how to fix them.

 When starting NetBeans it prompts you with a message that states “org.netbeans.modules.java.platform/1 >1.10 required version found 1.9.2″(Or some other version) with options “Disable and continue or Exit”.

This one’s an annoying one, which occurs every now and again. I got this on 6.0 on Linux and 5.5 on Windows, but not with 6.5 on Windows. So how do you fix it?

Go to:

/usr/share/netbeans/platform7/modules

or in Windows (x being a version number)

Program Files\NetBeans 6.x\nb6.x\modules

If you can’t find this folder just search for  “de-enough-polish-netbeans.jar” as this is the file you need to edit. Open up “de-enough-polish-netbeans.jar” with a zip program (Winrar, rileroller, Winzip, etc) and edit the file at META-INF/MANIFEST.MF wih a text editor (notepad.) There will be a sentence that states:

org.netbeans.modules.java.platform/1 > 1.10

Change it to

org.netbeans.modules.java.platform/1 > 1.0

Reactivate the plugin in Netbeans and enjoy!

You are prompted to resolve reference problems relating to “Emulator Platform” or “SUN WTK 2.2 etc…” not being found.

This occurs to everyone…

Go to your an existing (non polish) project folder and open the folder nbproject. There should be a file called project.properties, open this with a text editor. Scroll down and there should be two lines stating:

platform.active=Sun_Java_TM__Wireless_Toolkit_2_5_2_for_CLDC
platform.active.description=Sun Java(TM) Wireless Toolkit 2.5.2 for CLDC

The versions may be different, as you may have a later Wireless Toolkit!

Now open the same file in your J2ME Polish project and replace the platform.active and platform.active.description lines with the ones from the non polish project.

Replace every occurance of “MPowerPlayer” with Sun_Java_TM__Wireless_Toolkit_2_5_2_for_CLDC (or what you had in your old project.)

Replace every occurance of “Emulator Platform” with Sun Java(TM) Wireless Toolkit 2.5.2 for CLDC  (or what you had in your old project.)

Close Netbeans and reopen and all should be fixed!

Well so far, anyhow it’s time to celebrate! Well, somewhat… I’ve got a project to do!

Over the summer (read till October,) I’ll be busy working on my project; hopefully it won’t mean a massive lack of activity like my exams caused. In fact I should be able to write up some tips on using J2Me as I go along. I am rather lucky as I managed to persuade my supervisor to let me develop a game using J2Me, which should be lots of fun to make and test

I have noticed that although there are a few good sites, tutorials, and guides on developing games for J2Me; there is a distinct lack of help on how to use the Visual Game Designer and Visual Map Designer features that were introduced with Netbeans 6.0. (Correct me if I am wrong, but they weren’t in Netbeans 5.5.) Because these tools haven’t been around very long there is also a lack of books covering them. The only real useful information about using them is the sample ‘game’ included in the Netbeans Mobility pack. So when I get the time I’ll provide a guide on using these tools for a simple ‘game’.

In addition, I should be able to host the odd version of the game. As it will need testing on multiple devices and I can’t just go out and buy a load of phones! Of course the emulators are useful, but there are situations where the device can act differently. I’ve noticed this being the case when using JSR-226: The 2D Vector Graphics API. Annoying really as Vectors can be a great tool for mobile games. With their being a number of resolutions to work with vectors have a great advantage over sprites, but with the low implementation of JSR-226 in devices, I’ll be overlooking them.

Back to beer!

Is not very productive. So far we’ve fixed 4 bugs, ate pizza, broke it, fixed it, one of us went to the gym, others slept, ate more crisps,  messed about by stealing monitors and keyboards to make the eee pc into a desktop,  did some overclocking, thought about java, and sulked over the lack of a kettle. So all in all a good use of time!

The group project is nearing the deadline and the coding side of the work seems to be complete (bar the guaranteed major bug.) I’ll be pulling another all-nighter tomorrow to help finish off the testing and written work.

After numerous last minute revisions to the protocol and the server everything back working again! Loving it when someone recodes the server, client, or protocol then comes up to you and says: “By the way, your Gui is broke.” Really? It was working when I updated and went to bed >:( Perhaps that has happened too many times in the last 5 days for me to care anymore…

Since I am knacked, heres a lovely (Java ish related) comic from xkcd to keep you entertained:

After installing Netbeans 6 RC 1 I never really turned back to Netbeans 5.5.1, Netbeans 6 enabled me to be far more productive when coding. The highlighting, searching, and better auto commenting features were enough to make me delete Netbeans 5. Especially after the RC was stable enough to work with. Now Netbeans 6.1 beta 2 has recently appeared, it seems I missed out on having a look at beta 1. At least that means I get to test a more stable IDE.

Now the one huge difference with Netbeans 6.1 is the start up speed. It is almost instant, well in Netbeans terms anyway. On my home system — without any tweaks to the IDE — it loads up my last project in just under 10 seconds. Now you probably want to now how long Netbeans 6 takes, well that takes… 17 seconds (yes, I did just count.) So, for me at least, Sun aren’t making things up about the increased speed of the program.

According to Sun:

• Faster cold start and improved startup sequence. Up to 40% faster (with a project opened). Opening projects does not block startup. Go to Type dialog available even during post-startup scanning of sources.
• Various optimizations to reduce I/O and file access (touching disk), improving responsiveness in many situations, especially on slower filesystems (e.g. on network).
• Incremental parsing in java editor speeding up code completion and improving responsiveness of the editor especially with large files (see below).
• Improvements in JSP parser (caching, memory management, update strategies), leading to faster code completion and editor.
• Improvements in Visual Web designer — faster page opening and table drop, lower memory usage, fixed memory leaks, and more (see below).

It seems this major speed improvement is new to beta 2, so if you’re still stuck on beta 1 you might want to change.

There’s also some nice eye candy in there, it seems everyones on the transparency train these days!

I’ve only had one hiccup with the IDE so far, a button just wouldn’t delete in my Gui when using Matisse. I kept getting a little warning light about an error, so I happily submitted the problem. I ended up just tossing the button out of my gui as just one more ‘other component’ (the Netbeans equivalent of tossing it overboard!)

Coding a breadth first traversal is more complex than a depth first traversal (left to right, or right to left.) Although, the code behind the traversal is not much longer or complex, it just requires a bit of thinking. Source code for the breadth first traversal is at the bottom of the post, alongside source code for the more common depth traversal.

I’ve found that there are little examples – online or in books – of how to do a breadth first traversal, especially for Java. I had to teach myself this from a not too friendly C++ example. I’ll try to explain the basic idea of the traversal, before moving on to the code. I hope for your sake that I can actually explain this…

Suppose you have the following tree:

 Now if you were to run a depth traversal you would go in the following order:

1,2,3,4,5,6,7

As the traversal would go to the left most node, then get the root node of that node, then attempt to try this on the right node. As such:

I know, not the greatest of diagrams… that probably just confused you. The red numbers and arrows correspond to the order in which the traversal works. It will go all the way to the left, before going right; this is probably good in the case above, but sometimes you want to get all the values at a certain depth before moving to the next depth (alternatively see this as getting numbers across the breadth of the tree.) For example, if a tutor asked you to get the numbers in order of how close to the root of the tree they were. A normal traversal would not be able to do this, thus you would have to do a breadth first traversal in order to answer the question. Another good example would be searching for a closest ancestor of two people, a basic depth first traversal may get the correct answer on many occasions; however, it would give erroneous answers with more complex trees. If a breadth first traversal was used it would always give the correct answer.

For example, on the tree above a breadth first traversal would give the result:

4,2,6,1,3,5,7

As you can see the numbers are placed in order of their depth, 4 is the root of the whole tree, 2 and 6 are the subnodes of 4. Then finally you get the subnodes of the subnodes (1,3,5, and 7.)

In order to do such a traversal you will need to have two methods and a queue. The first method deals with the root and its subnodes and the second method will deal with all other nodes.

Basically you should dump the subnodes into the queue, then remove one from the queue and repeat the process. The code does a good job in explaining this.

 Now for the code, full source code is available at the bottom of this post.

Basic Traversal

/**
* Simply runs a basic left then right traversal.
*/

public void basicTraversal()
{
//Check if we can go left
if (left != null)
{
left.basicTraversal();
}

//Add the root
list.add(root);

//Check if we can go right
if (right != null)
{
right.basicTraversal();
}
}

Breadth traversal

  /**
* Runs a breadth first traversal
* This method runs once to get the root and it’s subnodes, then runs
* another method to continue the traversal
*
* @param list ArrayList to store the roots in
* @return ArrayList of type Integer
*/
public ArrayList<Integer> getBreadthTraversal(ArrayList<Integer> list)
{

//Add the root to the arraylist, we know it is always the first entry.
list.add(root);

//Basically we add the first set of nodes into the queue for
//traversing.

//Query if left exists
if (left != null)
{
//Then add the node into the tree for traversing later
queue.add(left);
}
//Same for right
if (right != null)
{
queue.add(right);
}

//Then we call the traverse method to do the rest of the work
return traverse(list);
}

/**
* Called by getBreadthTraversal, this should not be ran without it.
*
* This method completes the breadth first traversal. It will remove the
* first Tree from the queue and add their nodes (left and right)
* to the back of the queue. Then it will append the Tree to the
* ArrayList for returning.
*
*
* @param list ArrayList to list tree roots in
* @return list ArrayList
*/
private ArrayList<Integer> traverse(ArrayList<Integer> list)
{
//Keep traversing until we run out of people
while (!queue.isEmpty())
{
/**
* We take one from the queue.
* As a linked list is a queue it operates as “First In First Out”
* also known as FIFO. So if you add something to a queue you have
* to wait until all other objects are removed before you can
* access the object again.
*/
Tree p = queue.remove();

//Check if it has any subnodes
if (p.left != null)
{
//Add the subnode to the back of the queue
queue.add(p.left);
}

//Same for left
if (p.right != null)
{
//Same here, no queue jumping!
queue.add(p.right);
}

//Append to the ArrayList
list.add(p.root);
}

//And return
return list;
}

Tree example source code

I randomly found this picture yesterday and it really describes how things are going in the group project I am involved in.

You leave the discussions from the last day thinking “Everything is all sorted, and I know how we are going to implement things.” The next day the discussion revolves around the same task after someone suggests an alternate method, yet there was nothing wrong with the first method, in fact both methods are of equal merit. However the group discusses the same thing again and again, and I just want to get round to coding the damn thing.

I’ve ended up just writing the code myself, based on one of the numerous choices, screw discussing it further we have a deadline to meet! All that matters to me now is getting the input and the output working as they should; once the program is up and running then — and only then — should we worry about refining it with more efficient methods of doing components. For example in multi threading we could use manual locks, shifting synchronized methods into their own classes, volatile methods, and so on; they all do the same thing in different ways, lets just use one, or even go for a Taguchi methodology and try two, in a prototype and see how things go. I’d rather spend my time working on a few simple prototypes (that can be utilised for the final build) that highlight the problems than spending the same time (or even longer) discussing which is best…

This post is going on for too long, rant over…