A little size of fun.

Generally, I’m rather finicky about making assumptions about the sizes of types, and even conversions between signed and unsigned types. Although I occasionally skirt dangerous gronud, such as feeding a function pointer into a object pointer, and expect to be able to cast the void* back to the function pointer (basically implementation defined by C, but required by POSIX), I also tend to make notes of when (fully aware) I do things that are non portable, but not necessarily obvious. At least in the example case I just mentioned, I didn’t know that was dangerous ground until I reviewed code under -pendantic, and scratched my head at the required warning message.

Normally I take things in stride, and just cringe when I see, “Portable” software doing stupid things like using unsigned int where they mean uint32_t, or the (flawed) assumption that a pointer to xyz will be as large as an object of xyz. So I thought I’d just take a look see here, and then wrote a program to display it in bits rather then bytes, since most of the folks I know will better get the picture that way :-o.

Also being a practical man, I kind of like to know what is off the edge of the map, just in case I some day have to jump off o/.

Here is a simple program to solve my curiosity:

 #include 
#include
#include
#include
int
main(void) {

    printf("sizeof(char)t= %u-bitsn", sizeof(char)*CHAR_BIT);
    printf("sizeof(char*)t= %u-bitsn", sizeof(char*)*CHAR_BIT);
    printf("sizeof(wchar_t)t= %u-bitsn", sizeof(wchar_t)*CHAR_BIT);
    printf("sizeof(wchar_t*)t= %u-bitsn", sizeof(wchar_t*)*CHAR_BIT);
    printf("sizeof(short int)t= %u-bitsn", sizeof(short int)*CHAR_BIT);
    printf("sizeof(short int*)t= %u-bitsn", sizeof(short int*)*CHAR_BIT);
    printf("sizeof(int)t= %u-bitsn", sizeof(int)*CHAR_BIT);
    printf("sizeof(int*)t= %u-bitsn", sizeof(int*)*CHAR_BIT);
    printf("sizeof(long)t= %u-bitsn", sizeof(long)*CHAR_BIT);
    printf("sizeof(long*)t= %u-bitsn", sizeof(long*)*CHAR_BIT);
    printf("sizeof(long long)t= %u-bitsn", sizeof(long long)*CHAR_BIT);
    printf("sizeof(long long*)t= %u-bitsn", sizeof(long long*)*CHAR_BIT);
    printf("sizeof(size_t)t= %u-bitsn", sizeof(size_t)*CHAR_BIT);
    printf("sizeof(size_t*)t= %u-bitsn", sizeof(size_t*)*CHAR_BIT);
    printf("sizeof(float)t= %u-bitsn", sizeof(float)*CHAR_BIT);
    printf("sizeof(float*)t= %u-bitsn", sizeof(float*)*CHAR_BIT);
    printf("sizeof(double)t= %u-bitsn", sizeof(double)*CHAR_BIT);
    printf("sizeof(double*)t= %u-bitsn", sizeof(double*)*CHAR_BIT);
    printf("sizeof(long double)t= %u-bitsn", sizeof(long double)*CHAR_BIT);
    printf("sizeof(long double*)t= %u-bitsn", sizeof(long double*)*CHAR_BIT);
    printf("sizeof(ptrdiff_t)t= %u-bitsn", sizeof(ptrdiff_t)*CHAR_BIT);
    printf("sizeof(ptrdiff_t*)t= %u-bitsn", sizeof(ptrdiff_t*)*CHAR_BIT);
    printf("sizeof(intptr_t)t= %u-bitsn", sizeof(intptr_t)*CHAR_BIT);
    printf("sizeof(intptr_t*)t= %u-bitsn", sizeof(intptr_t*)*CHAR_BIT);

    return 0;
}


