The Web has taken us Backwards

But how can this be? The Web is the greatest thing thats ever happened to humanity… is it not? First off, I would climbing down out the tree’s probably ranks as one of the best (and one of the worst) things we’ve done as a species, the web hardly comes close to that. That said, the title of this post says it’s taken us backwards, and in a way it has. When Microsoft brought out DOS (and later windows), together with IBM (and later Intel), they introduced the masses to computing. Before that computers had mostly been Mainframe terminals and such. Even as PC’s were taking their foothold in the minds of the human population, Mainframes were still the order of the day within large companies with lots of money to loose. Mainframes constituted (and often worked with and within) very large data-centers.

How does a stupid-old; slow-and-clunky; text-only mainframe relate to the web. Simple.

Your browser is nothing more than a modernized mainframe terminal.

When you use Google Documents; Gmail; Hotmail; Yahoo Mail; Google Spreadsheets; WordPress; (insert other web systems here); the data is stored in a huge big data-center, and the software is running on some enormous server-farm (and in the case of a Web 2 application, they farm a chunk of the work out to your browser). So you see. We’ve gone backwards, it just looks better.

Advertisements

Games Development in Java

This is another one of my ideas posts. One of the many things I’d love to do, but simply don’t have the time to. The question is: why isn’t more large-scale games development done in Java? The answer to most is simple: speed. However, the answer is not actually that simple. Take into account that most of your graphics work (the most intensive work for any game) is taken over by the graphics card, and even physics these days can be farmed out to hardware. The question remains, and the answer stands in several places.

  1. Cross Platform byte-codes don’t lend themselves to game deployment
    1. Even though the advantages of running within a VM space can be huge
  2. Java is heavily multi-threaded, and that can make things difficult in a world where response-time is everything
  3. Garbage Collection is done beyond the developers control, many game devs feel insecure about not being able to “free()” or “delete”
  4. Java’s support for external C/C++ libraries in via JNI, which adds an extra layer of abstraction (if a very thin one)

All of these things are however solvable. I would choose GCJ as the start of my “Ubber Java Game Development Toolkit”, it’s an excellent compiler with many of the features you’d want to see for this sort of system. I’d develop an API layer akin to LWGL, but using CNI (GCJ’s answer to JNI; which has you writing code in C++ that directly links into your executable with no abstraction layer). Using your own API (written in CNI), you could directly bind onto the underlying platforms event model, getting rid of the Java event-queue. You can even take over most of the Garbage Collection by doing it in C++.

The idea at the end of the day is: native platform bindings, Java game code. So you API layer would actually make up a large portion of the game engine, allowing the actual game development to happen in Java, with compilation to a native executable.

Netbeans Best for Open Source Too?

A short while ago I blogged about how Netbeans is an amazing tool for developing MIDP applications. Today I’m going to explain why any Open Source software developed in Java, C/C++ or Fortran should be developed in Netbeans. First off, Netbeans has support for C/C++ and Fortran through an excellent C/C++ Module which integrates it into GCC and Make, and all those sorts of tools. But that just says “it can do C/C++ and Fortran”, so why is it good for Open Source developers then?

The answer: the collaboration modules. Now the first time I heard about the Netbeans Collab modules, they sounded like nothing more than an IM client in you IDE. That would be useful by itself, but it wasn’t enough to make me download the modules. However, these modules do not just you chat in your IDE. Start a conversation with one (or a few) other people, then drag and drop one of your source-files into the Conversation Window and what happens? The Collab module shares the file between all the people in the conversation. Now this is not your ordinary sharing, this is letter-for-letter, line-by-line changes visible to anyone who opens the shared file.

So now I can edit a few files you shared with me online, you can watch what I type, as I type it. You can also type, and I see what you’re doing as well. Now for the cool part: Right click on the Project icon in the Shared Files box, and click “Run”. Yup, it builds and runs the project on the machine of the person who shared it, and everyone can see the output.

This is a truly brilliant tool for people who live and work in the world of Open Source development, where you are generally not in the same room (and often even the same country) as the rest of your team. Netbeans Collab modules give you a whole new level of team development.

Xbox 360 Games on a PS3…

This is not about rumours of an Xbox360 emulator or any some such, it’s about what’s been going round in my head the past 20 minutes or so: How would it be done? Emulating a CPU takes enormous amounts of time, not to mention that Linux on the PS3 runs inside a Hyper visor, stopping it from using the RSX graphics chip. So again: how would it be done.

Ok, lets look at some facts:

  • PS3 gives Linux the use of 6 SPE’s
  • PS3 has 2 memory banks, where the 360 has 1
  • The 360 has a 3 core CPU
  • Both CPU’s are PowerPC derivatives

