Featured Post

Update

It’s been a while since I posted anything to the blog as I tend to use Twitter these days for gamesy stuff but I thought I’d recap exactly what I’ve been doing these past few months in Pumpkin Land. I’ve been keeping busy converting various bits n bobs of Java, frameworks and libraries to C#, in an attempt to release some of the awesome games from Puppy Games on the iPhone via the awesomeness that is Mono / Mono Touch. I’ve worked with the Puppy guys in the past, bringing Ultratron to the Xbox 360 via XBLIG / XNA Games Studio and entering a Droid Assault WIP to the 2011 Dream Build Play contest (we didn’t win). Previously, I’d used a hybrid approach when dealing with the Puppy code in XNA. A bit of their stuff, a bit of mine, the Content Pipeline, etc, in a mash up of conflicting styles and designs goals. And while this worked, it involved a fair amount of hacking, bug hunts and lots of head scratching trying to fit square puppies in round, pumpkin shaped holes. So, this time would be different! I’d convert the whole Shaven Puppy Games Library (SPGL), their support tools, their reflection based resource loaders, their GUI, the lot! Oh, and therefore any bits from The Lightweight Java Game Library (LWJGL) that the Puppy engine utilised. It would be a fairly complex conversion but ultimately make converting the games much, much easier. I started sometime in October, maybe the 14th and by mid December I was done. A minimal SPGL proof of concept app running in the iPhone simulator on my brand new shiny MacBook Pro. Sprites, music, SFX, arbitrary geometry, text, touch all present and correct. The actually journey from Java source to running appplication wasn’t too bad. A few folks commented that it should be a breeze to convert to C# due to the similarity of the languages, and while mostly right, there were a few bumps along the way. Firstly, I ‘needed’ a new Mac. Mine was old and slow and the keys were silver instead of the new flat black ones and, ok then, I just wanted a new one. Then I had to set up the Mono environment which was quite difficult for someone that bootcamped Windows pretty much exclusively on the old one. Where do the libraries go? Ah, Nant is compiled with MCS and I want a v4 compler so I need DMCS, blah, blah, blah. I shouldn’t complain though as without Mono none of this would be possible. And it really is an outstanding piece of work created by magic, pixie dust and lots of hard graft by the folks at Xamarin Next was down to a combination of too many late nights and grand incompetence on my part. Trying to run my Mono code on the iPhone. That’s desktop code. On the iPhone. What was I thinking!? Once I realised what I fool I’d been I created some Mono Touch solutions, referenced the correct framework libs and we were good to go. Then there was all the Java bits ‘missing’ from C# that I needed to either duplicate or rewrite. I chose to duplicate and spent some time in java.nio, java.io etc dragging more and more bits of core functionality in until finally drawing a line, adding some NotImplemented exceptions and commenting out some stuff that probably will never be called anyway. Generics are different. A bit of head scratching there. Annotations / Attributes close enough to hack around a solution (no generic attributes allowed in .Net). Reflection pretty much the same really just different keywords so I either added extension methods or changed the source code to be more Dot Netified. Default scope rules are different, no biggie though. Checked exceptions – gone. Iterators to foreach mostly ok (except for list modifications while traversing) and probably a few others that I forget now. I must thank Cas Prince for putting up with me hassling him late at night on Skype about Java syntax or functions or why my sprites aren’t showing / are the wrong colour! So there we are. All ready to go in the new year, hopefully with some cool games for desktops, mobiles and tablets. Cas will do the Java side and I’ll port to iOS. Merry Christmas. PS – I’ve also got a Windows Phone 7 / Xbox ports done now too. Happy days

Read More

What the dickens is a LWJGL?

Posted by Paul | Posted in Code, Droid Assault, Puppy Games, Ultratron, Uncategorized, XBLIG, XNA | Posted on 30-11-2012

0

I’ve been Tweeting quite a bit recently about the various libraries and frameworks I’m converting from Java to C# and I’m aware the posts are probably pretty meaningless to all but a few select developer chums.  So, in an attempt to enlighten the rest of the Pumpkin followers, here’s the low-down on the main players involved.

LWJGL – The Lightweight Java Game Library is an open source Java software library for computer game developers. It exposes common libraries like OpenGL, OpenAL, etc in a speedy, lightweight manner to the Java crowd. Cas Prince (@puppygames) was the original author. It powers all the Puppy games, Project Zomboid and Minecraft to name a few.

I’ve converted the graphical primitives like Color, Rectangle, Vector (and whatever interfaces they implement) as is – they are reference types and take precedent over the XNA equivalents. The input classes; Mouse, Controller and Keyboard are done too and they just delegate to their XNA namesakes.

