Well, another change to SIEGE, this time without screenshots — namely, SIEGE has now received public domain image (via stb_image) and OGG Vorbis (via stb_vorbis) loading!

All the example programs have been modified to use this instead now, to be able to use SIEGE with image, audio (and, from before, font) loading without any external libraries!

A couple of days ago, SIEGE has received Public Domain font rendering via the excellent stb_truetype library; other improvements have been added to both the STB and Freetype modules and implementations, however:

• Kerning has been implemented
• User-provided DPI setting for glyph rendering (default is 96)
• Loading fonts from generic streams (SGStream — see the previous post)
• Major cleanup of text-rendering and related (text size, offset position, …) functions in siege/graphics/font.c
• Fixed a bug with rendering artefacts on the left-hand side of some glyphs

The new module is named “STB-TrueType” — in order to use it, simply replace “Freetype” in the sgLoadModule() call with “STB-TrueType”.

The changes are spread across multiple commits, but this is the largest: https://github.com/SIEGE/siege/commit/34e31681738a7b4b479780a8c7069f50acbc6be6.

And finally, a screenshot of the new module in action with all the improvements:

As you may have noticed, the new module does create a bit more “blurry” text, which may be (depending on the situation and the style of the game) a good or a bad thing. If that is a problem, simply use the Freetype module, which is still available (and will be available — I have no intention of removing it). I will probably be changing all the SIEGE examples to use this by default for one very simple reason — no external dependencies, everything is included with the module.

SIEGE has just received a new feature — streams. They allow the user to load, say, textures and audio, directly from sockets, memory and whatnot, without any issues.

Of course, existing functions will remain for loading, as it is much more convenient to simply use the file load function rather than who-knows-what when advanced functionality isn’t required; internally, it now all uses streams, however.

The API is very simple and can be seen here: https://github.com/SIEGE/siege/blob/master/include/siege/util/stream.h.

SIEGE version 0.7.0 is out! The following features have been added or changed:

• evDraw is now called between evTick and evTickEnd — this allows the user to do things after the drawing has already been completed, in preparation for the next tick.
• SGBank has been added for resource management. This is a conveniency wrapper which allows the programmer to load resources on-demand. For example:

// try data/sprites/<name>.png and data/sprites/<name>.jpg in sequence
SGBank* sprites = sgBankCreate("data/sprites/%s.png|data/sprites/%s.jpg", loadSprite, unloadSprite);

// data/sprites/player.png or data/sprites/player.jpg
// NULL is an opaque data pointer, passed in to loadSprite
SGSprite* player1 = sgBankLoad(sprites, "player", NULL);

// ...

// "player" has already been loaded, so we return that sprite instead of loading again
SGSprite* player2 = sgBankLoad(sprites, "player", NULL);

// automatically calls unloadSprite for each loaded image
sgBankDestroy(sprites);

• SGEntity now has an (optional) name, so that entities can be looked up by name.

sgEntitySetName(tanks[0], "tank");
sgEntitySetName(tanks[1], "tank");

// ...

SGList* tanks = sgEntityFind("tank");

• sgDrawSetAlphaTest and sgDrawSetAlphaFunc have been added, which enable the use of some interesting effects such as metaballs
• Timers for easier handling of timed things (examples being animations, gun reload times, timed doors, elevators, …)
• Texture atlases (they are not yet used within SIEGE, so they are mostly useless, but they will eventually be used for sprites and fonts)
• Other minor changes and fixes

Hey there, no updates in a while, I know.

SIEGE has gone through quite a lot of refactoring and updates — to name a few:

• joystick support has been completed (note: POV-hats are still not supported, I’ll get to those later)
• Entity priorities have been removed, which means that entity creation and destruction is now O(1) instead of O(n)
• SGEvent, which was never ever used by anyone (not counting uses within SIEGE) has been removed and merged into SGEntity

There are still some minor changes to be done with events, socket support has to be finished and texture atlases + sprite sheets added to the engine; the latter (sprite sheets) should make loading sprite animations, tilesets, etc… much easier than earlier.

