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.

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 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 …

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.

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.