I’m finding it hard to believe its almost 2009 already! I guess it’s that time of the year where I start reflecting on my accomplishments and shortcomings. Back in January I had set the goal of completing a commercial game. Well, that never came to fruition for various reasons. It was mainly a conflict in balancing school responsibilities with game development (which at this point in time couldn’t be considered anything but ‘hobby’). I guess my flaw was not taking it seriously enough, as I can recall on more than one occasion where I could have been a little more productive over the weekend with the time I had.

But after all is said and done, I’ve certainly made great progress towards that goal over the year. For instance, I’ve been writing a framework over this year to help me aid in making a game and its shaping up to be really great in terms of speed and productivity. Another nice thing that came out of my ‘venture’ into making frameworks was porting Farseer Physics to Blitzmax. Now users of the Blitzmax language have another ‘option’ for a physics solution. And finally, I’ve been making a lot of progress on my XNA game that will hopefully be released onto the Xbox Live Community Games.

I am feeling a bit stretched thin trying to juggle several exciting projects at once, but I’ve dropped the ones that were not vital to me achieving my goals and I’m pretty much focusing on 3 separate projects at the moment.

XNA Game

So I’m currently working on a new platformer for the Xbox 360 using XNA and TorqueX. This is my ‘short term’ goal of releasing a full game (I’m loosely using the term ‘short’). Currently, the team consists of me and one artist. Since January we’ve been prototyping different types of games, and always coming to the same conclusion: this game wouldn’t be worth polishing up. In the back of both our minds, we were wanting to do something a little more ambitious, but were trying to stay ‘practical’ and do something small first. In the end, I couldn’t muster up the motiviation to work on something that I didn’t fully believe in. So we went with the platformer idea. The basic ‘platformer’ mechanics exist, but it’ll have several twists in terms how one navigates and interprets the world. So we’re both excited about that. The unique ‘navigation’ mechanics we plan to implement are looking to be very challenging. On the technical side of things, since I’m using TorqueX the biggest challenge I’m hitting is TorqueX’s way of handling how a platformer should work. We don’t want to give up the tool set that TorqueX comes with, as that is the main reason why we want to use the technology. So I’m having to try to work in the ‘constraints’ of how the engine deals with collisions and rendering. Hopefully it’ll work out :).

Blitzmax Game

Blitzmax development is where a lot of time has been spent in the last couple of weeks. My ideas and projects are more ‘long term’ in Blitzmax than it is in XNA. Hence, why I’m taking my time building up a more robust code base. The last couple of weeks I’ve been deep in development of a networking module that works with my framework. It’s functional currently, and the API is seemingly easy to use I suppose. I’ve essentially taken Blitzmax’s built in TStream object, extended it as TUDPSocketStream, and allowed my game to use a ‘connection based’ protocol similar to TCP, but it uses UDP underneath. Why not just use TCP? Well I’m needing the flexibility of sending different types of data with different priorities. The 4 priorities I’m designing into the net code are:

  1. Unreliable Unordered – this is basically just UDP with no extra bells and whistles.
  2. Unreliable Ordered – Its important for the game code not to work about getting ‘out-dated’ data, but doesn’t necessarily care if a few packets don’t get to their destination. The networking layer will manage the ordering of these packets and only make them available if they are ‘newer’ than the last one it got.
  3. Reliable Unordered – This will be useful for messages that don’t need to be sent often, and are not temporally related to their previous messages.
  4. Reliable Ordered – the ‘heaviest’ of the 4 channels. I’m actually implementing this rather closely to how TCP deals with reliability, but using UDP as the underlying protocol.

The networking layer has proven to be rather challenging and complex. When I first initially started out, I had basic networking done in about a sitting or two. But as with anything dealing with networking, there’s a lot of work that has to go into all the unreliability of networks and how to deal with that. Trying to get the code stable so that it isn’t ‘sensitive’ to one or two lost packets is not trivial unfortunately.

