I had planned to put up more of a tutorial post on rendering adaptive 2D grids for things like editors and such, since it was something I recently implemented. I got it working in my editor but then when I tried to conjure up a more “simplified” version in Blitzmax without any of the abstractions of a scenegraph, camera, and other numerous things I found I was tripping up over Blitzmax’s own graphics commands O_o. Being impatient I took the route of “at least it works in my system” and I’m just going to point you to a code listing that helped me generally implement it. Moving along now…

Since working on my weekend “Gunstyle 2” project I’ve had to develop a map editor that allows a mapper to save map files and load them into the game. In the first iteration of the game we had written the map files as binary files with all the assets needed in a single map file. On the 2nd iteration for the XNA Dream.Build.Play competition we used TorqueX as our engine of choice and it used XML files to serialize assets. After developing in both and developing the “next” version of Gunstyle in Blitzmax, I’ve had to tackle the decision of which type of serializing the framework and game would use.


I opted for XML in the end. The reasons were:

  • Portability – Something we wanted to do with the newest version of the game was pull over some of our levels from the original and the XNA/TorqueX version so we could quickly test gameplay on fully-developed maps. Massaging a binary file to be compatible with another binary format is a headache to say the least. The maps in the original Gunstyle were binary, so I took the route of exporting the maps to an XML format. the Binary-> XML conversion wasn’t easy either, but once in XML updating the schema as the framework evolved was A LOT less painful. Extracting the geometry of levels from our XNA version (which was actually a custom XML file outside of TorqueX) proved to be trivial also.
  • Readability – This is a difficult one to prove that is useful. If a binary file is valid, why do you need to read it? During development of the file format, being able to read the file output helps with debugging.
  • Flexibility – With XML, you can treat the map file almost like a database. Using XPath or some other way of querying the data, you aren’t restricted to the exact order things are in the file.
  • Ease of editing – With XML I can now leverage text editors to do simple edits in a map file rather than writing some custom tool to do what amounts to a basic  ‘search/replace’ for a map if, for example, an asset name is changed.

While using XML did give me some benefits, there were some trade offs I had to deal with:

  • Non-Encapsulation – Now a map file no longer was a single monolithic file. Which to me seems ‘cleaner’ and is much easier to distribute. Maps consisted of an XML file that essentially described the geometry, scenegraph layout, and where to find the textures and audio.
  • More Verbose Code – Writing a binary file in Blitzmax is less lines of code than writing an XML file (I’m using a binding to libxml by the way).

On the topic of encapsulation, I really liked having maps be a single file you can send to someone and be able to play. This also greatly simplified the auto-download feature of our previous game where we simply looked for the missing map file. I suspect to get this type of simplicity for users I would have to implement a virtual file system for the game and have assets and XML files be wrapped up in zip files or something. I’m fine with dealing with more verbose code as the benefits outweigh the downsides in my opinion.


There’s definitely more down-sides to using XML over binary than I listed above, but I can’t think of any at the moment. I attribute this to my hunger. I am now going to proceed to feed my face, play some games, and start doing some networking work :).  Just as a note, I will be traveling for the next week-ish, so don’t be surprised if I don’t get a new (hopefully more insightful/useful post than this one) post up next weekend. Happy Labor Day Holiday!

colestanceI’m currently working on an editor for the next iteration of Gunstyle on the weekends. I find it’s a nice break from iPhone development and lets me start the week with renewed energy to work on Tilt To Live again. I’m using wxMax to develop the UI for the actual editor. It’s not much at the moment but it’s coming together slowly. The editor code architecture is taking a page from the Unreal engine mentality of having your engine and editor be pretty much one in the same. After a little re-jiggering the internals of my framework I can now run a blitzmax game using my framework in a normal graphics window or inside an editor. The code running the actual game logic doesn’t have to know which mode it is in unless it really wants to, so it’s pretty transparent from the viewpoint of game code.

