It’s been busy, busy, busy as of late. We’re in full swing trying to get Tilt to Live HD ready for the iPad. It’s looking amazing thus far and plays a lot better than just the 2x mode for the original Tilt to Live. Frostbite mode just went out the door a few days ago, and the response has been positive so far. We’ve been getting some responses from users saying the game has become too easy in the other modes. I haven’t tweaked anything in the other modes for ages so my hunches to why users are believing this are:

  • It’s been a while since they’ve played and when they came back it was like riding a bicycle and they instantly got into the flow of the game.
  • Performance has degraded on the lower end devices (particularly when running iOS4), which slows the game down and as a result makes it ‘easier’.

I’ve tested the game on a 2nd gen ipod touch with iOS4 and it seems to run fine performance-wise. So it’s something I guess I’ll just keep on my mind when doing further updates to the game. Maybe revisiting Code Red mode and making it even harder could be a possibility to appease the hardcore users.

Some Reading Links

Whenever I have time to kill I go browsing through my RSS feed to catch up on things. I decided to share a few of my usual reading links. Maybe you’ll find something of interest in this pile as I tried to focus on reading links that are outside the iphone development community. A lot I’m sure are common go-to places for a lot of indie devs regardless of platform.

Cliffski’s Blog

I feel like just about anyone that has any semblance of what goes on in the indie world is at least aware of Cliff Harris and his musings on his blog on both his own games and the industry as a whole.


Steve Gaynor’s [Bioshock 2] video game design blog. Always a good read and has valuable insights into not only the design of mechanics in games but about the medium of games overall.

Shawn Hargreaves

For a time I worked mostly in XNA and C#. While most of his recent posts are about gearing up for windows phone 7 and other XNA tech, his technical but easily readable posts were extremely helpful not just in XNA, but any platform you may be starting out on. Great learning for those that don’t have true game industry experience (like me). His credits include Extreme-G (N64), Moto GP (Xbox/PC), and several other racing games.

Mark Sibly

Ok, not many updates for this blog but that’s not the point. Creator of Blitz Basic and Blitzmax. For those that don’t know anything about it, Blitzmax is a very nice cross platform language (PC/Mac/Linux) for developing 2D (and 3D) games. It’s a very small and friendly community, but one I spent a lot of time in when I first started getting serious about making independent games. The tech he currently is working on seems like really exciting stuff: A language that allows you to target HTML5, flash, XNA, Android, iPhone, native GL for game development. Very ambitious, but very exciting to keep tabs on!

Beautiful Pixels

Great graphics and game development blog. I believe he recently went to work for Google on Chrome OS. Great posts to browser through, and I’m sure some very useful ones in the coming future. Despite having a lot of ‘game oriented’ blogs on my feed, I tend to follow developers outside the game industry as well. And now that he’s at Google, I’m sure lots of good will come of it :).

Game Architect

A great blog on finding the ‘hard to find in a book’ answers to questions that come up during development. Like what’s a good way to keep you from creating a crazy object hierarchy but still have flexibility. Great thoughts on middleware as well.

Grey Alien Games

I’ve been following Jake Birkett for several years now as I was going through high school and college. His success as an indie was very inspiring. Great place to read for motivational and lifestyle posts as well as general independent game development. He was also a very involved community member in the Blitzmax community, writing a pretty successful game framework to allow developers to more quickly make indie casual games on the PC.

Lost Garden

If you haven’t heard of this site and Danc by now, then…I don’t know what more to say.


Andy Patrick’s blog. Great info from an experienced developer. He previously worked at Rare on Kameo and Viva Pinata. Hasn’t had an update in over a year but some good content on programming things like cameras, game programming in a garbage collected environment, and tool recommendations. One article I really liked was going over how to implement infinite undo/redo in an game editor.

Sell More Games

Great site has articles focusing more on the marketing and business side of indie game development. Mostly geared towards the PC market, but I feel all of it is still applicable to the iPhone market.

Make it BIG in games

I believe I’ve referenced Jeff Tunnell’s blog entries before, but it’s worth listing again.