I’ve tried to design the lower-layer networking close to how Blitzmax operates with normal streams.

Local msgSize:Int = _socketStream.Receive()
That’s essentially all that is needed for the UDPSocketStream to ‘receive’ messages. One important distinction, is that it is non-blocking. If you use Blitzmax’s built in TCP and UDP sockets as-is it becomes difficult to implement a single-threaded program where your main loop looks something like this:

while running

Local msgSize:Int = _socketStream.Receive()
… do some net code



TUDPSocketStream does use Blitzmax’s socket API, but does a little ‘outside the box’ tinkering to get non-blocking IO working in a native Blitzmax fashion. My socket stream has a method that makes this easy by calling some ‘undocumented’ functions that map to the standard sockets api:
‘bbdoc: enables/disables non-blocking on the socket
Method SetNonBlocking(enabled:Int)
Local b:Byte[1]
b[0] = enabled
ioctl_(_socket._socket, FIONBIO, b)
End Method
One thing to note is  ioctl_() is defined internally by blitzmax, and FIONBIO is a constant used by the sockets API. I had to look up the constants values,  and it currently works in windows without a hitch. To get it to work on Mac/Linux I would have to find the right constants for the ioctl() function that work under that OS. Here is the extern needed to gain access to those functions in Blitzmax:
‘ the socket options

Extern “os”
Const FIONREAD:Int = $4004667F
Const FIONBIO:Int = $8004667E
Function ioctl_(socket:Int, opt:Int, buf:Byte Ptr) = “ioctlsocket@12”
Const FIONREAD:Int = $4004667F
Function ioctl_(socket:Int, opt:Int, buf:Byte Ptr) = “ioctl”
Const FIONREAD:Int = $541b
Function ioctl_(socket:Int, opt:Int, buf:Byte Ptr) = “ioctl”
End Extern


For anyone that is doing any serious development in Blitzmax, I can’t see anyone in their right mind not using BLide. It’s a professional grade IDE for people who wish to develop professional grade applications/games. I’ve seen many who are still ‘clinging’ to the default Blitzmax IDE for whatever reason. At this point, if I’m working on anything that will require more than a day’s (hell, 30 minutes) worth of work then it’s worth opening BLide.

I’ve been working on a rather ‘large’ plugin for BLide that will allow users to download add-ons directly from within BLide. It also tracks updates so you can easily update from within the BLide editor. This will be great for those that are making add-ons to BLide and wish to reach their primary audience in a more direct way. The initial ‘proof of concept’ allowed for downloading of add-ons but the new version provides both a way to ‘upload’ new add-ons, moderate add-ons, as well as download them. So it’s an all-encompassing plugin that automates the delivery and deployment of add-ons. I’ve yet to come up with a name for the whole system, but as it comes closer to ‘beta’ I’m sure I’ll think of something :).

Onward to the Upcoming New Year!

I’m hoping to get the first complete pass of the networking layer done by year’s end. I’m focusing on building up my framework for the remainder of this month, being that it’ll be a rather hectic holiday with plenty of travel, it won’t be too bad if I don’t get as much done on it as I intended since its a long term project. Come January, I’ll be primarily focusing on my XNA game and an that interesting BLide plugin. The start of a new year is exciting because it always brings a ‘clean slate’ and allows me to gain some perspective on what my goals for the year will be. I hope by the end of 2009 I’ll finally be able to say I’ve ‘released’ a game successfully, be it indie or otherwise :).

Now, I’m off to go snowboarding for a week! Merry Christmas and a Happy New Year!

I was made aware of a serious issue with detecting collisions between TGeom’s recently. While it did not affect anyone who was using the engine and letting the TPhysicsSimulator run and manage collisions and dynamics, anyone who wished to use Farseer.BMX’s collision routines separately by calling TGeom.CollideWithGeometry() ran into issues. The code has since been fixed and updated. Please update your Farseer.BMX module so you can continue using it without this annoying bug.