As for the editor code, that’s another beast entirely and it really adds complexity to the code base. I haven’t decided yet how “integrated” I want the editor in the game framework I have. Currently, 99% of the editor code lies on the game code layer, above the framework, and the framework just has some functionality for handling the switching between OpenGL window and a wx Application. The reason it makes this difficult is there are a set of opposing goals I’m dealing with here:

  • If I want to be able to re-use this framework for future projects, I don’t want to pigeon hole myself into a position where the editor is only good at making 2D side-scrolling physics-based maps. This mentality leads to where I am right now with the editor living largely outside the framework and just hooking into it.
  • If I want my framework to have a fully functioning editor, this will undoubtedly turn into a “Gunstyle Engine”. As I will want to make tools to specifically aid in creating Gunstyle maps and objects. Is that a bad thing? From a time and goal perspective, no. From an idealistic point of view, I want the framework to be ‘general’.
  • A potential compromise between the two opposing points above is to create a ‘generic’ editor that exposes a lot of hooks and ability to code in new tools. While a good way to approach this, I’m only doing this for fun and the end goal is to have a fun game to play. As someone with a limited time and constrained resources I cannot take on this approach as it’s a whole project unto itself.

So as a result, I’m left with either:

  1. A one-off editor for Gunstyle. The code from this editor could potentially be re-used for future games but will be specifically designed to work with the Gunstyle game.
  2. An integrated editor in the framework. In my mind, this would graduate the code from “framework” to “engine” code-base as it would introduce not only a set of API’s but a basic content-pipeline for creating content for this code base.

The main reason the one-off editor approach caused me to pause is there have been situations where I want to include functionality in the core of the editor (in the framework layer) but it would require me to pull in a lot of game specific functionality into the core as well. So I’m sure this is leading to several less than optimal code design decisions because I’m trying to tackle a game specific editor while simultaneously trying to develop a bare-bones editor.

An example of this is I’ve added a line tool to the editor this weekend. The line tool creates a physics based line object into the map for Gunstyle. Now, I feel a basic line and box editing tool is something that could be added to the core of the framework. The problem? The framework has no physics functionality. Physics is all on the game-layer. Currently, the 2D rigid body physics engine is home-grown, but physics is one of those things where I would like to switch out from project to project (using Box2D, Chipmunk, or Farseer). As a result, I’ve yet to roll any physics engine into the core of the framework.

After getting all of that written out in front of me, I think I’ll be sticking to the one-off editor route for this project. If anything comes of Gunstyle and it’s editor I’ll probably be more willing to roll more of the game editor into the core and just go the ‘engine’ route in the future. But for now, I’m trying to focus on Getting This Thing Done. And coding a generic solution to a specific problem is not the best way to Get It Done.

I’ve had this issue in past 2D games all the time. The ability to interpolate 2D rotations for basic animations for anyone that doesn’t understand quaternions becomes a rather laborious task. I’ve done messy if-then statements to try to catch all the cases where rotation hits the ‘360 to 0’ boundary and it’s always ugly and seemed like there had to be a more mathematically correct way to interpolate a circular value.

Well for anyone that sticks with it long enough, they undoubtedly run into quaternions. What are quaternions? I’m not about to explain it in detail, but I like to think of them as a way to express a 3D rotations and not having that annoying gimbal lock problem.

So how do quaternions help our 2D rotation needs? Well if you’re in a situation where you need to interpolate between the shortest path between 2 angles then Quaternions can help. You have a few choices to solve this problem:

  1. Use if-then clauses to try to catch all the cases when you hit a rotational boundary if you are rotating from, for example, 300 degrees to 2 degrees. You would want to rotate all the way through 360 instead of going backwards.
  2. Use quaternions, which are more applicable to 3D rotations, to interpolate between to angles using spherical interpolation (slerp for short).
  3. Use spinors, which are a very similar concept to quaternions, except they are more catered to 2D rotations.