The C standard defines CHAR_BIT in limits.h, as being the number of bits  for the smallest object that is not a bit field, roughly meaning that CHAR_BIT = number of bits in a byte, for all practical intents and purposes. Like wise, the sizeof operator is defined as returning the size of its operand in bytes, as an implementation defined unsigned integer value having the type size_t, from stddef.h. For the fuckos out there, the standard also says that a char object is large enough to store any character of the basic execution set (A-Z, a-z, 0-9, space, plus the required punctuation and control characters—roughly a character set of 99 symbols that fit within a single byte), and that those characters will have a non negative value while doing it. It also declares that sizeof(char) == 1. From this we can infer that sizeof(x) * CHAR_BIT should be the size of x in bits, and that ‘x’ is basically as good as off the edge of the map, for any x that you can’t make on my grandmothers type writer.

Having the size of each type followed by a pointer to it displayed, is mostly done to emphasis that a pointer to a size, means dick all about the size of the pointer. You’ll notice an interesting connection between pointer size and your hardware however. Gee, that just doesn’t sound right, LOL.

Some examples:

Run on FreeBSD 8.0-STABLE i386:

sizeof(char)    = 8-bits
sizeof(char*)   = 32-bits
sizeof(wchar_t) = 32-bits
sizeof(wchar_t*)        = 32-bits
sizeof(short int)       = 16-bits
sizeof(short int*)      = 32-bits
sizeof(int)     = 32-bits
sizeof(int*)    = 32-bits
sizeof(long)    = 32-bits
sizeof(long*)   = 32-bits
sizeof(long long)       = 64-bits
sizeof(long long*)      = 32-bits
sizeof(size_t)  = 32-bits
sizeof(size_t*) = 32-bits
sizeof(float)   = 32-bits
sizeof(float*)  = 32-bits
sizeof(double)  = 64-bits
sizeof(double*) = 32-bits
sizeof(long double)     = 96-bits
sizeof(long double*)    = 32-bits
sizeof(ptrdiff_t)       = 32-bits
sizeof(ptrdiff_t*)      = 32-bits
sizeof(intptr_t)        = 32-bits
sizeof(intptr_t*)       = 32-bits

and FreeBSD 8.0-RELEASE amd64:

sizeof(char)    = 8-bits
sizeof(char*)   = 64-bits
sizeof(wchar_t) = 32-bits
sizeof(wchar_t*)        = 64-bits
sizeof(short int)       = 16-bits
sizeof(short int*)      = 64-bits
sizeof(int)     = 32-bits
sizeof(int*)    = 64-bits
sizeof(long)    = 64-bits
sizeof(long*)   = 64-bits
sizeof(long long)       = 64-bits
sizeof(long long*)      = 64-bits
sizeof(size_t)  = 64-bits
sizeof(size_t*) = 64-bits
sizeof(float)   = 32-bits
sizeof(float*)  = 64-bits
sizeof(double)  = 64-bits
sizeof(double*) = 64-bits
sizeof(long double)     = 128-bits
sizeof(long double*)    = 64-bits
sizeof(ptrdiff_t)       = 64-bits
sizeof(ptrdiff_t*)      = 64-bits
sizeof(intptr_t)        = 64-bits
sizeof(intptr_t*)       = 64-bits

I also have access to 32-bit versions of Windows NT and OpenBSD running on Pentium 4-grade hardware, but don’t feel like booting the wintel tonight, I’m to comfortable with Dixie hehe. Perhaps I will run the program on other systems and implementations, for the sake of testing, and add it to this entry as a comment.

Wew it’s been a jumpin’ hopin’ day!

I was up all night fiddling with Code::Blocks and Stargella, plus work this morning, and ideas for an interesting project. However it’s a project that would call for C++, and I hate C++, lol. I like C, but hate C++… funny. On the upside, I’ve finally gotten Stargella builds sorted out, and I’m tempted some what to hunt down and eliminate ‘itches’ here and there, but I’m not sure whether or not patches would be welcomed for some things that seem to be, to be good ideas. They’ve accrued a fair number of open patches and bug reports, so I don’t think it’s a highly active project. The code base is only about sixty some thousand lines, not to big for all it does.

Sigh, nothing but work on the horizon o/. At least there’s something on TV tonight that I haven’t seen before, the original Night of the Living Dead. Geeze, what is it with all the zombie flicks lately? Compared to what I’ve seen of the remake (beginning / last half), it certainly has a more spirited beginning, bah I need some pop corn lol. I’ve no idea ottomh what they filmed it in, but it does give an interesting feel to the movie, different then most contemporary films of the era.