New updates bring SIEGE to version 0.4.0:

• initialization has been changed so that it no longer opens a window by itself (thus, the number of parameters has been reduced to 1 – flags)
• new API added to leverage SIEGE’s image loading functionality directly
• window icon functionality added (by request from bernardh)

Here’s a short example of the new API:

// old initialization
// sgInit(width, height, bpp, flags);

// new initialization (we'll open the window later)
sgInit(flags);

// image loading
SGImageData* idata = sgImageDataCreateFile("data/sprites/whatever.png");
/*
 * Set the icon (this has to be done *before* the window is opened).
 * Note that in Windows, this is required to be 32x32; also note that there might
 * be some changes in the API in the future.
 */
sgWindowSetIcon(idata);
sgImageDataDestroy(idata);

// now we can finally open the window!
sgWindowOpen(width, height, bpp, flags);

And finally, a screenshot:

Example of the window icon functionality in SIEGE - note the small yellow icon in the top-left.

If you haven’t been able to reach the website during the last few days, it was due to DNS propagation and because I’ve been fiddling with the new server.

And by fiddling, I mean that the website has been moved to a new server, and I still had (and have) to configure some things. You’ll also notice that the theme is currently semi-broken (the title bar, for example, should have a dark background) – I’m working on that.

The good news is that SIEGE is now on a much better server than before (it’s a dedicated server), which means that I’ll be able to put up, say, a bugtracker which doesn’t use PHP (there’s a lot to choose from though).

SIEGE has just (well, actually a few days ago) received new functionality, all related to threading. The following are now available:

• threads (suprise, suprise!)
• thread-local storage
• mutexes
• semaphores

The API is cross-platform – it works both in Windows and on POSIX systems. I won’t be quoting all the functions added here because there is quite a lot of those – if you want to see all of them, check out these files: /include/siege/util/thread.h, /include/siege/util/threadkey.h, /include/siege/util/mutex.h and /include/siege/util/semaphore.h.

As you may know, SIEGE does not actually use threads – yet, so what do I need this API for? Well, I’m working on getting a separate rendering thread running in SIEGE (optional, controlled by a flag, so you don’t have to worry about thread-safety if you don’t want to and instead disable multithreading). Furthermore, I want to eventually make SIEGE completely event-based (again, controlled by flags) so that event handlers can run from a thread pool and use messages for communication.

Until now, the module search path has been hardcoded to the “modules” directory; I have now changed that so that it can be changed by the user. Furthermore, multiple paths can be provided – if SIEGE cannot find the module in the first path, it continues seeking in the second path and so on.

Furthermore, four new functions are added:

/*
 * Try "ndirs" directories in order - if the module cannot be found in the first,
 * continue to second, if it's not there, continue to third, et cetera...
 *
 * Up to 256 directories can be provided.
 */
void sgModuleSetLoadDirsv(size_t ndirs, va_list args);
void sgModuleSetLoadDirs(size_t ndirs, ...);
// same as calling sgModuleSetLoadDirs(1, dir)
void sgModuleSetLoadDir(const char* dir);
// get the current list of dirs
char** sgModuleGetLoadDirs(size_t* ndirs);

I am also going to un-hardcode the prefix (the “[lib]SGModule-” bit) soon.

UPDATE: The prefixes are now un-hardcoded (though the code hasn’t been tested well); the API is similar to the directories, only replace “Dir”/”Dirs” with “Prefix”/”Prefixes”.

