SIEGE has just recieved a new feature – one which was present in its D “ancestor”, but took quite until now to implement in C (it’s a long story why) – namely, physics collision callbacks.

True, they are not 100% complete yet (the post-step is still missing) and an important feature is still missing (namely, removing of physical bodies from within callbacks), but so far, so good!

The physics demo has been updated to handle the callbacks. Hit the F1 key to see:

• collision points at beginning of collision
• distances and normals (green lines)
• objects which are currently colliding (red-colored objects)

Firstly, I’d like to apologize for posting no news for so long… I’ve always been waiting until a feature is “ready” so that I can announce it as completed – and then I end up forgetting to update the site.

Anyways, on to the news – there are 3 things that SIEGE has gained recently, plus one which it had but was never officially tested before:

1. C99 standards compliance – SIEGE is now almost fully C99 standard-compliant – it is not (and cannot be) 100% simply because of its use of the POSIX function dlsym, which returns a void* pointer instead of a function pointer – there is no way to convert a void* pointer to a function pointer in ISO C99. Nevertheless, most (if not all) compilers on POSIX-compatiable architectures compile this just fine – and it works just fine (in fact, POSIX 2008 states that the direct conversion must be possible).
2. SIEGE now compiles out-of-the-box on OS X – it has always previously compiled with some changes (such as replacing “#include <GL/gl.h>” with “#include <OpenGL/gl.h>”), but with the recent updates, it compiles without any changes whatsoever (provided that the dependencies are present, of course). To fetch this version, see SIEGE repository info on Gitorious.
3. Added an IConv module and with it support for wchar_t, UTF-8, UTF-16 and UTF-32 strings. Here is a screenshot:
   
4. I have tested compiling SIEGE with Clang for the first time and it worked outright – no warnings, no errors. Therefore, I can finally say that SIEGE officially compiles with both GCC and Clang.

That’s all as far as new features in the main branch go… However, there is work going on in other branches. Two such things high on the list are:

1. SIEGE console – an ingame console, along with features such as history, colors, etc… Note that the console is still in early stages of development.
   

   Early screenshot

2. Lighting – in-engine support for 2D dynamic lights, along with support for shadows, different light “heights” (for non-infinite length shadows) and caching (precalculated values for static lights and shadows).
   

To finish today’s triple-posting:

I’ve put the SIEGE logos (and their WiP – now obsolete – drafts) into Git; they are available in the misc/artwork/logos directory, in SVG form. I’ll add the PNG logos into a separate page on this website.

The other (cube) logo is still pending…

For those waiting, the A* example is finally in Git – it took me a while to do it because I’ve been pretty busy (sorry!).

It’s available in Git in src/examples/astar.c. Furthermore, it is built by default during the SIEGE build process (that is, unless it’s manually disabled) and builds into the “bin/Example-AStar” binary.

The example is rather crude at the moment because I didn’t have much time to make it, well, better. Maybe I’ll make a minigame out of it?

UPDATE 2011/03/31: A memory leak and crash at exit at have been found in the A* example (due to errors in the navgrid implementation itself) and corrected – thanks bernardh for bringing the problem to my attention!

A new SIEGE build type is around – namely, non-monolithic SIEGE.

Don’t worry, the “monolithic” build is not going anywhere, it’s still staying around; on the other hand, the non-monolithic build will enable you to only link to (and bundle/use) one component of SIEGE, plus its dependencies, instead of the whole thing.

So, if you only need SIEGE’s audio, you’ll only need to link to SIEGE Audio and module loading (and possibly util).

The A* search algorithm implementation and the navigation grid (previously path grid) have been in the “astar” branch for quite a while… I’ve finally sorted things out and now they’ve been merged into master.

I don’t have any examples yet, but do note one thing – the A* implementation is a generic one, which means that it isn’t bound to any form; it works on a set of nodes, which it considers as fully abstract objects. In other words, it doesn’t care whether the nodes represent a grid, a node graph in a mathematical sense or, indeed, apples and oranges, long as there exists a cost function between two different nodes.

Both the cost and the heuristic (predicted cost, which must be optimistic – that is, lower or equal to the actual cost – in order for the algorithm to work correctly) are passed in as callbacks, which means that the user can provide whatever he wants for the cost. Furthermore, checking whether a node is the goal is also performed via a function, so one can, for example, have multiple goals.

That said, if the user doesn’t provide such functions, the algorithm tries to use decent predictions – the cost between two nodes is assumed to be 1, and the heuristic is assumed to be 0, essentially making this a breadth-first search. Why 0? This prevents cases of the user providing a cost function returning values lower than 1, with the heuristic assuming 1 – it would break the algorithm, which would return a suboptimal (not shortest/lowest cost) path. A similar assumption is made for the goal node – a node is assumed to be the goal if they are the same references, something which is not completely necessarry when “custom” functions are provided (indeed, it completely depends on the function at hand).

Hopefully, I’ll find some time to scribble together a couple of demos.

Just now, I’ve removed 4 bugs from SIEGE (they were found quickly with a bit of help of Valgrind) – this means that SIEGE now exits with no memory leaks whatsoever (well, none that Valgrind could find with the app I tested with) and that it’s clean on the Valgrind end.

(more…)

Minor update this time – the functionality to draw arcs has been added this time – this means that SIEGE can now draw an arbitrary arc (elliptic as well), as opposed to merely circles and ellipses:

Current circle and ellipse-drawing code has been modified to use this instead.

Indeed, it is a small update, however work is being done on other things (it’s nearing completion) – coming soon – per-pixel collision detection and a generic implementation of the A* search algorithm (also a wrapper over it for grid-based pathfinding).

For the implementation, see the sources on Gitorious – note that the implementation may be done with the help of rational splines once those are added to SIEGE.

Alright, I’ve done some minor changes to SIEGE, boosting the version to 0.1.8:

• sgLoadModules(char** modules) has been changed to sgLoadModules(int n, …) where n is the number of modules to load, followed by the modules themselves.
• A lot of functions which take a filename for input have been changed from accepting char* into const char* as the first argument (for example, sgLoadModule).
• SGLinkedList has been renamed to SGList (I’ve intended to do that before, but I simply forgot) – thus, SGLinkedNode is now SGListNode.

I’ve also added a link to the siege documentation – N3o (aka Th3On3, the other SIEGE dev) has kindly brought up to my attention that I forgot to put up a link to it on this site, and well, here it is! You can also find it in the site menu. Please note, however, that the documentation is a work in progress.

There is still tons to do, however:

• AI:
  • Pathfinding (navmeshes, for example)
  • Fuzzy Logic
  • Artificial Neural Networks
  • Genetic Algorithms
• Per-pixel collision detection
• Performance-related:
  • FPS counter
  • Profiling tools
• Threading (not 100% certain that we’ll add that)
• Unicode rendered text support (probably via libiconv via a module)

…apart from longer-term plans such as networking.