The price of pissing me off.

A word of warning, this post contains quite a bit of profanity after the jump break

After being up until well past 0400 last night, setting up a decent SCons build set on FreeBSD, for testing— its usefulness to this project. I started setting up the required config tweaks today on the Windows machine.

When suddenly, I found a odd difference between how the same SCons versions behave on FreeBSD/unix and Windows, in fact, this kind of thing is why I’ve given up on the more popular CMake.

lib = os.path.join('#', outdir)
#
# For some really mother fucking stupid reason, Glob('*.$OBJSUFFIX') works
# on FreeBSD scons 1.2.0_20091224 but not on the Win32 scons 1.2.0_d20091224
# from the installer. So we have to use this fucking method, which will require
# us to wrap it in exceptions in case OBJSUFFIX is None or missing totally on 
# platform X.Y.Z. from fucking hell -- I fucking hate software build tools.
#
src = None
try:
    src = os.path.join('#', outdir, '*'+str(env['OBJSUFFIX']))
except:
    print("Fatal error: I can't make libs from object files without a file "
          + "extension. TERMINATING THIS SCONSCRIPT")
    import sys
    sys.exit(127)

env.StaticLibrary(lib, Glob(src))



# edit: an explanation of why subst() isn’t used in place of the [] look up: once you violate the consistency part, I’m not going to trust that there will be an $OBJSUFFIX to subst() on.

I was going to make most of this code a simple library function for the sake of code reuse, instead of having a virtual copy/paste of the same few SConscript files between all my games source modules—after this, I’ll stick to having one of those comment blocks in each source modules SConscript file as appropriate.

Generally I like SCons, it’s rather similar to what I’ve invisioned as the “Perfect build tool”, even though SCons still requires about 3 x the amount of work for Stargellas build system then tmk should. However, SCons is here today, tmk won’t be for a long time. What annoys me, is that SCons is still just as bad as all the other build tools out there.

For crying out loud people, it is the year twenty first fscking century…. and asking some consistency of our modern build tools, still demands limiting ourselves to the 1970s era make tool from PWB/UNIX.


Being stuck with walking around the supermarket (baah, humbug!), I tried to devote my trains of thought to Stargella. For me, it is kind of a difficult project; much more complex then most of the things I’ve worked on.

In thinking about how to structure the rendering code, I started to think more on the issue of dealing with the data sets to be rendered, which basically means sprites (2d), models (3d), and rendering the level (2d/3d), and I want as much of the code to be shared between several game projects, which makes baking the lasagna a bit involved. Since my current focus is on the 2D oriented, Stargella, I find it wiser to concentrate on sprites then three dimensional models. At first I was thinking, it would be ideal to represent animations for sprites, as a simple image stack; but I don’t want to go through all that for unanimated sprites, which would still require a singular stack frame. The fix to that is simple, only use stacks for holding the animation details! Then I was thinking, gee, wouldn’t it be cool, if we could attach some type of script or shader program to be run, so a level of progmmability could be used in implementing special effects. For example, using program to stake out the centre of a starship, split it into segments and have them drift away from one another, while interleaving it with an explosion-like image or particle effect. Simple enough to do from C I’m sure, but I would much rather have it be apart of the game data, then the game code. I’m not sure if that would be doable from mating with GLSL files, or if it would mean binding a script with the sprite. Either way, as far as general game scripting goes, it should have some level of access to the graphic stuff as a matter of completeness.

For now, I think I’ll concentrate on resource handling. It should be easy enough, just create dynamic arrays as needed (e.g. of loaded textures), and each time a new texture is loaded, assign it an unique identifier that indexes into the array; …

Honestly, I don’t have a problem with programming in C, other then it can be time consuming at times o/. But, because I have to learn OpenGL along the way, it is, shall we say a freaking lot of docs to parse.