You’ll eventually see that using quaternions is somewhat overdoing it as 2 axises are never used in any calculation in 2D. If you eliminate these 2 axises from the quaternion you end up with a spinor! Thanks to Frank, of Chaotic Box, who helped lead me down that direction for my own iPhone game.

To help test out the concept and make sure it’s working I ended up writing a Blitzmax quickie app using what little I know about quaternions. I’m certainly a bit iffy when it comes to dealing with complex numbers, as I don’t fully grok them as I do normal vector math, but I make do. So if anyone reads this post and sees some sort of logical error in my code, by all means leave a comment and I’ll improve the listing.

So to get started I needed a way to represent a 2D rotation as a spinor. So I created a spinor type with some basic math functions (all of them analogous to how quaternions work):

Type Spinor
Field real:Float
Field complex:Float

Function CreateWithAngle:Spinor(angle:Float)
Local s:Spinor = New Spinor
s.real = Cos(angle)
s.complex = Sin(angle)
Return s
End Function

Function Create:Spinor(realPart:Float, complexpart:Float)
Local s:Spinor = New Spinor
s.complex = complexPart
s.real = realPart
Return s
End Function

Method GetScale:Spinor(t:Float)
Return Spinor.Create(real * t, complex * t)
End Method

Method GetInvert:Spinor()
Local s:Spinor = Spinor.Create(real, -complex)
Return s.GetScale(s.GetLengthSquared())
End Method

Method GetAdd:Spinor(other:Spinor)
Return Spinor.Create(real + other.real, complex + other.complex)
End Method

Method GetLength:Float()
Return Sqr(real * real + complex * complex)
End Method

Method GetLengthSquared:Float()
Return (real * real + complex * complex)
End Method

Method GetMultiply:Spinor(other:Spinor)
Return Spinor.Create(real * other.real – complex * other.complex, real * other.complex + complex * other.real)
End Method

Method GetNormalized:Spinor()
Local length:Float = GetLength()
Return Spinor.Create(real / length, complex / length)
End Method

Method GetAngle:Float()
Return ATan2(complex, real) * 2
End Method

Function Lerp:Spinor(startVal:Spinor, endVal:Spinor, t:Float)
Return startVal.GetScale(1 – t).GetAdd(endVal.GetScale(t)).GetNormalized()
End Function

Function Slerp:Spinor(from:Spinor, dest:Spinor, t:Float)
Local tr:Float
Local tc:Float
Local omega:Float, cosom:Float, sinom:Float, scale0:Float, scale1:Float

‘calc cosine
cosom = from.real * dest.real + from.complex * dest.complex

‘adjust signs
If (cosom < 0) Then cosom = -cosom tc = -dest.complex tr = -dest.real Else tc = dest.complex tr = dest.real End If ' coefficients If (1 - cosom) > 0.001 Then ‘threshold, use linear interp if too close
omega = ACos(cosom)
sinom = Sin(omega)
scale0 = Sin((1 – t) * omega) / sinom
scale1 = Sin(t * omega) / sinom
scale0 = 1 – t
scale1 = t
End If

‘ calc final
Local res:Spinor = Spinor.Create(0, 0)
res.complex = scale0 * from.complex + scale1 * tc
res.real = scale0 * from.real + scale1 * tr
Return res
End Function

End Type

One caveat in the above code is that any angle from 0-360 is mapped to 0-180 in the Spinor. What does this mean? it means if I want to represent the angle 270 I need to divide it by 2, creating the spinor with the angle 135. Now when I call GetAngle() it will return 270. This allows us to smoothly rotate the whole 360 degrees correctly. This is explained here in more detail.

So now I want to spherically interpolate (slerp) between 2 2D angles. Well, if I call Slerp() on the spinor type it’ll do just that, giving me another spinor that sits in between the 2 angles. I’ve read a couple of articles in the past on slerp and how to implement it, but in order to get things done I just used a publically listed code snippet and ported it to blitzmax. That whole article is worth the read and recommended, even if you’re just using 2D.