Until recently, SIEGE Util (sources and headers in siege/util/*) have depended on SIEGE core to initialize them – not anymore – now they work perfectly fine without the core. This marks an important first step in getting SIEGE into a less monolithic state, so that (say) its pathfinding code can be used as a separate library.

There are a few cases where util depends on, say, modules (which currently depend on core) – for example, conv.c which requires an iconv module – but I have plans on fixing this and getting modules independent as well.

Here is the relevant commit: https://github.com/SIEGE/siege/commit/bd8d77a1651099eac809c0aae58623fa1fa10144.

UPDATE: SIEGE-Modules do not depend on core for initialization anymore. Commit: https://github.com/SIEGE/siege/commit/03c578bf8bc04f83c6d3c945a770874fd00af642

Okay, I’ve decided to stop looking for a better API for lights and just put them into master.

Here are the relevant commits:

• https://github.com/SIEGE/siege/commit/09bcf4a8bccceac52b9bc11247429a5226879382
• https://github.com/SIEGE/siege/commit/e35e6d32cfd08451215879376409a0e238136406

Some changes are still pending, but the API is going to remain as it is, at least for the time being.

Yesterday, I’ve migrated SIEGE from Gitorious to GitHub – I have good reasons to do so, but I will not discuss them here.

SIEGE is now located on this GitHub page: https://github.com/SIEGE. The Gitorious repository will be kept for a while and perhaps even updated once in a while – exactly how often (if at all) I will update it and for how long will I keep the repository, I do not know.

SIEGE has just got a new feature – gradients.

SGGradient is a new structure which holds the data for a gradient – a smooth (or, depending on interpolation, not-so-smooth) transition of colors on a scale from 0.0 to 1.0 – of course, stops can be added in between, so that you can go from, say, 0.75 past 0.25 to 1.0. The gradients are (by design) not limited to color information, but can hold any form of info – for example, a heightmap for a side-scroller could be stored in this way. SGColorGradient will be added later on, and will be a “specialization” of SGGradient for RGBA color info.

For those wondering how to use this functionality, here is an example:

// creates a gradient with two stops: (0.0 -> 0.0) and (1.0 -> 1.0)
SGGradient* grad = sgGradientCreate();

/*
    Add some stops; note that the stops at
    0.00 and 1.00 are automatically replaced
*/
sgGradientSetStopKey(grad, 0.00, 1.00); // 0.00 -> 1.00
sgGradientSetStopKey(grad, 0.25, 0.75); // 0.25 -> 0.75
sgGradientSetStopKey(grad, 0.75, 0.00); // 0.75 -> 0.00
sgGradientSetStopKey(grad, 1.00, 0.50); // 1.00 -> 0.50

// ...
// draw the gradient...
size_t i;
for(i = 0; i < 640; i += 16)
{
    // grayscale gradient color: rgba(g, g, g, 0.0)
    sgDrawColor1f(sgGradientGetValue(grad, i / 640.0));
    sgDrawRectangleWH(i, 0, 16, 480, SG_TRUE);
}
// ...

sgGradientDestroy(grad);

…and that’s about it regarding the use! Here is a screenshot of the gradients in action (note: this is not the same gradient as the above code):

Interpolations from top to bottom: Nearest-neighbour, linear, cosine, cubic - custom interpolation functions are supported. Dim orange lines are stops.

Now that gradients are settled, onto the 2nd update: SGFont API change.

Until now, SGFont had a LOT of different functions for printing:

sgFontPrintCentered*
sgFontPrintXCentered*
sgFontPrintYCentered*

All of these had 9 variants, for a total of 27 functions. They have all been replaced with a set of new functions, sgFontPrintAligned*:

void sgFontPrintAligned(SGFont* font, float x, float y, SGenum align, const char* text);

// example:
// print X-cented, but on the Y baseline
sgFontPrintAligned(myfont, 320, 240, SG_ALIGN_CENTER | SG_ALIGN_BASELINE, "Hello, font world!");

// the following constants are available:
// SG_ALIGN_CENTER   - x or y-centered (used for both because its value is 0)
// SG_ALIGN_LEFT     - left-aligned on x
// SG_ALIGN_RIGHT    - right-aligned on x
// SG_ALIGN_TOP      - top-aligned on y
// SG_ALIGN_BASELINE - baseline-aligned on y
// SG_ALIGN_BOTTOM   - bottom-aligned on y

…plus variants. The “old” functions still exist, but they have been deprecated and are scheduled to be removed soon (since most are almost unused, very soon) without notice whatsoever.

Yes, there are more arguments to pass, but it is much more flexible – for example, there existed no way to print right-, top- or bottom-aligned text – there was only left/center on x and center/baseline on y. Furthermore, a switch was previous required in case certain alignments were required under certain conditions (to make sure the right function is called) – now, it is only a matter of a different argument.

Well, that pretty much concludes today’s post – I hope the new gradients and font drawing functionality will come in handy!

SIEGE has been without audio for quite some time, pending correction of a couple of bugs – this took quite a long while simply because I couldn’t get the bugs fixed earlier. I’ve corrected the breaking bug now, however and even some other bugs in audio, so it now works!

You can check it out in the “audio” example, but make sure you have FLAC and Vorbis libraries installed or else you will get silence since it won’t know how to load the audio files.

Streaming is not yet supported – the audio has to be preloaded as a whole – but it is planned.

There is one more feature, however, which is designed to ease the creation of “fire and forget” sound effects – sgAudioSourceDestroyLazy. You can find an example of use in the aforementioned “audio” example, but here it is for those who don’t want to bother checking:

void createExplosion(SGAudioBuffer* buffer)
{
    /*
     * Explosions are:
     * - high-priority sounds (10.0 priority)
     * - loud (1.0 volume)
     * - "powerful" (pitch reduced to 0.5 to make it sound "deeper")
     * - non-looping (looping set to SG_FALSE)
     */
    SGAudioSource* source = sgAudioSourceCreate(10.0, 1.0, 0.5, SG_FALSE);
    sgAudioSourceQueueBuffer(source, buffer);
    sgAudioSourcePlay(source);

    /*
     * Newest addition - this will wait until the source
     * stops playing (looping is automatically set to SG_FALSE)
     * and then destroy the source.
     */
    sgAudioSourceDestroyLazy(source);
}

A minor update this time – hold on to your seats though because more is coming soon!

Here are some of new features that SIEGE has got:

• Particle system, created by tshirtman
• AA trees (also known as Andersson trees) for mapping of value->value
• FPS counter, frame limiter and high-precision time/sleep functions – created by bernardh
• Depth testing can now be toggled
• Drawing of smooth points, lines and polygons can now be toggled
• New “Pyramid” example

As always, there are also a couple of bugfixes and other misc. changes here and there.

Screenshots for the particle system will follow later, as I have yet to create a good demo for the feature.

Okay, more news are in regarding SIEGE physics – new features which will make the physics engine way more powerful now.

Here they are, roughly in chronological order of introduction:

• Physics shapes now have settable groups (shapes of the same group do not interact), friction and restitution (elasticity)
• Constraints are added (although they are still heavily work-in-progress), meaning that two bodies can now be linked together properly
• A bug has been fixed – if a body is attached to no entity, it will crash in the collision callback handler as it tries to dereference a NULL pointer
• Each physics space now comes with a default “static body” – one which has no shapes by default, but has infinite mass and moment of inertia, to be used as a base for static shapes. Of course, creation of static bodies in “the old fashioned way” still works perfectly fine.

There are some unrelated fixes as well:

• An unrelated bug has also been fixed with mouse handling in SDL (press/release events now work properly)
• “Normal” keyboard and mouse events (those without Press/Release/Repeat) now work as expected – they are triggered at every tick as they should be

I’ll try to throw a demo together shortly.

Here is the commit: https://gitorious.org/siege/siege/commit/d03d563d1873a2c9fb72b0e6c30191d7471fbd04

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 ” with “#include ”), 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

  * 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).  
    [<img class="aligncenter size-medium wp-image-293" title="SIEGE Lighting" src="https://libsiege.org/wp-content/uploads/2011/05/siege_shadows_3-300x235.png" alt="A screenshot of SIEGE lights along with shadows" width="300" height="235" />][3]</ol>

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…

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

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!