While I’m more familiar with Direct3D then OpenGL, even if you can still get a good bang for you buck out of a DirectX SDK without having to stoop to C++, I’m not willing to write a DirectX backend for my game. Obviously, I want to avoid using glThis and glThat all over the game code, but ahem, the issue of shaders enter the picture. Short of making a definitive choice at compile time, that would have to live for the projects entitiy, the only way to support runtime choice, would also require writing both HLSL (DirectX) and GLSL (OpenGL) code, and that’s a headache I won’t put up with!  As much as I favour the idea of nVidia’s Cg, it is not available on enough platforms, and implementing it where needed, to much trouble.

If people other then me want to play the game, they can buy a graphics card made in the 21st century and install its drivers >_>.

—- this post has been interrupted so many damn rat fucking times by family, that it is unfinished and will likely always remain so. This is one of many reasons why I fucking hate my life.

How he does it – Trees!

Yesterday, I was explaining to a less experienced player how I so easily knew where the hostages he missed where located, after the young Element Leader exclaimed that he was always missing hostages rather then suspects 8=). For those that don’t play with me a lot, I am that annoying-guy in the element, who can usually tell the Element Leader what rooms were cleared, which were missed, and so on. In fact, during one live op, I ended up guiding a younger EL around the huge map.

The way I accomplish this feat of meticulous memory, is to keep track of it in my brains equivalent of a data tree. By remembering where I am in the mental tree (I have an excellent sense of direction), I know what the neighbouring nodes are in the tree—and if I forget what is after those, by the time I reach the spot-after, I can compare what I see with a ‘snap shot’ stored in my head, to trigger my brain into remembering where we’ve been before. If we’ve never been there, then obviously, I append it, or if it is an unexplored door, mark it as such mentally.

 I’ve been thinking of putting up a diagram of it for some time now, so here goes, lol.

This is a diagram of a fairly simple building, it contains a starting room (1), a large room (2) with a hostage and two terrorists: three doors connecting to two other rooms (3 and 4), containing terrorists and a hostage. Those rooms (3 and 4) connect to a final room (7) by way of hallways (5 and 6, respectively), and contains a hostage.

It is a very simple diagram, so I doubt anyone will have problems understanding that, because if you do, there is a problem with your map reading skills ^_^.

The way I navigate in side a building like that depicted in the above diagram, is storing each element as a “Leaf” or node in a tree, itself being a tree in my minds eye. Each node is a reference in my brain, telling me what door( node)s connect it to other rooms, and what was found in it (in this case, hostages and terrorists). Those in turn, point to other nodes or leaves of the tree, creating an organised pattern, shown below:

Here you can see the nodes are again labelled, matching to their “Room number” from above. I don’t mentally record room numbers, rather room names, but for sake of examples, I find numbers simpler to explain.

The first node (1) references a single child node (2), which as you can see, contains two terrorists and hostage, and references three door( node)s leading to the adjoining rooms—exactly as in the floor plan I drew earlier. To make it more obvious, I wrote X->Y on the nodes representing the doors, denoting where they lead to. The door( node) 2->4 takes you into room 4, from room 2. Just like in the floor plan, room four contains a terrorist and a door to a hallway (6), The two door nodes, 2->3, lead into room 3 from 2, where room 3 contains two terrorists and a hostage, again exactly in the floor plan diagrammed previously. The hallway( node)s (5 and 6) connect rooms 3 and 4 to room 7 (respectively), and room 7 contains a hostage.

This is actually a simplification of how my mind works, a since my mind notes doors, hostages, terrorists, downed team mates, objectives, important events, etc, as the children of a tree leaf, and the doors reference the next leaves. That however, is only of importance to another programmer :-o.

Since my head keeps a running track of where I am, and I know easily if I started in room 1, walked into the next room (2), and took the single door into another room, that I must be in room 4, and the door ahead leads to the hallway (6) connecting with room 7. The data tree (i.e. second diagram), is mental abstraction, showing (very roughly) how my mind views the relationships between elements of a map (e.g. the first diagram). So in essence, navigating inside a building, is a simple matter of scanning the tree in memory, and vola, I know exactly how to get to X from Y, lol.