Now that the concept of spinors is encapsulated in the Spinor type I wanted just a basic convenience function that I can feed 2 angles and get another angle out:

Function Slerp2D:Float(fromAngle:Float, toAngle:Float, t:Float)
Local from:Spinor = Spinor.Create(Cos(fromangle / 2), Sin(fromangle / 2))
Local toSpinor:Spinor = Spinor.Create(Cos(toAngle / 2), Sin(toAngle / 2))
Return Spinor.Slerp(from, toSpinor, t).GetAngle()
End Function
the ‘t’ variable is the time variable from 0 to 1 that determines how far to interpolate between the 2 angles. Giving it a value of 1 means you will get toAngle out, and a value of 0 is equal to fromAngle and anything in-between is just that…in-between.

Now I can call Slerp2D(300, 10, 0.5) And get the correct angle without worrying if I’m interpolating in the right direction :).

Also, I want to point out that the above code was just used in a quick proof of concept app. It’s somewhat sloppy and to be honest, I’m not sure I named the portions of the spinor correctly (real,complex), but it works. For clarity and to save time I didn’t inline the Slerp2D functions or the Spinor type methods, so it generates a lot of garbage. You would need to optimize this to use it in a tight loop somewhere. Any suggestions are welcomed.

As for references, I did some searching and got most of the ‘missing link’ materials I needed to bridge the gap between quaternions and spinors from:


wxMaxThe title of this article says it all. I’m currently working on the next ‘iteration’ of Gunstyle with a fellow developer and over the past weekend we were in need of a GUI library to help develop our map editor. In the past maxGUI ‘worked’ more or less….emphasis on the less. The design of maxGUI left me with a bad taste in my mouth. It’s a procedural library that is cobbled together with some weak OO on top that didn’t provide much flexibility (not to mention it wasn’t exactly ‘native’ UI on different platforms). Either way, it was a good library for small projects and prototypes.

Now we’re working on something of a little bit bigger in scale, and needing a more heavy duty gui library to go with it. So we chose Brucey’s wxMax GUI Module for Blitzmax. Just picking it up over the weekend has been a joy to work with. It’s object-oriented from the get go so it’s a bit easier to integrate into already established OO code.  It also boasts being cross-platform (Win/Linux/Mac), but I’ve yet to test or need this functionality yet. It’s also wrapping a rather solid and established library, wxWidgets.

One of the main requirements was for us to develop a GUI around a game framework that would allow us to switch in and out of an editor on the fly. To test this type of functionality I whipped up a basic test file that switches from the standard Blitzmax graphics window to a wxMax GUI with a GLCanvas and back again several times. Below is the actual source for doing that type of switching, in case anyone wants to do something similar:


Framework wx.wxApp
Import brl.glmax2d
Import brl.standardio
Import wx.wxFrame
Import wx.wxPanel
Import wx.wxGLCanvas
Import wx.wxglmax2d
Import brl.max2d
Import wx.wxTimer
Import brl.pngloader

Global app:TestApp = New TestApp
Global imgTest:TImage
Global imgPath:String = “myTestImage.png”

SetGraphicsDriver(brl.GLMax2D.GLMax2DDriver()) ‘ needed in order for the normal gfx driver to run
SetGraphics(Graphics(800, 600)) ‘ set context back to main window

‘ test switching between max2D and wxMax
‘ while loading an image that is shared between the two modes
If FileType(imgPath) = 0 Then
Notify “invalid path for image. file does not exist”
End If

imgTest = LoadImage(imgPath)


Function RunBmaxGraphics()
SetGraphicsDriver(brl.GLMax2D.GLMax2DDriver()) ‘ needed in order for the normal gfx driver to run
SetGraphics(Graphics(800, 600)) ‘ set context back to main window
While Not(KeyHit(KEY_ESCAPE))
If KeyHit(KEY_D) Then
End If
DrawImage(imgTest, 100, 100)
End Function