Download: Farseer.BMX v1.1

What if I made customizations to the Farseer.BMX code already?

Well thankfully, the bug was isolated to only one file, and in particular one method. If you wish to keep your custom build of Farseer but want to fix the issue then simply download this new version and take the Collisions/Geom.bmx file from it and place it in your corresponding Farseer.BMX directory.

If you happened to make changes to the Geom.bmx file itself, then simply search for the method ‘CollideWithGeometry()’ in the new version and place it in your current version. For those that simply want the code that’s changed (since this is a small change) I pasted it below:

Method CollideWithGeometry:Int(geometry:TGeom)
For Local i:Int = 0 To _worldVertices.Count() – 1
_vert = _worldVertices._vecArray[i]
If geometry.Collide(_vert) Then
Return True
End If

For Local i:Int = 0 To geometry._worldVertices.Count() – 1
_vert = geometry._worldVertices._vecArray[i]
If Self.Collide(_vert) Then
Return True
End If

Return False
End Method

This was a minor update that I thought was critical to getting out there for those that may be experiencing problems, so there aren’t any ‘extras’. Documentation is still a WIP.

Quick status update on Wildboarders. Every week I tend to have small incremental goals to hit. This week focused on wrapping up the supporting code to allow me to generate levels for the game. I’m slowly starting to realize my current schedule isn’t accomodating to my game dev time. It’s actually the opposite, my game dev time is working ‘around’ my schedule. Looks like I’m going to have to rearrange a few things on my weekly schedule to actually get this game done on time and make game dev my focus for the next several months. Why do we only have 7 days in a week? Sheesh.

I’m beginning to wrap up most of the ‘content’ code such as tutorials, in-game events/dialogues for the first level of the game. It’s taken a while to complete the first level just because there’s some start up development that needed to be done. I’ve designed a lot of the systems to be data-driven so ideally, level creation will be a speedier process. The only portion I’m not too satisfied with is the cut-scene/event code. Most systems like tutorials and dialogue lend themselves rather nicely to simple data-driven designs. Trying to orchestrate multiple custom in-game events for several of the levels is a daunting undertaking. I do not have the time to and resources as a single developer to go off and create a complex in-game event/cut-scene editor just for this game. The good thing is that the majority of the gameplay code is already complete, so it’s these ‘exceptions’ that are mostly left to deal with. Below is a ‘work-in-progress’ screenshot of one of the in-game events. Your character, Indy, took a bad fall and ate snow! At the moment I’m using pretty much 100% placeholder art, most of which is from the previous version of wildboarders.

So much to do… so little time…

Just wanted to post a quick update on some game development stuff I’ve been working on the past couple of months. Farseer Physics is just one of the few projects I’m working on. By the way, I’m still slowly working on Farseer physics, but don’t expect an update on it for a while. I’ve mainly been giving support to those who are using it through e-mail. So if you’re having issues with it or can’t figure something out let me know and I can help you there. I also figured it was finally time to do some aesthetic work on the site. I like the way it turned out :). All in all, things are doing great but I’m ever so busy! Over the last few months I’ve been neck deep in either Blitzmax, C#, C++, php, or mySQL.

Continue reading

I’ve been working on a few projects that require blitzmax and a web-server (php/mysql) to communicate. Along came the need to hash files. This code archive entry was very useful :). I decided to wrap it into  an object and add a new method to it. Even though it’s a series of functions I still tend to make types with functions in them to help me organize them (it’s like a cheap way of  namespacing). I needed the ability to hash a file using Sha-1 hashing. Seeing that php has a function called sha1_file($pathToFile) I figured I’d implement the equivalent on blitzmax. With this THasher type, I’ve added a SHA1_File(path) function also.

Why hash files?