If you asked this website “did you do something to your hair?” you might not be far from truth, because as you may have noticed, the color scheme of the website has changed. The most obvious change is the title bar, but almost all the colors have been changed; for example, text got a hint of orange into it – not much, just a hint.

Furthermore, SIEGE now finally has a logo! You can see it on the top-left, that “libSIEGE” thing with an “SG” below it – there are two more variants of the logo, however, for a total of three (plus one coming, so that’s four).

The first variant is the color version — the one you can see on top:

Next up is the first grayscale variant, meant to be displayed on a white background:

…and one meant to be displayed on a black background (note: it may look ugly here because it is a transparent PNG, and the webpage background is not black!):

The logo that will follow will be one with an image of a cube with “lib” and “SG” somewhere on it.

All the variants will be put (in SVG form) into the Git repository… Why SVG? It’s easily scalable without data loss and it can (in some cases – such as this) be described with a set of polygons (which can be easily rendered).

Special thanks for all these logos go to Landon Tuff aka Toxshox (clickety for his blog) who has offered to make the logos – and he (obviously) delivered. It took me ages to find someone to make a logo for SIEGE – I did find some people before, but they’d all bail out, sometimes before even starting work on anything… Therefore, again – thanks!

I’ve finally had it with the old host with non-working subdomains and sometimes domains – SIEGE is now on a brand new host, which, although more expensive, is also (at least according to my first impressions) much more reliable.