This is how I navigate in doors, and it works damn well, certainly works better then asking a terrorist for directions! Because my working conditions place me inside buildings quite a lot, it has been necessary for my senses of navigation and deductive reasoning to adapt accordingly. I almost never get lost, just don’t ask where you left the swiffer duster. Even navigating outside, my roads-view isn’t street sign or land mark based, but closer to watching a overhead view on a HUD map from some video game…. I blame it on so many years behind a controller.

Lacking the knowledge of how the human mind operates, I’ve always found it easier to explain things in relation to a how a computer does its stuff…. because honestly, my mind functions eerily similar to a computer as it is… but hey, I am a computer geek!

Ahh, Stargella moves foreward

I’ve just made a forum posting, starting an open query for any artistic talents interesting in helping to contact me. My main concern at the moment is working out the games design bible while finishing off the Georgia drivers guide >_>.

Most of the code for Stargella is going to be reused for the later first person shooter and ‘mech projects (which may just get released years before the new MechWarrior lol). While the shooter is going to be a 3D affair, and the ‘mech combat game is undecided, the star fighter game (Stargella) is fairly straight forward: 2D is the only way to go. At least without getting sued for recreating Star Fox, if I dared try it in 3D lol. At its heart, Stargella is about having fun, the kind of fun that existed before the move into 3D games. I largely missed the big classics like Battlezone and Asteroids, only getting to play them in later years, but Galaga was a game I did play as a child. Its always been something I’ve found missing, no modern incarnation I’ve had access to just itches the right spot, that’s where Stargella comes in: it’s gotta be fast and furious, like an nail biting round of Centipede. Yet it’s got to something you can actually play and survive with some mastery, like Asteroids (one of my great favourites btw). Most of the games I played growing up, were side scrollers like Super Mario Brothers and Sonic the Hedgehog, so I remember the mechanics quite easily.

Graphics are my achilles heel however, because while I can code what I want, making it ‘look’ that the way I want, is limited by the models that can be created for the game to display. In fact, I’m actually thinking of drawing most of the ships for Stargella, and scanning them into the computer. Really it has been a long time since I’ve done free hand drawing, it feels more natural to me then the computer: I can work FASTER!!!

For Stargella, I very much know what kind of look I want, the question is can I get graphics that match it without the whole thing looking like the early arcade games, lol. I reckon that I could always hash things out in a modelling program and get a head start on code needed for the 3D titles, but I feel that is just over kill for a game like Stargella.

Building SpiderMonkey 1.8.0 rc1 on Windows XP with Visual C++ 2008 / 9.0

Finding this note in SpiderMonkies documentation was a huge NO NO for me, because a dependency on Autoconf 2.13 is *worse* then a dependency on Autotools in general.

As I said I would, I investigated Windows/MSVC builds with SpiderMonkey before completing and utterly refusing to ever use the thing ^_^. This is a summery of my findings.

A lot of people are still using Visual C++ 7.1/2003.NET or 8.0/2005 versions, while I however use the Express Edition of Visual C++ 9.0/2008 for Windows builds, which generally means no pre-compiled libs binaries are available. That’s ok, since I prefer to evaluate the buildability of a dependency before I commit to using it…. hehe. One perk of doing most of my coding under FreeBSD, no need to buy a Professional Edition of Visual Studio :-D. I think this post should apply to most versions of Microsoft’s compiler, +/- differences in compiler flags.

The proper build requires MinGW, MSys, GNU Make, and a suitable copy of Visual C++.

MSys is required because of UNIX tools, such as uname, sed, and countless others are used by the build system; which also seems to depend on GNU Make.

Open the Visual Studio command prompt, or call  %VS90COMNTOOLS%vsvars32.bat from your current cmd session (VS90 = 2008 fyi; adapt as needed for older/newer versions). Then execute a MSys RXVT terminal from that. You do that by running the msys.bat script in the MSys root with the -rxvt argument, example:

+> C:DevFilesMSYS1.0msys.bat -rxvt

which will close the cmd session and open RXVT.

Change over to the js/src directory of where you extracted SpideryMonkey to, and run make on the projects makefile:

bash $ pushd /C/DevFiles/Libraries/SpiderMonkey/1.8.0rc1/js/src/
bash $ make BUILD_OPT=1 -f Makefile.ref