To sum up the way I would go about building an emulator: I wouldn’t.

  • I would build a kind of cross-compiler. Dedicate one of the SPE’s to transforming opcodes from Xbox to PS3 (where needed), this SPE could also be used to optimize code for the PS3’s architecture (this sort of thing has been done before).
  • I would then link the Xbox 360 code to a PS3 native library of known API’s, allowing things like the graphics and sounds API’s to be built for the PS3. More of these API’s could be developed over time, eventually taking over from large chunks of the Xbox 360 code.
  • I would drop the graphics detail and screen resolution heavily, I know this is a large part of why someone would buy one of these consoles, but you simply don’t have the power without the RSX (though successfully developing this code may push Sony to open the RSX up).

Depending on the underlying architecture of the XBox 360 and in particular the way it structures it’s executables, you may well be able to simply run a compiler over the code, optimize heavily (take a few minutes if you need to), and build a native PS3 / Linux executable which you run instead.

Update: In recent months Tungsten Graphics has been developing an OpenGL driver for the Cell CPU. Although it’s very early days for the project, in the long term it would make what I talk about on this page much easier. Although the RSX is not open to Linux, the Cell is  mostly. Having a graphics driver for the Cell would make a dynamic-re-compiler a lot easier to do.

Also for those that are concerned with the speed of an emulator. Don’t forget the QEMU project. Ignoring the full machine emulation side of the project, QEMU also has the ability to run executables that target one CPU on a different CPU (provided the OS libraries can be found).

Annotations in Java 1.2 and up

I really like annotations, as do a large group of Java developers. Note that I avoided the word “love”, since I find that some developers are already abusing annotations by over-using them. However, there are plenty of developers out there that can’t use Java 5, and are stuck on 1.4; 1.3 and some on 1.2. I’ve stumbled on two great Open Source projects that let you use annotations (or something very similar) in earlier versions of Java. This can also be really useful to people developing on a platform that doesn’t yet allow Java 5 (like a MIDP application).

The first is Retroweaver, which allows almost all the Java 5 language features on earlier platforms by taking Java 5 bytecodes and re-writing them back into Java 4/3/2 compliant bytecodes. As part of it’s re-writing it maps several Java 5 API’s to it’s own runtime API (annotations included here).

The second API is much simpler and from the Jakarta project, it’s Commons-Attributes. Attributes has an Ant task which scans your JavaDocs for “@@…” attributes, and maps them to an XML file. The XML file can then be accessed by using the runtime API, which is less than 40k in size. The compiler and runtime API map the attributes to classes you write (a bit like annotations, except that they’re POJO’s).

Classloading and Garbage Collecting in Java

A while back I put together this presentation for a company I worked for, and I thought I’d share it online. It gives a nice amount of insight into how Java handles classes, and how to build custom ClassLoaders, coupled with information about Java’s Garbage Collection internals. You can link to the Flash version of the presentation (Word Press doesn’t allow me to embed it in the page); or you can download the PowerPoint version (WordPress won’t let me upload the Open Document file unfortunately).

Hrm… I’m starting to dislike WordPress 😐

Why Netbeans is best for MIDlets

I’ve been using the Netbeans IDE for years now, but I have never been so impressed with any piece of software as I am today. I’ve been developing a MIDlet the past two days using the Mobility Pack, and I am nothing but impressed. In case you havn’t gotten the picture yet: this is very very impressive IDE. The MIDlet I’m developing uses a web-application to retrieve data and display it to the user. It’s a nice interface onto a CRUD application. The product has a web-service, but that is a strictly “write only” service. I was just going to create a new class to start working on stubs for the back-end application when an icon caught my eye:

In my experience Netbeans generated code is of a very high quality, taking into account situations I would generally not bother with, or not even think of. So I clicked and was greeted by a lovely Netbeans wizard (see below) asking me which Web-Project my MIDlet was going to talk to.

I already had my “HomePage” project open, so I gave the wizard the package I wanted to use and a name for the servlet. I wasn’t actually ready for the next tab though: I didn’t have any real model code ready, and I really didn’t expect what I was going to see next though.

You simply select the methods you want to be able to invoke and the wizard generates all the code. Now for the really impressive parts:

  • The code generated is session aware, you don’t have to bother with maintaining session cookies
  • It generates a configuration file the can be used (with a lovely editor) to regenerate the Servlet and Stubs
  • It can generate an example MIDlet that uses the generated code

This is but a tiny portion of the awesome functionality that the Mobility Pack gives you, other highlights for me include:

  • A work flow editor to organize which commands link to which screens
  • A GUI editor for building screens
  • Lovely support for building deployment descriptors etc.