Gausswerks Design Reboot

Another great game design blog. Less on the technical and more on the design and art of games. I’m ashamed to admit I don’t read enough of these articles.

I’ve had a rather productive weekend! Implemented a handful of new art assets from Adam, finished some more gameplay code, optimized a bit, and even released a new build to testers tonight. It wasn’t a smooth process, but when is it ever? I was having an issue with loading the assets of the game at app launch and it caused the game to crash if it ever took more than 20 seconds to load the assets.

Admittedly, the asset loading code could use some optimization. Namely, I need to start using texture atlases for the art assets to minimize the state changes in OpenGLES. The reason I haven’t done this yet is art assets are still in flux and changing almost daily. I haven’t found any decent tools to pack textures into single images yet (haven’t looked too hard yet) and I haven’t taken the time to re-write the resource management in the game to be aware of multiple resources in the same texture.

So I’m putting it off for now and in the meantime wanted to redo the overall asset loading the ‘right way’ with a proper load screen and what not. I was faced with:

  • The Easy Way: Just draw up a loading screen and then load the assets right after drawing. The game essentially is blocked and there’s no user feedback that the game is running until the assets are all loaded
  • The Difficult Way: Whip out some multi-threading API’s and have the assets load on another thread and have some animation play on the main thread.

Naturally, I chose the ‘difficult way’. After doing some reading up on multi-threading assets on the iPhone I figured it wouldn’t be too difficult to get running and I could implement it for tonight’s build. Wow was I wrong. I took the 20 minutes to implement the correct EAGLShareGroups and EAGLContexts and the supporting code to play the load screen and have the background thread load the assets.


It all worked beautifully and having the circles spin while the “loading” words doing some idle animation worked surprisingly well with little stuttering. I tested it on the Simulator and it worked fine, but to get accurate time results I began testing on the device itself. With everything in order I kept testing the loading screen and nothing was amiss. I was minutes away from calling it done and about to start making final test builds when I tried it one more time unhooked from my mac mini… I was looking at the circles spin when suddenly they locked up. The screen turned black, and the next second I was staring at my home screen.

After debugging the build I was still at a loss as to what was going on. Each time the application crashed it was an EXC_BAD_ACCESS error in the CGContextDrawImage function. I’m using this function to load a texture into OpenGL and it’s worked just fine in a single-threaded environment. Unfortunately, I haven’t found any definitive info on whether it’s possible to call this function from a 2nd thread or not. This code listing has a very similar process inside the ‘textureWithName’ method (single threaded) in case you wish to see how it works.

Unless I come across something that shows how to use CGContextDrawImage correctly in a multi-threaded application I’m probably going to go the route of libpng. The portions of code I added have worked in regards to openGL so I believe I have that part solved, it’s just the data conversion from a file to raw bytes before openGL gets it’s hands on it is the problem.

Some Data You May Find Useful

My decision to use multiple threads for asset loading wasn’t based on any conceptions of a speed boost. If it loaded faster due to multi-threading that’d be great but it was secondary. I was doing it from a polish point of view and to make the whole experience on the user more seamless. So here’s a list of some data I’m working with:

  • 68 png images totaling 609kb. There is huge performance gain potential here when I implement texture atlases.
  • 22 audio (caf) files totaling 10.9Mb. Audio is certainly the majority of the game’s data, and I hope to reduce this by tweaking the compression on these files later.

Some load time data, don’t have the log files off hand at the moment so these are approximates:

[table id=1 /]

So the single threaded time is pretty straightforward. In the 2nd column it was my attempt to do both audio+graphics loading in a single background thread. After realizing I wouldn’t be able to fix this in time for the build I opted for a different multi-thread approach, which is shown in the 3rd column.

I load all the graphics assets on the main thread but just before I do that I spin off a background thread to load the audio assets. The result? Pretty much no performance gain! The graphics load in pretty much the same speed but audio loading takes twice as long while doing it at the same time as graphics loading. The net time is still around 7-8 seconds, which is no different than a single-threaded approach.