Type TestApp Extends wxApp
Field frame:wxFrame
Field panel:wxPanel
Field canvas:TMax2DCanvas

Method OnInit:Int()
frame = New wxFrame.Create(,, “Test”, 0, 0, 1024, 768)

panel = New wxPanel.Create(frame, wxID_ANY, 160, 0, 1024, 768)
canvas = TMax2DCanvas(New TMax2DCanvas.Create(panel, wxID_ANY, GRAPHICS_BACKBUFFER | GRAPHICS_DEPTHBUFFER, 0, 0, 1024, 768))


Return True
End Method

End Type

Type GLFrame Extends wxFrame
Field canvas:TMax2DCanvas

Method OnInit()
canvas = TMax2DCanvas(New TMax2DCanvas.Create(Self, -1, GRAPHICS_BACKBUFFER | GRAPHICS_DEPTHBUFFER))
ConnectAny(wxEVT_CLOSE, OnClose)

End Method

Function OnClose(event:wxEvent)

End Function
End Type

Type TMax2DCanvas Extends wxGLCanvas
Field timer:wxTimer

Method OnInit()
timer = New wxTimer.Create(Self)
ConnectAny(wxEVT_TIMER, OnTick)
End Method

Method OnPaint(event:wxPaintEvent)
End Method

Method Render()
SetGraphics CanvasGraphics2D(Self)

DrawImage(imgTest, 100, 100)

End Method
Function OnTick(event:wxEvent)
End Function
End Type

The main benefit of the above setup is seen in the switching between ‘RunBmaxGraphics()‘ and ‘app.run()‘. I can switch from my normal game logic, to an editor logic, but still use the same rendering routines! Now I’m not 100% positive that resources such as TImage will persist after a graphics change (in my case they do, but I don’t think that’s universal) so you may be required to reload textures.

It has been a while since my last blog post :(. If you’ve been following my twitter account though you’d know it’s still been a busy last couple of months. I’ve been developing things on several fronts lately. For one, I’ve been busy developing some supporting code to hook Opensteer into C4 in a more seamless matter and work with C4’s constructs in mind. It’s a project related to some school work, which has proven to be challenging and fun. Hopefully the students in the video game design class that I did this AI library for will find my work at least useful for their games.

In other news, I had a inspirational fever lately as I’ve come to understand a lot more of how physics and animation work due to a class I’m attending. I decided it’d be a fun spring break project if I could apply what I’ve learned to a simple 2D physics demo. Maybe it’ll grow to something more, but for now it’s more of an exploration and an excuse to work in Blitzmax again.

I’ve started the registration process for developing on the iPhone and it’s proven to be rather headache inducing lately with trying to get all the paperwork in order. After yet another delay, I won’t be able to start deploying apps on my iPhone for at least another 2 weeks. Damn. The iPhone game development venue seems promising, but the window is closing fast for anyone wishing to make a decent amount of money with minimal marketing effort. With the announcement of iPhone OS 3.0, and all the new features it’ll boast it makes the platform even more exciting to develop for. One of the more interesting development I think is the ability to ‘subscribe’ to apps and also buy additional content for particular apps. This type of business model would maybe give way to the first true ‘MMO’ (and I use the ‘Massively’ M loosely here) on the iPhone that can sustain itself? Interesting indeed.

Finally, I’m still chugging away at my Xbox Live Community Game. No idea when it’ll be done and there is no name for it yet. All I can pretty much say is it is a stylistic platformer. I recently got a parallax system working that I’m finally satisfied with. Also spent a couple of hours with Adam browsing music sites for potential audio soundtracks and we came up with some interesting possibilities. A lot of our musical choices leans more towards the ‘classical’ genre, so it’s not your typical uppity/pop/techno game music. I really hope as things solidify I’ll finally be able to post some media to show off the progress of my games. Until then, I’m focusing on finishing my last semester in school, looking for a developer job (preferably game industry related), and working on these game projects in the meantime.

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.

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…