The BUILD_OPT causes an optimised release build to be made, default seems to be debug builds; read the Makefiles and Wiki for details on that.

Now for an example app to test, to see if more then js.exe works!

bash $ cat > test.c

#include "jsapi.h"

/* The class of the global object. */
static JSClass global_class = {
    "global", JSCLASS_GLOBAL_FLAGS,
    JS_PropertyStub, JS_PropertyStub, JS_PropertyStub, JS_PropertyStub,
    JS_EnumerateStub, JS_ResolveStub, JS_ConvertStub, JS_FinalizeStub,
    JSCLASS_NO_OPTIONAL_MEMBERS
};

/* The error reporter callback. */
void reportError(JSContext *cx, const char *message, JSErrorReport *report)
{
    fprintf(stderr, "%s:%u:%sn",
            report->filename ? report->filename : "",
            (unsigned int) report->lineno,
            message);
}

int main(int argc, const char *argv[])
{
    /* JS variables. */
    JSRuntime *rt;
    JSContext *cx;
    JSObject  *global;

    /* Create a JS runtime. */
    rt = JS_NewRuntime(8L * 1024L * 1024L);
    if (rt == NULL)
        return 1;

    /* Create a context. */
    cx = JS_NewContext(rt, 8192);
    if (cx == NULL)
        return 1;
    JS_SetOptions(cx, JSOPTION_VAROBJFIX);
    JS_SetVersion(cx, JSVERSION_LATEST);
    JS_SetErrorReporter(cx, reportError);

    /* Create the global object. */
    global = JS_NewObject(cx, &global_class, NULL, NULL);
    if (global == NULL)
        return 1;

    /* Populate the global object with the standard globals,
       like Object and Array. */
    if (!JS_InitStandardClasses(cx, global))
        return 1;


    /* Your application code here. This may include JSAPI calls
       to create your own custom JS objects and run scripts. */

    /* Cleanup. */
    JS_DestroyContext(cx);
    JS_DestroyRuntime(rt);
    JS_ShutDown();
    return 0;
}


bash $ $ cl -nologo -DXP_WIN  -I.. -MD -Fetest test.c js32.lib
bash $ ./test.exe

footnote: that test.c is just the minimal app example from the user guide, here. Also note that using /dos style switches with cl under bash/rxvt, doesn’t seem to work (it’s converted to file names).

I’ll need to do some further testing but everything appears to be working fine.

Here’s my notes from installing JPEG-7 on Windows

Take note: I install libraries into C:DevFilesLibrariesWhat; with compiler specific files dumped under sub folders, e.g. C:DevFilesLibrarieszlibmsvczdll.lib and C:DevFilesLibrarieszlibmingwlibzdll.a. Like wise, I leave a README.TXT file in the root, noting anything I will need to remember when it comes to using the library.

# build for Visual C++ 2008 / 9.0
> unzip "pathtojpegsr7.zip"
# I want it in jpegsrc for safe keeping
> mkdir jpeg
> move jpeg-7 jpegsrc
# use the corresponding .vcX files for version
> copy makeasln.vc9 apps.sln
> copy makejsln.vc9 jpeg.sln
> copy makewvcp.vc9 wrjpgcom.vcproj
> copy maketvcp.vc9 jpegtran.vcproj
> copy makervcp.vc9 rdjpgcom.vcproj
> copy makedvcp.vc9 djpeg.vcproj
> copy makecvcp.vc9 cjpeg.vcproj
> copy makejvcp.vc9 jpeg.vcproj
> copy jconfig.vc jconfig.h
# I'm using vcbuild, since I read .vcproj files in vim; you may want the IDE
> vcbuild /nologo jpeg.sln "Release|Win32"
...
> vcbuild /nologo apps.sln "Release|Win32"
# I put compiler specific files in a suitable folder
> mkdir ..msvc
> copy Releasejpeg.lib ..msvc
# jconfig.h is compiler specific, so we dump it in our compiler directory
> copy jconfig.h ..msvc
> del jconfig.h
# build for MinGW/MSys
$ pushd /C/DevFiles/Libraries/jpeg/
$ pushd src
# works for most packages
$ ./configure --prefix=/C/DevFiles/Libraries/jpeg/ --exec-prefix=/C/DevFiles/L
ibraries/jpeg/mingw/
$ make
$ make install
# move jconfig out of independent include and into compiler specific dir
$ mv ../include/jconfig.h