Note that subdomains may still be inaccessiable for the next couple of hours while the DNS cache gets flushed on the nameservers – you can try doing it manually if you want, but it may/may not help depending on the settings of your PC, router and external nameserver (most likely that of your ISP).

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.

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.

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.

The first two bugs were in the implementation of SGList (linked lists) – in freeing of the list:

if(list->internalFree != NULL;
    list->internalFree(list->internal);

…and an individual node:

if(node->internalFree != NULL;
    node->internalFree(node->internal);

This normally isn’t a problem, however the issue is that neither internalFree was set anywhere – that means that “internalFree” was undefined (could have any value), and as such, the program would segfault on exit.

The other problem was in deinit of viewports and the modules – both had code which was similar to this:

SGListNode* node;
for(node = _sg_viewList->first; node != NULL; node = node->next)
    sgViewportDestroy(node->item);

Look carefully – the viewport at the node is destroyed (which also destroys the node), after which “node = node->next” is ran – by that time, the previous node has been free’d, and its contents are thus undefined. The solution was simple:

SGListNode* node;
SGListNode* next;
for(node = _sg_viewList->first; node != NULL; node = next)
{
    next = node->next;
    sgViewportDestroy(node->item);
}

So there you have it – the problems which were pestering SIEGE’s otherwise clean shutdown are now gone.

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.

I’ve just corrected SIEGE’s CMakeLists.txt so that CPack now “agrees” with SIEGE completely – this means that SIEGE binary distributions are possible (and simple) via CPack, apart from source distributions, which worked fine before.

I’ll see to it that binaries (and sources) get uploaded somewhere, I’ll most likely use SourceForge for the files, but mirror them here.

Stay tuned for the first uploaded & zipped (as opposed to available via Git or SVN) binary distribution!
**UPDATE 18:43 UTC: **The downloads are up – you can find them here.

Here is the commit: https://gitorious.org/siege/siege/commit/4e88916cf6b50915a039dc85d320624dbfb15320.

I have decided to change to a different theme. Although the old theme was awesome, it had two problems – it was fixed width, which means it didn’t scale well across different resolutions and the central column was way too narrow.

I’m still poking around for different themes (in hopes of finding an even better one), but for now, this one will do.

Okay, third post today. Sorry.

I like minimalistic licenses, and to that point I’ve considered relicensing SIEGE to the even simpler 2-clause BSD license (as opposed to the 3-clause license, which is usually called the “BSD license”) – it is the same variation of the BSD license as that which is employed by FreeBSD.

I’ve talked to Th3On3 (him being the only active developer of SIEGE, not considering non-code artwork) have agreed that SIEGE is to be relicensed to the 2-clause BSD license, as opposed to the 3-clause license used so far (you can find more about that on Wikipedia). This makes the license even shorter and thus more simple.

I have also relicensed it to the so-called “SIEGE Development Team” as opposed to myself. I think the licensing to yours truly dates back to the times when Th3On3 was not on board the project yet, and thus I was the only developer – hence the holder.

Furthermore, I have added a license notice to most of the SIEGE source files – took me a while, but it had to be done eventually, and since I was at it, why the hell not. Here’s the link to the commit: https://gitorious.org/siege/siege/commit/3108ad36f938fc9db93b3ec402a36922bb03a2a5.

Here is the online copy of the license: linky.

Well, migration to Git is pretty much complete now. I have (after a rather large discussion about SourceForge and different alternatives to it) opted to use Gitorious for the project – it is similar to GitHub, except that the stack behind it is completely non-proprietary.

I’ll admit, there have been hiccups here and there, mostly due to Git not importing svn branches (or tags, for that matter) properly. I have gotten around those and the repository seems to be happy with its current state – I know I am.

So, from now on, you’ll be able to find SIEGE on Git at Gitorious. I’ll be leaving the SVN repository up for a while as there are errands to do – I have to zip together tags and upload them somewhere, for one.

Yes, I realize this post is right after the previous, but I’ve decided to put different things separately this time.

I have finally streamlined the SIEGE build process, meaning that the whole thing can now be built with one single invocation of the cmake/make combo (as opposed to two + copy). This opens a door for CPack, and I have already played with it, creating CPack-generated source distributions – sadly, binary distributions don’t work yet (CPack creates empty archives), but it’s a start…

I’ve recently had a rather bad experience with merging different branches in Subversion, which made me finally decide to migrate SIEGE to Git.

I’ve been hearing nice things about it, and myself had a privilege of trying it out. Git was originally designed and developed by Linus Torvalds (the same guy responsible for the Linux kernel) for development of the kernel – so if it was made by him and if it’s good enough for kernel devel, it ought to be good enough for SIEGE, right?

Of course, as with anything, there is a catch – SourceForge does not support the use of Trac’s source browser and whatnot with Git, which means that Trac has lost a bit more of its usefulness for me – I’ve only used it for bugtracking and source browsing, and this leaves only bugtracking.

That is the reason why I’m trying out a new bugtracker, namely MantisBT (**UPDATE 2010/10/01: **I’ve decided to switch to WordPress Quality Control) – you can find it at bugs.libsiege.org, although I do have to tinker with the settings a bit, still. I have been considering using Trac as the wiki, however, as I haven’t been too happy with MediaWiki – maybe I’ll end up using Trac in the end anyways if I can persuade my webhost that it would be a neat thing to be able to use this… Either them or SF.net staff. Hmm…

Well, as far as the migration to Git goes, I don’t know when will it happen (I have to find out if I can persuade my host first, and so on), but it will in the near future. I may leave Subversion up for some time after that, but I don’t know for how long.

… that said, using Github is not completely out of the question …

I’ve been “porting” the documentation from D to C. It’s been hard work, but here are some of the results:

• Modules/Simple tutorial (note that it was changed to load a BMP now, instead of nonsensial images)
• HelloWorld tutorial
• Online HTML documentation

They are a bit messy at the moment, but work is continuing in improving this. I’ve also been battling Wiki spam though, which is why I’ve added the CAPTCHA – it should filter out at least some of the spam. The HTML documentation was created with Doxygen, but I’ve been playing with breathe – a tool which takes Doxygen’s XML as input and outputs something usable with Sphinx, a very nice documentation generator (Python docs use it).

One tutorial was “ported” earlier, but I should note it anyways: The Configuring tutorial.

I’ve also been working on CPython bindings – for those that do not know, CPython is the official, and most popular Python implementation – if you’re using Python, you’re probably using CPython. I haven’t been able to get the deinit working correctly yet, and it’s a possibility that I may have to embed Python in a thin wrapper just so that I can use it properly with SIEGE.

Furthermore, I’ve been thinking of binding SIEGE to a whole variety of languages, including (but not limited to) Ruby, Pike, AngelScript, etc… Even Scheme (because TinyScheme is easy to bind). I’m looking for a good language to bind SIEGE to, so if anyone has any idea, do tell – just don’t say Lua, I really don’t like it.

I have created the beginning of what will become C++ and D bindings.

Oh, one more thing – I’m still (and constantly) looking for devs willing to help with SIEGE (especially someone to maintain the C++ bindings!) – if you’re up to it, do drop me a mail.

I’ve moved the SIEGE website from e107 to WordPress, mainly due to security issues with e107 which could not be fixed (they were related to the contact form and the plugin meant to replace it did not work).

I’ll be moving the older news here as well.

It’s been too long since I’ve last updated this website.

However, believe it or not, me and Th3on3 have been busy developing SIEGE.

The wiki was finally put to use with some tutorials, in addition of which we now have Trac for bugtracking and source viewing (Trac’s wiki will not be used), in addition to generated documentation from the code.

Yes, I know I’ve promised SIEGE to go Alpha, but that promise has been delayed because I wanted to do bindings to a scripting language first. It seems that the bindings will have to wait…

There is an experimental port of SIEGE to C going on – if it is successful, this will replace much of the current D frontend. Instead, it will pave the way for multiple frontends – D, C++ and Python, for example.

Perhaps I should wait to see how CSiege goes before calling this one alpha, since CSiege is a big rewrite. Luckily, it doesn’t all have to happen in one go.

The SIEGE modules are now fully migrated to CMake (SIEGE itself not, because of problems with CMakeD, a CMake module for D) and SDL is now the primary backend for windowing and input — this is because GLFW refuses to cooperate in Linux.

Also, I’ve been looking for a good replacement for OpenAL. It would seem that OAL does not want to cooperate properly with ALSA (instead chooses to only work with OSS) on some PC’s. It’s also been giving me some trouble in Windows, not only Linux.

If anyone has any suggestions for other cross-platform audio APIs, I’m listening — just note that I’ve already looked at SDL_sound, SDL_mixer and FMOD.

Furthermore, I am still looking for developers. Right now, I’d need someone to build & test things in 32-bit Linux, someone to do the same for MacOS and then someone for whatever OS they’d like to see SIEGE work in.

If you want to contact us, the contact link is to the left; sometimes we can be found in #gamecraft on Freenode. A Java web client is available: irc.libsiege.org. Furthermore, there is a mailing list available, you’ll find its link at the bottom of any of the tutorials in the wiki; I’d prefer not to write it here for anti-spam reasons.

It’s been a long time with seemingly no development — but believe me when I say that we’ve been working hard.

SIEGE, which is the working title of the engine behind GameCraft is almost ready for alpha stage.

SIEGE went through two completely different designs, and now it is an event-based layer with an interchangeable backend. Right now, only OpenGL backend is available, but more are planned.

Once they are done, the same frontend will run OpenGL, Direct3D, SDL, Mesa, even PSP (Playstation Portable)!

What’s left are (very) minor changes to parts of the API, to clean it up and make it easier to use.

A demo will follow soon, but first, the bindings to Monster Script must be done.

Also, three(!) developers have expressed interest in helping code SIEGE and perhaps later GameCraft – two programmers and one artist.

The programmers have to learn D first, but they have agreed to help, and the artist is working on a logo.

I’ve added RSS feeds to keep track of the news on the website. They are available here or in the menu on the left.
Please note that I may remove the “comments” feeds later.

At last, GameCraft has a scripting language. The interpreter creation has stopped, because I’ve found a scripting language which was very similar to what GCScript would have became.

I am now cooperating with Nicolay Korslund, the creator of Monster – giving him some ideas for future development and similar.

More information on the scripting language can be found here.

Also, I’ve found a physics engine for use with GameCraft. It is called Blaze, and it has all the features that the engine will need.

I am also in cooperation with the creator of the physics engine, Mason Green. I am going to port the engine to Phobos, the official standard library for D (at the moment, it is only available for Tango, the alternative standard library).

If you would like to know more about the engine, see the project page on dsource.

So far, I’m pretty much the only guy working GameCraft (see below for others). While I’ve been making progress, it was much slower than what it could have been.

I could use another pair of hands to help me out.

Me and Th30n3 are now working on the GCEngine part, currently the organization and design (how the functions are named, how they are put into modules and similar)

Here are the positions that are yet to be filled:

• Vector Graphics Designer – Someone to create a logo and an icon for the program and its filetypes. They should be in Tango style.
• GUI Designer – Designer the graphical interface of the IDE
• D Programmer – If I have another pair of hands helping me, the progress will be faster
• Article Writer – Someone to write some Wiki articles, create a good description of the program and such
• Game Programmer – Someone to create example games, test the IDE out, etc etc
• Beta-Tester – Tester of the games that the game programmer creates – I have trust in the game programmer to create a bug-free game, but the problem is the engine behind it may be buggy.

We will also need a set of resources, to help the programmers start. Here’s what we need:

• Sprites – The main ingame art. Formats that erase the per-pixel precision (such as JPEG) will NOT be accepted. Prefered format is PNG.
• Tilesets – The guidelines are similar to those of sprites, only that this time they’re for floor/wall tiles (and similar).
• Textures – for the floor, background textures and such. Prefered formats are PNG and JPEG (no JPEG if it requires precision or if it contains transparency). A rule of thumb is to just send PNG, and I’ll conver them as neccesarry.
• Music – Prefered format is OGG, but I’ll convert anything else as neccesarry. If the music was made in MIDI format, keep it that way.
• Sounds – Same rules apply as in music.

I may have forgotten something, and if you don’t feel like you’d fit any of these, but still want to help, feel free to contact me via the form, the mailing list or (if I’m there) on IRC.

We’re always looking for ideas, so, if you have one, it is very welcome.

As I said, I’m almost the only guy who works on GameCraft. ALMOST.

I would like to express my gratitude to:

• Th30n3 for currently being the only other active member of the project.
• Nicolay for creating Monster script, and therefore creating a scripting language to be used in GameCraft
• Jenfri for creating the site banner
• CheeryBounce and Anteusz for giving me tips about the scripting language (before I found Monster) and about the program itself
• SourceForge for support of free projects and creating a home for the Subversion repository of the project
• Walter for creating the D Programming Lanugage
• All the GUI designers who made mockups in gif/png/jpeg formats

If I’ve left anyone out, do tell.

I’ve done some plans for GameCraft, and ended up with the following diagram (click for bigger image):

The working title of the engine is “SIEGE – Simple Interplatform Entity Game Engine”

As visible from the diagram, both the engine and the language will be used for other projects, too.

There is also a new mailing list (just append @libsiege.org – this was done to prevent spam):

• Posting: siege
• Subscribing: siege-subscribe
• Unsubscribing: siege-unsubscribe
• Help: siege-help

If you have any questions, feel free to contact us.

We’re still alive, and we do bring news. Good news.

Well, the website has been down, because of some problems with the domain registrar…
We’ve hoped that the issue would get resolved, but it never did.
It’s still on the same server, only under a different (sub)domain – gamecraft.soulbreakers.com (but, since you’re here, I assume that you already know that).

On other news, the bytecode interpreter is almost done… All that’s missing is functions (easy), some more work with the arrays and external calling of the functions.
The tricky part is the compiler, and we hope to get that done until June.

What are we going to use for the backend of GameCraft?
Well, this is what we plan to use, but it’s not written in stone:

• Graphics: GLFW (window functions, events, etc) + OpenGL + FreeImage (for image loading)
• Sound: OpenAL or fmod
• Physics: Chipmunk Game Dynamics

Yes, we know that 1st of April is a bad date for news, because everyone assumes that the webmaster is just making fun of them…
Just to make it clear, this is not an April fool.

We’ve decided to put aside all the scripting languages that are there and start making our own.

We have started working on GameCraft Script (or GCS in short). There isn’t much to tell just yet, except for the fact that the script will have C-like syntax.

The SVN directory for the scripting language is located here.

Well, we can finally announce that our website is now open. At the moment it is located at a subdomain, but that is to change once we get a decent userbase.

The site is still under development and configuration, but there won’t be any major changes after we get the forums up and running (which will happen as soon as we think of which forum sections and categories to put in!

So, how’s the project doing? It’s doing well. Though our original plan was to compile the script, we’re most probably going to move onto runtime script running. Shouldn’t be noticable with games.