I’m sure I’m probably doing something dumb in the loading of both assets since both have to hit the file system at the same time and there may be some thread contention there, causing it to lock the audio thread. I’ll need to look into it further because if I could do both simultaneously with minimal blocking then this approach would be the way to go.

The visual result? The load screen animation freezes for 3-4 seconds at the beginning while loading the graphics, but once only the audio is left it starts to animate again. Not ideal, but it doesn’t crash. I’ll be working on getting it all on the background thread in the coming weeks.

Tilt To LiveWhen it comes to gui coding I don’t typically find it the most glamorous things to do. Particularly when dealing with games. You are left with writing a lot of boiler plate GUI code that is tightly integrated with your rendering pipeline. And even when I do find gui libraries for games they tend to try to emulate the OS in look and feel. When you want something lightweight and very interactive/animated you typically have to write it and integrate it yourself. If someone knows of a library for games that allows for versatile GUI development please leave a link in the comments :). When left unchecked, GUI code can end up being:

  1. messy and hard to maintain
  2. difficult to change
  3. rigid (basically just “functional” with very minimal style)

The GUI is one of the few remaining “big” items left on Tilt To Live’s to-do list. When imagining the GUI I had all sorts of crazy ideas for animations, transitions, interactions. Despite it being a relatively minor part of the game’s experience I still felt it important to really make it as polished as possible. Why? The GUI is the first thing a new user sees when launching a game (unless you’re Jonathon Blow’s Braid). It’s important to grab the user’s attention as soon as you can to make sure they give your game a fair shake.

Attention! Over Here! Look at Me!

In the mobile market you are fighting for pretty small attention spans. One of the design goals for Tilt To Live is to make it quick to play. Currently it takes one tap to start playing the game. I’m still working on reducing the initial load time. I even contemplated removing the requirement of ‘one tap’ to play, and to just drop the player into the game. When someone selects ‘Tilt To Live’ on the iPhone there’s a large chance they are simply wanting to play a quick game of Tilt To Live. In fact, other games like Spider: The Secret of Bryce Manor do just that and it’s actually quiet welcome. My only reservation is Tilt To Live may expand in the future to multiple game types so the ‘play from launch’ approach isn’t ideal if the desired game mode isn’t known with great certainty.

Either way, trying to get that good first impression on the user is very important. In addition to that, reducing the friction required to play your mobile game could possibly raise the game up beyond “I have nothing better to do” status and overtake other forms of gaming.


So back to GUI animations. Throughout the game I’ve used a hacked-together curve editing tool I wrote in Blitzmax to produce animations for items spawning, enemies popping up, etc. It works “well enough”, but the barrier to creating a new ‘curve’ was still high and it added to the total filesize of the game and was another asset to add to the app. So I revisited easing functions. I use some throughout the GUI system, but they aren’t very interesting. I started looking into alternatives and ended up with a rather nice solution.

Below is a work in progess video of the new easing functions in action on Tilt To Live’s menu UI:

A couple of years ago, Shawn Hargreaves had a really nice article explaining curve functions and how to use them in the context of GUI transitions using the XNA framework. It was a really nice primer to getting your hands wet with polynomial functions. Fast forward to today, I still have the basic “exponential” and “sigmoid” functions, but they were pretty boring in the scheme of things. Tilt To Live’s aesthetic is kind of cartoony so those functions weren’t very lively.

Having worked with Flash many years ago I knew it’s easing animation capabilities were very sophisticated, but I wanted to have some subset of that flexibility in my code as well, so off to Google I went. The best resource I found was Timothée Groleau’s Easing Function Generator. Not only did it have a nice set of preset easing functions, it generated the code to produce those exact curves! Wow, this was a huge time saver! For anyone that wishes to use these functions as well, the variables used in the function probably require a quick explanation:

  • t – the floating point time value from 0 to 1 (inclusive). If you want the position on the curve half way through the transition then you pass ‘0.5’ through t.
  • b – the starting position. In a one dimensional setting this is the value you would get if t = 0.
  • c – the ‘change’ in position. So if you want to transition from 34 to 56 then c = (56-34) = 13. (more on this later)
  • d – duration of the transition. If you want the transition to last, for example, 2 seconds then d= 2.