Now copy jerror.h, jinclude.h, jmorecfg.h, jpegint.h, and jpeglib.h into ../include/. Those are the portable headers, that won’t very based on compiler (MinGW/MSVC).

and here’s my notes file:

MinGW -> static link as normal
MinGW -> Use import library libjpeg.dll.a for dynamic linking with libjpeg-7.dll
MinGW -> Last build JPEG-7 on 2009-12-24

MSVC -> Can only static link agaisnt jpeg.lib; must use /MD
MSVC -> also add msvc/ to include path, for jconfig.h
MSVC -> Last build JPEG-7 on 2009-12-23

In all cases, add include + compiler folders to your include path.

Although my original plan for the day, was to spend it working on Stargella, I’ve not found time for it, and I’ve to much of a headache now to worry about it.

I got in some good SWAT action then set to work on dependency compiling and evaluation, getting the freetype and jpeg libraries built. It was excellent to see that the freetype folks know how to use autotools, something a lot of projects fail at; and that jpeg has an gone through insane hoops to make their package easily built, on virtually anything lol. Tomorrow is moving on to other libs that may be useful. Since the handling of model and map information, will likely be done through XML files, I also need to start evaluating XML parsers again; something I have absolutely no love for. Also, because of that, there’s no point in taking a few moments to write a simple config file parser, when the application requires an XML parser :-S.

Code wise, the main focus for the day was to be working on implementing a simple drop down console, but I haven’t had time to focus on it, due to the time and effort it takes to compile software in a Windows environment. Which is approximately 200% more trouble then a unix environment, or 90% higher if it’s a Linux application written by assholes who knew less about what they’re doing then the puts who wrote the tools 8=).

I’m interested in seeing what SDL_ttf can do for rendering the textual part of the console, but that requires freetype, lol. Freetype however is a very painless thing to setup under Windows, at least using MinGW and MSVC. Whether or not SDL_ttf will be so hunky dory, remains to be seen.

Also spent some time in evaluating the concept of using JavaScript as an embedded scripting language. Mozillas Spidermonkey seems to be the only engine that fits the bill: written in C. It’s also fairly portable and has one hell of a nice (JS)API , with out a doubt it’s gotta be a lovely way of embedding a language into your program. The only problem, the build system issues. I will explore it’s compilation under Windows but expect it to be a wash out. The comments about autotools alone, virtually make Spidermonkey something you can rule out of any sane programmers toolkit.  I’ve already learned about Python extension modules, but have never had time to look closely into embedding the interp into an application, but will do that also in time. Another thing to consider, is embedding Lua, a language I’ve never had an excuse to study, lol.

On the embedding a language thing, my thoughts are focused around in game scripting, more so then implementing the game in it. Although with the JSAPI, it wouldn’t be to tricky to do the entire game in JavaScript, as absurd as that might sound to the uninformed. For Stargella, the scripting needs can actually be integrated into the map data, in a fairly simple manor as firing positional events off to the game code. However the underlying code is meant to be (largely) shared across several games, and some (the tactical fps for example) will need much more useful scripting capabilities. Using shared objects written in C would be possible, but then maps would become non-platform independent, and I don’t want that. Quakes solution, was inventing their own C based language, and to a lesser extent the Q3VM, but ahem, I’m not quite going to do that :-P.

Some how, the idea of scripting the game system using JavaScript is still an attractive idea…. but do I really want to live with compiling Spidermonkey in order to do it?

The principal concept of any build tool, is building stuff. In my opinion, make has the perfect idea for it: just tell it what you want, then tell you want done about it.Then exploit that what you want done, can usually be guessed or written once, hehe.

At it’s heart, tmk is still a `make`, and perhaps barrows the most from classic make and from Qts project file sytax. Personally, I feel tmk makes things more simple, I’ll not repeat here what I’m loading into the Wiki on Source Forge however.