There are many reasons to use hashes, but recently I used it to check for file changes. If you’ve ever wanted to find out if some arbitrary file has ‘changed’ since the last time you’ve opened it this can prove to be useful. If you save the hash beforehand then recompute the hash now and if they are different, then something’s changed! Some applications of this are:

  • Write a file-updater to quickly find out which new files need to be downloaded. Just comparing hashes would be sufficient in most cases, instead of having to go individually byte-by-byte or traversing the file structure to find a difference.
  • help stop cheating. If you don’t want users changing texture files to gain an advantage or don’t want them ‘mucking’ with any other data file. If you check the current hash against a previously approved one and it doesn’t check out then the file has more than likely been tampered with.

How Do I Use THasher?

If you want to hash a string using SHA-1 then:

Local hashedFoo:String = THasher.sha1(“Foo”)

Want to hash a whole file? Then:

Local filehash:String = THasher.SHA1_File(“someFile.txt”)
Keep in mind you can hash any file, not just text files like in the above example.

Anyway, read on for the whole file. With the exception of SHA1_File() I did not write these hashing functions for Blitzmax. They were simply taken from Yan’s very helpful code archives post :).
Continue reading

Yes, yes I know the documentation is lacking at the moment for Farseer.BMX. I’m still working on it on a few fronts. First, I’m trying to do api documentation (bbdoc mostly). Secondly, I’m trying to write tutorials/guides that help show how to use some of farseer’s features. I had hoped that releasing the demo application source code would’ve covered this aspect as the demos cover pretty much each feature, but I guess since the demo source is a bit more complex in design (handling a lot of graphics related mumbo jumbo), the actual ‘needed content’ wasn’t particularly easy to find. So I’m going to try to write up very simplified versions of some of farseer’s basic features (minimal graphics, minimal code).

I’ve uploaded the first of these tutorials to the articles section. It covers creating concave polygons in farseer :). More to come soon…

So far feedback has been great on Farseer.BMX working in Blitzmax. Some users have tested Farseer.BMX on Linux and Mac and it works without a hitch. Farseer.BMX is officially cross-platform between Windows, Linux, and Mac! That’s great news seeing how widely available the Farseer engine is becoming. It’s now available on:

  • Windows
    • C# – XNA
    • C# – Silverlight
    • Blitzmax
  • XBox 360
    • C# – XNA
  • Linux
    • Blitzmax
  • Mac
    • Blitzmax
  • Your Toaster
    • ???

I’m curious if Jeff has any plans on bringing it to Zune…hehe.

The main reason I’m posting an update is to let everyone know that the download for Farseer.BMX has been updated to include a ‘module’ version of Farseer for those that like to have all their code in ‘module’ format for easy use across projects. So if you were wishing for a module version of Farseer.BMX, you’re wish is granted and you can go ahead and re-download the package. The package contains the original source layout for those, like me, who like to have all their library source code next to their game code, and additionally a farseerModule.zip that you can extract to your “Blitzmax/mod/” folder.

So with the module installed you can now just do this in your code…

Import aco.farseerphysics
‘Weeeee physics….!

… and off you go!

Please let me know if you run into any issues with the module.

*…wonders how he’s going to get up tomorrow morning for class….*

And there was much rejoicing! It does feel great to finally ‘finish’ something. I started out this project as something to give me a foundation to code my own game project on, and now after 110+ hours of coding there is a 2D physics library for Blitzmax :)! I hope it proves useful to those that end up using it. While the engine hasn’t been tested for ‘real-world’ use it I think the demos do a good job of putting it through its paces. It’ll very soon have a good test through a ‘real world’ application once I get it integrated with my own game project. Anyway, Farseer Physics for Blitzmax is ready for download. The zip file contains:

  • A compiled version of the physics demo application with 4 new demos!
  • Ready-to-compile source code for both the core physics engine and the demo application
  • A ‘quickstart’ application that shows someone how to setup a basic physics scene with minimal code.
  • a ‘quick start guide’ that pretty much is a walk through of the quick start application. Which can also be found online.