With that actionscript function generator it’s pretty trivial to implement it in any other language (as in my case, C). Although my GUI transitions aren’t based off of changes in position, but off of start and end positions. So my typical transition function signature looks like Transition(startPosition, endPosition, delta). Below is an example implementation in C:

float EaseOutElastic(float startVal, float endVal, float blend)
float diff = endVal – startVal;
float tsquared = blend * blend;
float tcubed = tsquared * blend;
return startVal + diff*(33*tcubed*tsquared – 106*tsquared*tsquared + 126*tcubed – 67*tsquared + 15*blend);

The result:

  • Much more interesting GUI transitions
  • No extra assets as curves are procedural
  • Can re-use curves in different types of animations (position, scaling, rotation, etc)

When I’m doing a polish phase on the GUI of a game or animations, sounds, etc I’m often reminded of the tidbit from Kyle Gabler’s  Gamasutra article about prototyping: Make it Juicy. Using easing functions to add a bit of bounciness, juiciness, and overall personality to a game can really help make the game feel more alive…feel more…juicy.

Tilt To Live

Some days it takes a herculean effort to force myself to sit down and work on my game. Some weeks it can be destructive to my entire schedule, while others its a complete non-issue. Overtime I’ve found prioritizing my tasks wasn’t enough to really Get Things Done. I needed a way to organize my daily tasks in such a way that would maximize my motivation to actually work that day, particularly after coming home from my day job. By taking my top priority items and then sorting them from easiest/most fun to hardest/most boring I think has helped my overall productivity.

I’ve resisted the temptation to try to squeeze in and finish off any low hanging fruit when I’m finishing up for the day and leaving it for the next session. Why? It increases the chances that I start on time the next day and get ‘into the zone’ faster for when I need to really concentrate on the harder bugs and features later into the day. It’s much easier for me to come back to an easy fix or feature. Whenever I have a really hard bug I tend to dread working on it before I’ve even sat down at the computer. Sometimes this can’t be avoided as some bugs can take days of work to finally be fixed, especially if you’re on a very limited time schedule with a day job and other obligations. I haven’t met many people who look forward to debugging some crazy hard bug when they start their day’s work. Once over the ‘hump’ when you’ve settled into just doing the easy things you can quickly ramp up and tackle the hard problems on your to-do with little fuss.

But when the day (or in my case, the night) is winding down, I try to save away some of those easy or fun 5 minute tasks for the next day to really help motivate me into starting on time. As for other tips on game development project motivation and such, instead of going into other aspects of it I’ll just link you guys to a post by Jake Birkett, of Grey Alien Games, that sums it up very nicely for indies looking to get ‘serious’ about their game development business. In particular, this bit:

I’ve run out of motivation

Well perhaps game programming isn’t for you but some other aspect of game production is? But maybe you just need to re-motivate yourself! There’s plenty of stuff about this all over the Internet. Try doing something that inspired you to make games in the first place – perhaps you need to play some of your favourite games, or boot up an emulator and play some old classics, or read some stories about other people’s success, or make a little fun minigame, or listen to some Commodore 64 tunes or Euphoric Trance music. Whatever gets you back into that space where you really want to have fun making and selling a game! Be sure to REPEAT this process whenever you feel your motivation dip.

Having a plan really helps out as you can chart your progress and see clearly what you need to do next. Also if you feel unmotivated, just START something, anything on your project and 5-10 minutes later you’ll probably be really into it.

That last bit is very important and speaks to the issues I encounter most often. For me, that ‘something’ is usually a 5-15 minute fun/easy high priority task that needs to get done. Planning this ahead of time helps as staring at a list of tasks and ‘cherry-picking’ when I’m in a state of lousy motivation usually ends up with me picking things that don’t need to get done right away and leaving more important tasks to linger on the list. Game development isn’t all fun, but with a little forethought and planning you can really help minimize the mundane feeling parts of software development.

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.

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…

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).