SPGL – The Shaven Puppy Game Library, is a layer that sits on top of LWJGL. It’s got a sprite engine, sound players, resources live here (fonts, paletes, etc) a bunch of animation commands and some OpenGL and OpenAL stuff. There’s some nice ‘rich text’ classes GLStyledText, GLTextArea for use by the GUI.

It also contains the resource loader / converter which takes a bunch of XML and creates fully working (Java/C#) objects from definitions in the mark up:

e.g.

The following XML snippet would create a GLTexture resource and an ImageBank resource at run time (or build time if you prefer)

<texture name="solid_background.texture" url="solid_background" dst="GL_RGBA" 
target="GL_TEXTURE_2D" min="GL_LINEAR" mag="GL_LINEAR" wrap="false" />

<imagebank name="background.imagebank" texture="background.texture">
  <spriteimage name="spriteimage.bg_bottom_left" x="0" y="0" w="10" h="12" hx="0" hy="0" />
  <spriteimage name="spriteimage.bg_bottom" x="10" y="0" w="42" h="12" hx="0" hy="0" />
etc
</imagebank>

Cool eh?! The similarities between Java and C# made this a breeze really which was a godsend as this is probably the core task when converting the Puppy stuff.

The sprite render uses XNA’s DrawIndexedPrimitives with dynamic Vertex and Index buffers. The Java renderer is a big array of floats so I created a corresponding VertexDeclaration and just blat whatever the sprite engine throws at it. Cas removed all (*most?*) of the immediate mode glVertexX OpenGL calls so there’s all sort of goodness going on here, with batching and buffers galore as sprites and arbitrary geometry all live happily together. There were a few glTranslates, glPush/PopMatrix calls left so I just created a GL wrapper object and mimicked the OpenGL matrix stacks (e.g glPushMatrix() becomes GL.PushMatrix()). The AndroidSPGL library I converted last year used OpenTK on the C# side but my new GL wrapper keeps the call parameters the same data types as OpenGL (public const int GL_TEXTURE_2D instead of All.Texture2D type enums)

LWJGLApplets - Next in the chain, this is the GUI and effects layer and is where the particle emitters live and all the widgets you’d need for a user interface. It contains a stack of Screens so you can navigate through the game; Title Screen, Options, High Scores, all the usual basic stuff. Games can subclass these screens to add features and obviously define brand new screens.

Java – I decided to convert bits ‘n’ bobs to aid the conversion process. So when SPGL needs a ByteBuffer I just use my C# implementation of it instead of changing the SPGL source code. Most of java.nio is done and some other misc stuff like Integer.parseInt but I stopped half way through java.io and now I just use .Net collections instead – with added extension methods if required to match the Java behavious (e.g. HashMap.put(xxx) -> Dictionary.put(xxx) extension method). Extension methods help massively in getting to that glorious ‘Build Succeeded’ message in Visual Studio but if after profiling all the wrapping hurts performance then the source code is changed to a native class / call.

The Java Conversion Monkey – this is an automated conversion Windows Forms tool I knocked up to aid the entire process. You point it at a folder containing Java files, give it a destination folder and out pops a corresponding .cs file with beautiful C# code.

It’s a pretty brute force approach; each file has a series of FileProcessors perform conversion work on it in order – I’ve got NamespaceProcessor, FindAndReplaceProcessor, RegExProcessor, plus about 5 or 6 more that I forget now. It helps greatly in the process but there’s still a fair bit of manual fix ups to be done. A special mention here to Resharper too as it flags all the code errors like ‘you need override here’ or ‘this methods hide blah in the base class’.

So what are the main problems converting a bunch of Java libs to C#? Sound normally gets left until last and I usually do a few iterations until I’m happy with it. Stupid Java interfaces with their fields definitions – anonymous classes, blergh. I tend to create a concrete implementation here and add some delegates. But the worst annoyance by far is Binary Serialization. Simple to convert in theory but it’s a major PITA (and is something I will be leaving until the very end). Compact framework doesn’t have a binary serializer,  can’t reflect over private fields on the Phone. Once you add some custom serialization, the built-in mechanism gives up and it’s custom all the way. Java uses an Interface to tag classes as serializable, .Net a [Serializable] Attribute. However, I still need the Java Serializable interface as some of the SPGL functions require a serializable object. But then I need to implement .Net’s ISerializable too. This is what I currently end up with..

<code>
[Serializable]
public class SomeClass : Whatever, Java.io.Serializable, System.Runtime.Serialization.ISerializable {
<code>

hmm, it all gets a little bit messy and confusing :-)

That’s about the bulk of it. The ultimate goal is to convert Puppy Games’ titles to Xbox, iOS, PS Vita, Window 8 Phone, Surface with the minimum amount of fuss and  impact on the actual game code.

Java – done. LWJGL – done. SPGL – done (And the Android version). LWJGLApplets – in testing.

Titan Attacks – COMING SOON!

 

Write a comment

You must be logged in to post a comment.