For those eager to get their hands on it:

Download: Farseer.BMX

Since the last update, things came together rather quickly. I finished up the last of the classes that needed to be ported earlier in the week, which I then spent the rest of the week adding in demos to the demo application. This port is a very close implementation of the original Farseer in C#. The only times the source would deviate in any major fashion were in time-critical algorithms where optimization needed to be done differently considering how different C# and Blitzmax handle things (particularly garbage collection). With that said, you may find it helpful to visit the codeplex site of the C# version of the engine if you find yourself wondering how to do something in Farseer. While the answer you get may be in C#, keep in mind the methods, functions, and variable names are similar, if not identical, in Blitzmax. I’ve also implemented additional demos on top of the standard ones that came with Farseer to show the use of most of the available types in the engine. So if you wish to know how to implement a certain feature, try looking at the source code of one of the demos that does the said feature.

Here’s just a quick run down of what was added/updated since last post:

  • Added Demo 11 – Slider and Pin Joints
  • Fixed a minor bug in the main menu causing the about screen to stick
  • Sweep and Prune Collider implemented (not completely optimized)
  • Bilinear Interpolator
  • Added the Convert Units class for easy transformation between screen and world coordinates
  • Added IFluidContainer
  • Added onEntry and onExit event handling for fluid containers
  • Added Collision event handling
  • Added Demo 12 – Fluid Drag Controller
  • Added Demo 13 – Collision Event Handling

The fluid container objects turned out to be a bit cooler than I expected it to be. Not only did it simulate buoyancy but there was a controller that simulated wave formations on the surface of a container. Cool stuff indeed…

Pictures don’t do it justice so here’s a video…

By default Farseer doesn’t come with any code that allows geometry to create disturbances in a fluid container, but it comes with a nice, easy to use Disturb() function along with handy callback events for when a object enters and exits the container. With this I threw together a basic water container class that does some very ‘rough’ interaction between geometry and the waves. It’s far from realistic, but still yields an interesting effect I think. Someone could easily take this code and improve upon it. I’ve kept it outside of the ‘core’ physics engine and put it in the demo source since it was something that was kind of thrown together last minute (you can tell that by the rather rushed rendering code).

So that’s about it for now. I hope this engine finds some use in the Blitzmax community. Thanks to those on the blitz forums that provided feedback and data to help me optimize the engine. An especially big thanks to Jeff Weber for writing such a robust 2D physics engine to begin with!

*Crosses fingers and hopes the code will compile without issue on OSX and Linux*… 😉

I was hoping to have an update a little earlier than this, but decided to hold off and throw together at least a bit of content with the update. I’ve added a slew of joints and controllers into the Farseer engine for Blitzmax (which I think I’ll just start referring to as just Farseer.BMX to save my poor little fingers). Below is a list of stuff I’ve added since the initial post:

  • Angle Limit Joints (featured in the youtube video below) – this allows you to do some interesting joint behaviors that could potentially allow you to create a 2D ragdoll of sorts with limb constraints.
  • Fixed Angle Limit Joints – Same as above except instead of linking two objects together, only one is used and it’s angle is limited.
  • Fixed Angle Joints – Allows you to make an object always point in a certain direction. You can think of it as a way to disable ‘rotation’ for a particular object, and it will always be set at some angle from some anchor regardless of where it is in the world.
  • Angle Springs – You can link two bodies and they will attempt to align themselves to a certain angle using spring physics to give a bouncy effect.
  • Interactive Angle Joints (untested)
  • Circular Interpolator (untested)
  • Pin Joint – This one allows you to choose an anchor on two bodies and a distance, and the two physics bodies will always stay that distance apart, but still tumble and interact with other bodies realistically.
  • Slider Joint – Same concept as a ‘Pin Joint’ except now instead of a concrete distance apart there is a minimum distance and a maximum distance these two objects will stay within.
  • Brute Force Collider – Just another broad phase collider you can use instead of the default one. I may dig up a forum post by Jeff and others that describes the advantages/disadvantages among the different colliders you can choose from in Farseer.
  • Some getters/setters for the physics debug viewer class – Makes the debugger class a little easier to use.
  • Fixed a few minor bugs

Anyway, the video I posted isn’t that impressive but shows you that Farseer makes it pretty easy to setup different types of constraints and scenarios with just a few classes. There’s no new demo application to download for this update as I’m pretty close to finishing up the rest of the port, and would rather just wrap up a few more demos and get the code out there for others to use. Hopefully I’ll have more in a week or so!

Hurray! Finially got to a stable stopping point in porting over Farseer Physics from C# on XNA to Blitzmax! Farseer Physics Engine is a 2D physics engine originally written by Jeff Weber who develops XNA/Silverlight games over at Farseer Games. Much thanks to him for creating a great physics engine and for allowing me to move it to another language, which once done, I hope will help others create fun physics games in Blitzmax.

I’ve ported the ‘core’ features of the engine which now would allow you to use the basic features of the engine. If you head over to the Codeplex Farseer Physics Page you’ll see a list of the features in the C# version of the engine. Right now the things that aren’t implemented in the Blitzmax version:

  1. Fluid Drag and Buoyancy Controller.
  2. Slider (Prismatic) Joint
  3. Pin (Distance) Joint
  4. Broadphase Colliders: SweepAndPrune, BruteForce
  5. Collision Callback Mechanism

Currently, the Blitzmax version is using the ‘SelectiveSweep’ Broadphase collider that is the default collider in Farseer, and is supposed to have the best performance in a wider range of scenarios. The others have their advantages and disadvantages based on specific situations in the physics environment. I’ll be implementing those as well along with the rest of the list, but they weren’t used in the current build of the C# Farseer demo application so I chose to focus on the needed classes first to get an identical demo app running in Blitzmax.

Just some metrics you may find interesting (as I’ve noticed typical Blitzmax users have a very different way of developing their games):

84 .bmx files used for the physics engine and the demo application
7957 lines of code (blank lines not included)

Sounds like it may be a lot, but in reality it really isn’t much compared to a full relatively complex commercial Casual, Indie, or AAA game. But the reason I put that up there is to illustrate a point. I feel like if I was using the default Blitzmax IDE I would’ve have one hell of a nightmare just handling these little files. Having a project of a much bigger scale in BlitzPlus in the past, I know from experience the headaches of a large monolithic code base. You spend a lot of time scrolling and searching through files because the IDE promotes that type of behavior from the get go. Using BLIde, a very flexible editor created by Manel Ibáñez, productivity went way up and I was able to get more done on the physics engine. Not to mention built in Intellisense support is a god-send, which lets you spend more time coding instead of reading API docs. Just that feature alone I think is enough to abandon the default IDE and stick to BLIde. Anyway, if you’re a Blitzmax user I highly recommend that you take the time to learn to use BLIde and support Manel’s efforts for an outstanding product!

I’ve uploaded a demo video showcasing the same demos available in C# running in Blitzmax. I also added a new and original demo by me showing the use of concave polygons, which is one feature many 2D physics libraries lack. With other physics engines you can emulate concave shapes by putting together a bunch of convex ones, but it’s still a cumbersome and tedious task. The ability to create concave shapes with minimal hassle is a great productivity boost for content creation in your game. Below is a video of the physics demo app, along with a download link to the demo app itself so you can run it on your own PC. Hope to have more info posted with updates in the coming weeks!

To download the demo application shown in the above video click below:

Download Farseer Physics Demo


– Windows XP/Vista
– Direct X 7 or higher capable video card
– Minimum supported screen resolution: 1024 X 768

Known Issues:

– In Vista the fps are lower (and in some demos locked to 60 instead of 100 fps).