Filed Under: Journal - Development

As mentioned here's the script to generate a ToString method for a C\C++ bitwise mask enumeration. Again this is simple stuff, but can be pretty useful for debugging.

This, again, reads from stdin. The idea is to copy the enum from the library source and paste it into the terminal, then copy the output and paste it in your code.

For example, copying SDL_RendererFlags enum in:

/**
 *  \brief Flags used when creating a rendering context
 */
typedef enum
{
    SDL_RENDERER_SINGLEBUFFER = 0x00000001,     /**< Render directly to the 
                                                     window, if possible */
 
    SDL_RENDERER_PRESENTCOPY = 0x00000002,      /**< Present uses a copy from 
                                                     back buffer to the front 
                                                     buffer */
 
    SDL_RENDERER_PRESENTFLIP2 = 0x00000004,     /**< Present uses a flip, 
                                                     swapping back buffer and 
                                                     front buffer */
 
    SDL_RENDERER_PRESENTFLIP3 = 0x00000008,     /**< Present uses a flip, 
                                                     rotating between two back 
                                                     buffers and a front buffer
                                                 */
 
    SDL_RENDERER_PRESENTDISCARD = 0x00000010,   /**< Present leaves the contents
                                                     of the backbuffer undefined
                                                 */
 
    SDL_RENDERER_PRESENTVSYNC = 0x00000020,     /**< Present is synchronized 
                                                     with the refresh rate */
 
    SDL_RENDERER_ACCELERATED = 0x00000040       /**< The renderer uses hardware 
                                                     acceleration */
 
    } SDL_RendererFlags;

Yields:

const std::string GetSDL_RendererFlagsAsString( const int iVal ) {
	string r, sep;
 
	if (iVal & SDL_RENDERER_SINGLEBUFFER) {
		r += sep+"SDL_RENDERER_SINGLEBUFFER";
		sep = ", ";
	}
 
	if (iVal & SDL_RENDERER_PRESENTCOPY) {
		r += sep+"SDL_RENDERER_PRESENTCOPY";
		sep = ", ";
	}
 
	if (iVal & SDL_RENDERER_PRESENTFLIP2) {
		r += sep+"SDL_RENDERER_PRESENTFLIP2";
		sep = ", ";
	}
 
	if (iVal & SDL_RENDERER_PRESENTFLIP3) {
		r += sep+"SDL_RENDERER_PRESENTFLIP3";
		sep = ", ";
	}
 
	if (iVal & SDL_RENDERER_PRESENTDISCARD) {
		r += sep+"SDL_RENDERER_PRESENTDISCARD";
		sep = ", ";
	}
 
	if (iVal & SDL_RENDERER_PRESENTVSYNC) {
		r += sep+"SDL_RENDERER_PRESENTVSYNC";
		sep = ", ";
	}
 
	if (iVal & SDL_RENDERER_ACCELERATED) {
		r += sep+"SDL_RENDERER_ACCELERATED";
		sep = ", ";
	}
 
	return r;
}

Braindead, but a great debugging tool. Here's the perl code:

mkEnumLookup.pl

#!/usr/bin/perl
use strict;
use warnings;
 
my $buf = join '', <>;
 
# Strip out useless stuff.
$buf =~ s/\/\.*$//g;
$buf =~ s/\n/ /g;
$buf =~ s/\/\*.*?\*\///g;
 
# Start processing.
my $name = '';
if ($buf =~ /\{(.*)$/) {
	$buf = $1;
}
 
if ($buf =~ /(.*)\}\s*(.*);+.*$/) {
	$buf = $1;
	$name = $2;
} elsif ($buf =~ /(.*)\}.*$/) {
	$buf = $1;
}
 
my @defs = split /\s*,\s*/, $buf;
my @names = ();
 
$name ||= 'MyEnum';
 
print "const std::string Get$name","AsString( const int iVal ) {\n",
	"\tstring r, sep;\n\n";
 
foreach (@defs) {
	$_ =~ /^\s*(.+?)(\s+|\s*=.+|)$/;
	print "\tif (iVal & $1) {\n\t\tr += sep+\"$1\";\n",
		"\t\tsep = \", \";\n\t}\n\n";
}
print "\treturn r;\n}\n";

More useful than you'd think.

Filed Under: Journal - Development

I'm waiting for WoW to patch, and Minecraft files to scp to my box, so I thought I'd throw up another small code snippet from my toolbox of extensions. This command is a tiny Perl script that drops a bunch of asterisk filled lines in your terminal. Ultra-simple, but useful for separating the output of one command from another without clearing your buffer.

I don't use this nearly as much as I used to, but I found it useful when running compiling C++ which threw out gigantic std:: template errors that tend to run into each other. Usage would look something like this:

s; g++ myfile.cpp -o main;

It provides a natural break in the flow of output. The only vaguely interesting thing here is that it will fill the output line regardless of the terminal dimensions. I'm aware this is brain dead simple.

s

#!/usr/bin/perl -t
 
use strict;
use warnings;
 
require 'sys/ioctl.ph';
 
my $winsize;
 
die 'no TIOCGWINSZ' unless defined &TIOCGWINSZ;
 
open(TTY, "+</dev/tty") or die "No tty: $!";
unless (ioctl(TTY, &TIOCGWINSZ, $winsize='')) {
        die sprintf "$0: ioctl TIOCGWINSZ (%08x: $!)\n", &TIOCGWINSZ;
}
 
my ($row, $col, $xpixel, $ypixel) = unpack('S4', $winsize);
 
 
print "\n";
for (my $i=0; $i<16; ++$i) {
        print '*'x$col, "\n";
}
print "\n";
 
exit 0;

Filed Under: Journal - Development

Recently I've been doing a little bit of work getting up to speed with Ogre, starting to re-learn AC3d, a bit of ACNet hacking, a whole lot of time wasting in Minecraft and starting to dig myself even a bigger hole.

Also I think I'll start posting the scraps of code I write as I write scraps of code to make my life easier. More on that later.

SDL and Ogre

I picked up hacking on Ogre and SDL where I left off a few weeks ago. As usual it took half the time just getting back up to steam, but I did make a little headway. I'm hobbling along using a mishmash of Eclipse, vim and other tools rather than sticking to the IDE exclusively still trying to find where my sweet spot is going to be. Eclipse really drives me crazy sometimes, but it's hard to argue with the advantages it provides.

I got the Ogre Test Framework up and running, with obligatory and redundant screenshot provided to the right. I'm impressed with how simple it seems to be to get basic results. Unfortunately, in my experience however, whenever it is easy to do simple and straightforward things with a toolkit it's often very difficult to do complicated, specific things. I'm not making that claim yet. It's way too early to make that kind of determination.

The next steps will be looking into an import/export scheme that'll let me use AC3D, or to start investigating new simple tools for making meshes. Also I need to start considering how I'll integrate the n2lGUI libraries into the whole thing. They have OpenGL calls all over the place inside them which'll all have to be torn out and replaced. With those changes on top of all of the restructuring I was planning on doing it makes me wonder if I'm not better off starting from scratch, or with using something pre-built.

Making quick C/C++ Enum Lookups for Debugging

Most of this is going to be things better done with some existing app, but it shows how I do my thing. Maybe the act of putting this stuff out here will get me feedback describing even better tools of the trade.

This post is a little tool which parses a C/C++ enumeration and fabricates a C++ method which provides ToString for that enumeration. It isn't optimal, or pretty, but I find it very useful for hacking at new libraries when you just want a quickie way to see what is hiding variables.

This reads from stdin. The idea is to copy the enum from the library source and paste it into the terminal, then copy the output and paste it in your code.

For example, copying the following subset of the SDL_EventType enum in:

typedef enum
{
    SDL_FIRSTEVENT     = 0,     /**< Unused (do not remove) */
 
    /* Application events */
    SDL_QUIT           = 0x100, /**< User-requested quit */
 
    /* Window events */
    SDL_WINDOWEVENT    = 0x200, /**< Window state change */
    SDL_SYSWMEVENT,             /**< System specific event */
 
    /**
     *  This last event is only for bounding internal arrays
     */
    SDL_LASTEVENT    = 0xFFFF
} SDL_EventType;

Yields:

const std::string getSDL_EventTypeAsString( const int iVal ) {
	if (iVal == SDL_FIRSTEVENT) return "SDL_FIRSTEVENT";
	if (iVal == SDL_QUIT) return "SDL_QUIT";
	if (iVal == SDL_WINDOWEVENT) return "SDL_WINDOWEVENT";
	if (iVal == SDL_SYSWMEVENT) return "SDL_SYSWMEVENT";
	if (iVal == SDL_LASTEVENT) return "SDL_LASTEVENT";
	return "(INTERNAL) Unknown";
}

Simple, but I find quite useful. Here's the perl code:

mkEnumLookup.pl

#!/usr/bin/perl
 
use strict;
use warnings;
 
my $buf = join '', <>;
 
# Strip out useless stuff.
$buf =~ s/\/\.*$//g;
$buf =~ s/\n/ /g;
$buf =~ s/\/\*.*?\*\///g;
 
# Start processing.
my $name = '';
if ($buf =~ /\{(.*)$/) {
	$buf = $1;
}
 
if ($buf =~ /(.*)\}\s*(.*);+.*$/) {
	$buf = $1;
	$name = $2;
} elsif ($buf =~ /(.*)\}.*$/) {
	$buf = $1;
}
 
my @defs = split /\s*,\s*/, $buf;
my @names = ();
 
 
$name ||= 'MyEnum';
 
print "const std::string get$name","AsString( const int iVal ) {\n";
foreach (@defs) {
	$_ =~ /^\s*(.+?)(\s+|\s*=.+|)$/;
	if (length($1)*2+length("    if (iVal == ) return \"\";")<=80) {
		print "\tif (iVal == $1) return \"$1\";\n";
	} else {
		print "\tif (iVal == $1)\n\t\treturn \"$1\";\n\n";
	}
}
print "\treturn \"(INTERNAL) Unknown\";\n}\n";

I have a variant for dumping all the enabled flags in a bitmask as well, which I'll post next time.

ACNet Hacking

I've spent a few hours here and there modernizing the publishing and visual style of pages through out the site. Some of that payed off tonight, and some has turned into a huge mess. I'm always right on the edge of throwing the whole thing out and installing WordPress. Coding a publishing system just seems so unnecessary these days. Then I realize that there's so much more going on under the hood that I'd lose that it isn't realistic. Then I get disheartened.

Project/ Site and Documentation sections for Orange and Tang are coming. There's still not much to put up there, and I'd like to tighten up the integration with the project manager a bit before releasing it, so not much to say on that front.

In other news...

Minecraft has happened to me. I'll get into that a lot more in the near future.

As if that wasn't bad enough. I've gone and done this to myself:

I'm not a smart man.

Filed Under: Journal - Development

I dug back into some game development tonight and was pleasantly surprised to find I had forgotten slightly less than I'd expected.

Change can be a good thing, I'm learning. I've been a rather unmovable object in some of the development decisions I've made in the past, and I think I've been worse off for it. Just like every other developer out there I went through a phase of Not Invented Here, but I think many vestiges of that anti-pattern have stayed with me longer than they should have.

I'm giving eclipse a try and finding it far less objectionable than I'd expected. I certainly wouldn't have been willing to do anything with it a couple years ago. I'm still not willing to hand the full build configuration over to it, but maybe I'm growing up just a little.

For that matter, I think I'm finally going to be willing to use a 3rd party engine to take care of rendering. That's something I've been completely unwilling to release control of whilst simultaneously being absolutely dreadful at implementing solutions myself.

It's exciting that by lowering some of my ideological shields I may have gained (proper) access to Windows and the iPhone, not to mention other possibilities like consoles.

There is nothing really to be said about the projects themselves at this point, so I shall stop rambling and go to bed.

I'm never going to accept spaces instead of tabs, though. Till the grave.

Filed Under: Journal - Development

Is that all? This post is amazingly overdue so I'm going to try to cover everything as quickly as I possibly can. One thing at a time, so here we go:

Jimmy's World

Jimmy's World isn't actually dead. It looks dead, and it acts dead... and if one was to measure usefulness, or recentness, or value it would seem dead. It isn't. Trust me. Jimmy's World suffers from misfire problems. I've started at least 30 articles and written several pages only to realize I have neither the time nor the inclination to do the research necessary to cover the ground I wish to cover with the credibility that I feel I need to have. That is, I run the site like kindergartner but demand the accuracy of a university thesis. This results, somewhat predictably, in nothing ever being finished and published.

I have no solution for this. I state it only for the limited value of acknowledging it. Solutions are in the works, but, well, don't hold your breath.

Religion dot jimmysworld.org

I have no idea where to find the time to work on this project, but it has the potential to piss off too many people for me to just let it go. See Jimmy's World above for where this site sits. Not dead, just in carbon freeze.

The Unfortunately Esoteric Tale of libN2L-4, n2l5

LibN2L-4 is the backbone of Onyx and is a beautiful mess of poorly thought out dependencies, inappropriately categorized functionality, needlessly verbose code and really, really cool stuff. LibN2L-4 gave birth to DynVars, the ResourceManager and countless other really awesome chunks of code that I am going to labour very hard to finally give legs to. Enter n2l5.

The revised name, n2l5, is a symbol of where libN2L is going in the near future. It will be an improved, but smaller and more streamlined version of everything LibN2L-4 meant to do. The prefix 'Lib' is extraneous, the final 'L' of the acronym stands for library. A standing sentinel of duplication which had no business being there to begin with. The dash was syntactical complexity for no perceivable reason, a sign of ideology over reason. The four represents a fourth generation, when we all know that a fifth generation is bound to be better. You see how n2l5 fixes all these horrible mistakes.

In seriousness n2l5 will seek to cut the fat of LibN2L-4 and simplify the syntax while focusing on the functionality that should be in an underlying library. Where does that culled functionality go, you ask?

orange, and Orange

Orange was a codename assigned to a new game meant to occupy the Life2130 universe circa 2060-2100 shortly after the First Solar War as a sort of SimCity in space. The game lives on in a semi-mature design phase, renamed to ... something and Orange moves forward as the engine that will drive the games to come. Orange is the glue that LibN2L-4 inappropriately sought to be.

Designed and developed to simultaneously support Onyx, Onyx: Free Trader, Life2130 and orange (the first iteration): Orange will be the environment which will connect the power of n2l with the assets of already designed games. It will combine function with design.

Life2130

Life2130 is evolving yet again. Yeah, I'm not talking about Life2130 yet.

Onyx

The current codebase was declared dead as of 1:17am March 29 2007. the new codebase was born 1:17am March 29 2007. Onyx is dead, long live Onyx.

While long have I whined about the technical inadequacies of Onyx, particularly the physical and graphical inadequacies, on paper and in implementation Onyx had always been intended to pad my resume with game development goodness. It has totally and completely failed to do so. Now I realize I don't even want a game development job, and irregardless Onyx never fit the bill since as much as I may be proud of everything it was and everything it could do it simply doesn't look formidable enough to be worth anything.

Onyx was a failure and a success. I'm proud of what I accomplished on some levels, but what I accomplished has no externally visible value to speak of. Finally recognizing and fully digesting that fact leaves me with the inescapable conclusion that I need to close the book on Onyx the implementation and decide how I want to tell Onyx the story, if I want to tell its story.

Onyx the story is a story of the years 2108 to 2148 in the Life2130 universe and not 115,762 lines of C++, 71,541 lines of definition files and 850 meg of data. Realizing and accepting that lets me tell the story and divorce myself from the learning experience.

From this moment on Onyx will be restarted in concert with other projects and it will be back better, stronger and more descriptive of the universe it occupies.

And so...

And so JwGames moves forward. To define this turning point one needs to really define Onyx as an experience. How does one define Onyx? Onyx was a painful, bloody and crushing experience. Onyx was a vessel into which was poured the ill-conceived and outdated objectives of an extinct set of childish goals. Onyx became bitterness and cynicism crystallized. Onyx was a horrific, life-adjusting mistake. Onyx was and is a war that occupied 1370+ days, nearly 15% of my life and resulted in failure.

Onyx is an opportunity, and it sure as fuck isn't over yet.

Filed Under: Development - Game Development

So, the time off has ended and I figured it would be a good idea to summarize some of what got done before heading off to bed. It has been a good break with a fair amount accomplished, and I can say I'm mostly happy. Unfortunately I seemed to falter toward the end, but I suppose that's somewhat to be expected. So anyway, here I go.

Onyx

Onyx got a fair amount of attention including a new website, bugtrack project, wallpaper and a set of internal design documentation and story line outlines. As far as the code base, I did a little work, but not much. Most of the actually coding I did has been auxilary to Onyx and focused on the libN2L codebase instead. All of that added code directly mapped to things needed to get Onyx off the ground though, so progress was made.

In the artwork department I'm honestly not sure what if anything got done. pierre had a lot on his mind with moving and *ahem* other things... so I doubt much of substance got added. That's fine for the most part because I'm not really blocked by the artwork at this point. I'm sure things will start materializing a lot more in the next couple of weeks.

Soundtrack has moved not at all, unfortunately. I still have to get off my lazy ass and arrange quite a lot to get the audio side of things lined up. Not to mention the fact that there is absolutely ZERO audio code in libN2L at this point. I still haven't even decided if I'm going with SDL_mixer or OpenAL, yet. Probably OpenAL from the looks of it, but having never even compiled a test project yet I can hardly say with any certainty. So, that was a long winded way to say, nothing.

Story is finally taking root in the Onyx world, and is starting to gel to a point where I can get a feeling for where I want things to go. This has to be the only project I've ever worked on where the story backbone started appearing well after the game assets started to materialize. Luckily I think things are still early enough that no work was wasted. I can also say on a personal note that some of the adjoining material between Onyx and Life 2130 is really helping me to engage myself. It's almost as if a moving target just had a net thrown over it and it's finally possible to start attacking it.

LibN2L

LibN2L was (as usual) the primary focus of all the development that took place in the last few days. Almost all of that development I've been posting about in my journal this week, so I won't go into it all again. To summarize things development went very well. New events and event handling was added, lots of optimizations were added and a lot of bug fixes went into place. All in all, good strides were made in the code base.

On a more exciting note, I've set up a working cross-compile suite and can now make Windows binaries (exe's) right from my Linux box, just by running a script. Getting things working was a little hairy, and testing was a pain in the ass since I don't actually have access to a Win32 machine. BUT, things do indeed work. I even have proof:

That is indeed the Md2 selection test running happily on a Windows XP system which Thanatos generously donated along with his patience to help me get things working. This is actually a big step for me, since up till now I haven't been able to get a project actually link on a windows system. It also means I don't have to deal with the nightmare that is Visual Studio's compiler. All around I'm quite pleased with the cross-compile tools. You'll also note that Thanatos went that extra mile and endured my Onyx background long enough to take the shot. That speaks volumes of his character, let me tell you. :)

Life 2130

Life 2130 is not a dead project! I really can't say that enough. In the past few days I've clarified some of the story line, and mucked a little with the RPG system it will be using, as well as plotting out its development schedule a little bit more. It is safe to say that Life 2130 is alive and well (excuse the pun) and receiving active attention. Most of everything that has been done is internal development and documentation, though; so there really isn't much for me to say about it.

Jimmy's World.org

Not a whole lot happened to Jimmy's World, unless you count the addition of the Onyx site. I'm about half way through adding a C++ tutorial, which makes about 3 tutorials which are half done now. I had really hoped to add it before Wednesday, but not everything can get done, and the tutorial was a very optional project, as far as I was concerned. So, yeah. Jimmy's World is still Jimmy's World... and that's all I have to say about that.

And... Yeah..

All in all I suppose I'd have to say that yes, things went rather well. Certainly I could have used more time, and I could have made better use of the time I DID have. As always though, this isn't a sprint, it's a marathon. The real test will be to see if Onyx can materialize into a runnable test in the next three weeks. Longer than that and it has taken too long. LibN2L has more flaws right now than I can comfortably comprehend, but certainly it is far enough along to not be a restrictive agent any longer. The time is right, the story is starting to be there and the art is falling into place. Now starts the real test. Can I get this to materialize?

And with that rather melodramatic question floating in the air - I'm going to go to bed. Reality is afoot.

Filed Under: Development - Game Development

So I had intended to do some interface code, and as it turns out I wasn't quite ready for it. At least not as ready as I had thought. Drawing stuff isn't really a problem any more, it turns out that actually interacting with things on the screen was a bit less trivial than I had expected. The way I figure, most of my interface with widgets will all be taking place in an orthographic projection, so the coordinate maps will be really easy to map. That is, the mouse is @ x,y in real screen resolution, and I can easily scale it to the orthographic coordinates that widgets exist on. It occured to me though that I had no way of selecting anything that wasn't rendered on the orthographic layer. So, I had to take a brief trip into OpenGL selection.

You know, I'm working witht he selection mode now and I can't help but feel like this isn't the way it's done in reality. I mean it works, but it seems more than a little cludgy to re-render the scene over again just to find out what the mouse has clicked on. But look as I may the only method that seems to be described over and over is using selection. Anyway. I took my orc model toy and set it up to do selections on it, and got the code in place and it DID work, but good lord was it slow. When I did the Md2 class I was basically just hacking to get it working. Not dirty, but not fast either. I set up three of my 'dancing' orcs and everything worked like a charm, but when the mouse was clicked it was rendering eight copies, four visually and four for the selection... and damn was it slow. The frame rate was diving to around 20-30 fps when the mouse button was down.

My little orc models aren't terribly complicated, so rendering eight of them shouldn't have been causing THAT kind of speed drop. So, even though I wasn't planning on doing any optimization until the end I was stuck messing with the Md2 class just to get it to work under TEST conditions. It was prety depressing. I hadn't expected any test scenario to run into speed problems, not on the hardware I'm running here, but herer I was with a simple scene, unlit even, and it was a dog.

I figured I should set up a baseline test, so I set up the camera and positions and disabled my checkboard floor and mouse cursor and got to work with some optimizations. Just to quickly start I did some pre-calculations for the verticies and texture maps and unrolled a loop, figuring I'd buy myself a couple extra fps and boy, was I ever suprised. When I started my baseline code was running at about 55.3 fps, after the optimizations it shot up to 425.7 fps. Not exactly a small gain. Not only did the speed increase, but I found a bug in my vertex transformations that was causing the z-axis to be a little fuddled. Something to do with reversing the axies before doing my translations.

So, yay! About an hour later, a bug fixed and a ~ 700% speed improvement everything was good to go. The only thing left is to disable the texture rendering when doing the selection, and maybe find a way to render a simplified model. Even without things are acceptable again, so I'm happy.

After my success with the md2 class I dug into my particle engine to see if I could buy some quick improvements in that code too. I probably shouldn't have, because I didn't have nearly the luck I did with the md2's. I moved some of the billboard calculations out of the render method and grouped my particles by texture but it didn't buy more than a 5-10 fps increase for 5000 particles. I'm not sure what to do about it now, exactly. I know I can get about 10,000 particles to run at ~30 fps if I lower the particle size, but it just doesn't look as good. *shrugs* Anyway, I doubt I'll get into any scenario's with Onyx that even require two thousand particles at once, let alone ten thousand, so maybe it won't be a big deal.

Just for the fun of it here's a screen shot of the fps test and selection code. The models clip into each other all over the place, but it gives the idea. Notice the nicely rendered hyperion font (anti-aliased, even) and the little orc-hand mouse cursor in the bottom right-ish corner of the image. Even casts a shadow... that's how bored I was. For even more fun I threw in a shot of the particle fountain running with 10,000 particles. Well, 9892 particles, with the target being ten thousand. It's been reduced to 800x600 from 1024x768. Nothing new or exciting about it, just makes the screen shot row two wide instead of one, which looks lonely.



Anyway, now that I have selection code working (which I'm not even going to use for the menus) and some more experience I think I'll try again on my widget code tonight. And I still need a stupid keyboard manager as well. I'm not super clear on how to move focus around, and how exactly to set up buttons and text boxes vs. their input controls... but hey, if I knew it wouldn't be any fun, right?

So... back to it.

Filed Under: Development - Game Development

Things are moving forward at an awesome rate. There are all sorts of methods of design I'm seeing now that seem so obvious, but I had no clue about only a few weeks ago. I have no idea what sparked this new insite, but boy am I pleased.

I've got some semi-solid ideas about how to manage time, events and visualization in the game loop now. Something that has been a sort of murky half-realized set of notions is starting to take real shape. I can see very good ways of enforcing the seperation between visualization, game state, event processing and network transactions. Even better, there is a absolutely beautiful 'for free' network transparency inherit to the design. Enforcing seperation between the different code segments via streams (save visualization of the game state) enforces all sorts of wonderous concepts that should make design as a whole a great deal nicer.

I must say that it has been advantagous to start looking at the whole game design from the bottom up, more than just top down. I feel much more confident in producing something usable when the WAY in which it will be used dictates the design of the library, rather than the library design dictating the application.

Filed Under: Development - Game Development

It's been a few days since I entered a journal, but I've been hard at work. For a little bit I've been forced to step away from OpenGL and take care of some other stupid odds and ends that needed to be done. None of it is perfect, but it seems adequate.

At this point I've written the streams I need to get started, circular and persistent. I've got a working System->n2l event converter, which currently only knows how to convert 'quit' events. As that implies, there's also a workable 'event stream' and interface done. Out of the more tedious tasks a working virtual file system is set up and seems to work ok. I still need to build converters to RWOPS for SDL_Image & stuff.

I've also converted over oscillator and made an 'oscillating mulit-executor' to take several different frequencies and 'executor' instances to execute taskes at fixed and regulated frequencies. I've tested it using seperate system event pump, render and game state frequencies and everything seems to work fine. The neet-o thing there is that by seperating all of the layers of a game by event streams and then putting the game engine on it's own freqency clock which isn't timed with the renderer, I'll be able accelerate/slow/pause the game vary easily. This actually causes a lot of confusion and complication with some methods of implementing game events and frame rate independant game play for some implementations.

All in all quite a bit has come online and I'm just about back to dinking with raw GL again. I've decided that the first couple of projects I work on, I won't even try to wrap up any GL calls into classes or libraries and just get the hang of how things work together (or more importantly, don't work together) before trying to wrap anything.

For the first time for a project like this I've put up the source to everything right away, and though I doubt it will be downloaded or used I still feel odd. I'm still waiting for someone to appear from no-where and send me an email tearing my coding style apart. More so I think I'm not looking forward to the apathy that is FAR more likely than nastyness. In truth it would be nice to get SOME kind of commentary, but I doubt it will happen. I guess the lack of response just makes everything seem a little less important. That's difficult since it's absolutly not important to begin with, but it's always nice to FEEL like it matters. I guess we'll seen when game time comes. That's when things will count.

Filed Under: Development - Game Development

I spent a whole bunch of time thinking about things and working through some design problems and was all ready to make some serious progress tonight. Instead I seem to have run into a brick wall. My sense of spatial acuity seems to be about as finely tuned and a blind, drunk and high gopher.

I'm writing some testing code to make sure I have a decent grasp on GL before moving forward - and I don't mean any real skill, I mean a grasp - and it would seem that I have none. I was under the distinct opinion that OpenGL took care of the layering of geometry when it was sent to it. In fact in checking every working example I can get my hands on, it does indeed seem to work properly regardless of the order in which geometry is passed to it. To be more specific: if I draw a quad and point a camera at it, then draw a second quad behind it (with respect to the camera) it should be obscured. Specifically, it shouldn't be drawn at all. That doesn't seem to be the case for the test I'm working with right now. If I draw a red quad and then a green quad behind it, I see both. To add to the problem the green quad is smaller as it should be, so I know that my vertices are right.

I have no idea where to go from here. This is such a stupid question that I'm not sure where to look for an answer. The examples I've been looking at don't seem to do any special ordering to make sure the geometry is pushed in reverse order with respect to the camera and they all seem to work fine. Perhaps it's "built in" to the system they are using, but some of the examples are pretty darn simple, and the camera may be positioned both in front of and behind the geometry drawn and things are obscured as they should be. Of course this flies right in the face of what I'm doing now.

Anyway, this is frustrating. I had a bunch of things I wanted to move forward on tonight and suddenly I feel like a stark novice. Again. This is getting tiring.

... As I've said before - time has passed, but you don't know that ...

I feel slightly less idiotic now. It would seem that depth checks to hide obscured geometry has to be enabled. I now seem to recall reading something about that long ago, but it must not have stuck. That and by sheer luck my landscape test worked without this enabled, so I never thought to look before. That's right, glEnable( GL_DEPTH_TEST ) has to be called before it behaves as I had expected. Yay for me. I'm not losing my mind.

Filed Under: Development - Game Development

So the time has come to implement the world space classes so I can contain a whole bunch of geometry and objects and camera's and other fun stuff in one space and render it appropriately. The issue at hand is how to handle the containers. Do I go with a more C style handle scheme, or just move autopointers around? I can see the autopointers being more dangerous and all, but the truth of the matter is that handles seem like a needless waste. I've always focused on code safety before flexability in the past, but treating the developer as a hostile component of the design process is tiring to write, and frustrating for both me and the developer. To increase the frustration even further it's very likely I will be the only developer.

Sometimes I'm just afraid that all I'm doing is making my own life more complicated. At the same time, I'm hardly immune to the bad code practices just because I wrote the library in question.

So, I've benn working on this for quite a while now, and I have to say that the translation from simplifed theory to concrete code has not been an easy one. All sorts of complications I hadn't initally accounted for, or had assumed there would be easy answers for, have presented themselves as serious problems.

Filed Under: Development - Game Development

So I've been giving graphics a lot of thought again, now that I've got at least somewhat a workable network layer. It's still missing a UDP executor, but my grey matter is still wrangling that for now. I've been wrestling with the rather odd quandry of how to consolidate a virtual inheritence tree with renderable objects.

As I see it, generating the tree isn't that difficult a thing. Since OpenGL is so nicely stateful, a renderable object would rather easily consist of things inside containers which are also things. This paradigm seems to handle everything quite nicely from the projection matrix down to the smallest triangle. The real problem is generating these trees intelligently, and rendering them in a relatively quick way.

Since the largest advantage of a tree structure like this is the virtualization of each object, it follows that they all have to inherit from a pure virtual base class they can be handled by. At the same time though, more complex objects like landscapes which contain potentially thousands of triangles would incur a huge overhead when dynamically dereferencing each of the child triangles. A couple of solutions to this problem seem apparent, one being that the virtually inheriting classes are simply inlining abstractions of non-virtual implementations, which would allow complex objects like landscapes, which will only contain triangles to contain only triangle implementations and therefore skip all of the virtual derefrencing necessary. The second option is simply to count on the compiler to know that the pointers actually point to the type they are referenced by, which seems to be a fairly consistantly correct assumption, at least while using g++.

The other problem is one I'm less certain how to resolve is how to cull the renderation, and calculate useful bounds for the children of each node. Since this structure is intended to hold all the objects in the scene, many of the objects will have continuously moving locations or changing bounds which restricts them from playing nicely in a quad tree, or any other structured tree which recursively crops invisible nodes. Perhaps a good solution is to keep two or more seperate trees, one which contains only a flat representation in which all the elements must be checked all the time, and another passive tree which can be stored as a quad or oct tree.

I suppose I can just write the code without the abstracted implementations and strip out the implementation code after if the compiler is generating dynamic casts all over the place.

On a more personal note, it's nice to be back on graphics, even if just for a while. I've been getting awfully bored of network abstraction, and there's still all of the scripting abstraction to do. Not to mention the fact that I haven't even picked a language yet for the script to be in. Probably lua, but I wouldn't mind looking into php since I already know it. My guess is that it'll be too heavy anyway, and there will probably be license restrictions since the final destination of this whole thing is a closed license product. Something tells me that a simple abstraction layer doesn't count as enough seperation to allow it to be linked into a commercial product without being properly license, and even if it was legally I would feel wrong about doing it anyway.

There's also the issue of a map editor, which I would assume will be one of the first projects after I've finished the chat and pong. Actually, it should probably be after (or consecutively with) the final rendering engine so I can see the results of the editing real time. And because I'm impatient.

Filed Under: Development - Game Development

I got started working so late tonight I decided not to even try to decipher any C++, OpenGL or anything else that required structure or precise syntax. Still, I wanted to try to accomplish SOMETHING. With that in mind I launched into actual game design for the first time in ages. I've become so caught up in details of implementation that I've sort of lost track of where I was trying to end up. I guess it's a good thing I've looked ahead a bit.

For a long time I've had some rough ideas of what I wanted to accomplish for my first game. A lot of those ideas have been trimmed off for the sake of getting something done. Of course, I've still got 'pong' to write, but it isn't really so much of an achievement as proof that I can actually write something from creation to completion. It sort of sucks to have a great idea in your head, and to have to start cutting big pieces of what makes it cool off just to make it realistic. Not realistic in a 'reality vs. fantasy' sense. Realistic in a 'this will take me 2 years vs. 10 years' kind of way. What I really hope is that I can build this thing in such a way that when I'm done, I can just launch right into the extra stuff I wanted to begin with. Hopefully the structure it's being built under will allow for something as simple as that.

Anyway; the whole point here is that I may be looking at a lot more trimming. The original Nova-2 that spawned this whole silly library, and jump into SDL was going to encompass an idea that I think is really going to take off in the gaming world. That's right, I'm going to put down a prediction here in psudo-writing so I can look back when I'm 40 and say, good lord, if I had just finished ANYTHING when I was younger, I'd be rich now.

Convergence. That's what it's all going to be about in a few years. Taking that wicked-ass 1st person shooter 3D engine (who's technological merits alone will no longer sell) and joining it with a MOO style RTS, and connecting that all to a Starfleet Acadamy type combat space combat simulator. Then shake the whole thing up (a la shake and bake) and stick it on the net; where thousands of people can be playing in any of those modes, and seemlessly switching between them, all affecting one another. Order your starship to sector X, then run through your ship from the bridge to the hanger bay and hop into a shuttle, then fly the thing down to the surface of planet Y and hop out and drive transport Z to city K to sell cargo C that you bought in sector T from planet L.

Ahem.. Yeah. You get the idea (I).

The point is, people are getting sick of just doing one thing, and that one thing not having lasting, useful consequences. For ever and ever that has been the two routes a game has to follow. Either I'm going to be online and have some psudo-tripe story line in which I get killed 50 times a night accomplishing nothing but building experience I can use to die 45 times tomorrow night - or I'll play a single player game and drive to New Reno to run drugs for a crime lord, while solving a murder case and saving the world as we know it.

Not to metion that in either of the above cases I'm doing it within a strict and ridged framework where all specifics are shoe-horned into an interface that doesn't suit them, or specifics are left out entirely. I mean come on, we've all used the same dialog window to talk to people, operate computers, pick locations and buy items. It just doesn't make sense.

The first company out there to create a comprehensive and cohesive game world in which people can actively and intelligently interact with all of the important aspects of that world, is going to be stinking rich. A framework where people can live out a life that's close enough to real life to visualize ourselves in and remain sane, and open enough that we can do all the stuff we want to do in real life but can't. Largely because mistakes result in horrible (and rather permanent) death.

Well, as much as I'm enjoying this particular rant. It's now almost six in the morning, and there's a great deal of things to do tomorrow that I really should have done today.

Filed Under: Development - Game Development

Wow, it's been a really long time. I managed to get through a whole month without even an innane and incomplete journal entry. That actually requires skill. Yeah, skill. So to catch up, I suppose I should take a look at some of the older journals to see where I was a month ago, but I'm lazy, so I'll just duplicate.

Things have been moving, even if I haven't been posting journals. There have been a few source releases, but without any applications or documentation, those releases are little more than offsite backups. Apparently there have been a few downloads of the code there, but I haven't seen any feedback. I guess one can only expect feedback from maybe 1 in 60 or 70 users, so I've got a few YEARS at this rate to wait before I see anything. Since the download page is sprawled with warnings not to download anything, I'm not particularly suprised.

What's new, what's new... I've ditched the idea of writing intermidiate games. I just can't spare the time. I figure if I write a game and it turns out to be crap - THAT can be my learning game, and I'll start again. With that in mind I've opened up my focus a little to include the game engine rules, admin code for editing assets and artwork and things, storyline and more core classes to get underway. All game asset administration is taking place in a PHP/HTML/MySQL environment, the idea being that data pack files can be generated from the script straight out of MySQL. This let's me mix in some of my existing knowledge with all the new stuff I'm learning. On top of that, with a little work it's a nice multi-user, revision aware system for people to contribute artwork, game rules, maps, sounds, music, dialog... everything straight into the project code without having to dink with a seperate editor.

Right now all the game assets are internationalized in the database, so when I export a data file for the game it can be configured for English Canadian, or German, or whatever. All of the game assets including dialog, art and trigger files can be modified based on region. That gives a nice upshot that I can lower violence levels, profanity, adult content, whatever pretty easily based on region. This isn't something that I realistically need, but it sort of comes for free from building the admin tools in a language and platform that I already know well. Besides, I've wanted to write this as professionally as possible, even if it isn't really professional grade. That way if it ever comes to the point where I write games for myself I won't be suprised by any hidden complexities.

To facilitate all this PHP driven asset creation, I've needed to build some classes in C++ to read and use generic variables. That's been an interesting process, but it really increases the flexability of the engine. I think. For example I can specify a game rule for the advancement of a characteristic in PHP something like "5/4*15" (which is totally fictional, of course) and the C++ can interpret the variables in a typeless way. It also means I can build big lookup tables keyed by typeless variables, containing typeless variables and get reasonably fast lookups in C++, but with arrays built in PHP. The upshot to all this is that game rules, triggers, maps and everything else can be modified by just editing a data file instead of changing code in the engine. It also opens new avenues like dynamically loading new characters, maps and items runtime right out of a PHP script living someplace on the net. It could be interesting to have played a single player game for 6 months, and to suddenly have a new town, and new subquests added all over the place in the game.

Aside from all this stuff, the rendering engine is moving forward a little too. I've got better classes for handling system messages and timing, as well as some rending objects like cameras, etc. that use templated containers. It'll be nice because I can build a camera, for example, that has a frustrum culling container I can just feed geometry into and watch it chop off unrendered segments without really having to worry about how it's all happening. It also means that I can have multiple cameras really easily, though I don't really forsee any reflections, or single screen multiplayer stuff, so it's doubtable I'll really ever use that feature. Oh well, I'll know it's there.

Aside from the PHP and C++ advancements I've spent a fair amount of time on the game rules themselves. With the help of pierre and druid I've been able to iron out some long standing issues with character management and skills... and a bunch of other stuff. So semi-progress on all fronts.

All fronts except storyline, I'm afraid. There's still a whole lot of detail that doesn't exist about the games actual story. Arguably the most important element of the entire game design. For some reason my imagination seems to be having a hard time isolating ideas that I really want to attack. There is so much potential, and so little time... I really want to divise something reasonable, but enjoy what I'm working on at the same time. I never really thought this would be a hard thing for me to do, stories were never an issue. The truth is I feel like I'm makeing the least progress with it, though. Hopefully my creativity gene will kick in sometime soon. I'll need to start establishing some fairly solid mood and scene characteristics soon if I want to get the asset aquisition under way.

Anyway, I had wanted to get into some examples of the new typeless variables code, and show some screenshots of the new camera class at work, but I'm thinking instead I'll put that off to the next journal. Maybe I'll feel productive enough to attack that later tonight. For now I think I'm going to give my brain a brief rest and take in some "Enterprise" which we've discovered we can from mpeg's off the net onto VCD's and watch in our DVD player :).

Hopefully you'll hear from me again tonight. Not for your sake, but for mine. :)

Filed Under: Development - Game Development

Ups and downs indeed. Hardly the later in the same day update I had intended, but I figure now is as good a time as any to try to get back up to date.

What's new? Found some great tutorials for OpenGL, starting at the simplest concepts and branching out to some really complicated stuff. Very useful indeed. I've put up absolutely huge amounts of documentation for libN2L, though it probably wasn't a terribly good idea since a great deal of it is likely to change. Luckily the documentation is all automatically generated by a great little software package called doxygen so the changes won't be hard for me to update, though I'm afraid anyone interested in the library may get frustrated at the instability of everything. At the same time there are two important things to remember: 1) the only one insane enough to download my updates up to this point is google, as far as I know, and 2) if the bright yellow text throughout the download page telling people not to download this wacky thing isn't enough warning, they deserve the discomfort.

New in the code is a reworked cRScene class, and the mechanism used for grouping renderable objects. It feels a lot cleaner from a coding perspective... but alas at the moment it doesn't seem to be working. Devil is in the details, so they say. More important than the changes in the rendering code is the cementing of the dynamic equation classes cDynVar, cDynEquation and cDynVarSystem. All seem to be working well and are really kind of neat to work with. I'm looking forward to doing more game code so I can really see what this stuff can do. Cause I love examples, here's a small one:

0001 cDynVarSystem system; 0002 cDynVarEquation eq; 0003 0004 eq = "((a+b)/c)*2"; 0005 system.set("a",55); 0006 system.set("b",8); 0007 system.set("c",3); 0008 0009 cDynVar c = system.eval(eq); 0010 0011 cout << c.dump() << endl; 0012 // Outputs: int(42)

To many people that may not seem like a terribly exciting thing, but I think regular C++ programmers will appreciate it. The cDynEquation class parses the equations it's given when assigned, so executing the code is fairly quick. Of course I'm not suggesting that geometry be frustrum culled with dynamic equations, but the speed should be more than enough to calculate character speeds, skill tests and experience advancement.

In the gameplay universe; rules and item lists are coming along nicely. Quite a bit of progress has been made in ironing out the last stickyness of character creation and things are looking pretty good. I've got about a million ranged weapons cataloged, and now I'm just working at cutting off what I don't want in the game. The storyline itself is in place, at least the core of it. No maps, locations, characters, dialog or anything else worth mentioning is done, but the storyline brief itself has been drafted and it seems to be getting positive responses from my 'testing group'. All like 4 of them.

pierre has done a great little prototype of a logo for the game. The art is really impressive. I'm not sure if the design itself will last to 'shipping time' if such a thing even exists but in the interm the sheer coolness of it is more than good enough to make it the semi-offical logo. I'll be getting a site up with it as soon as he finishes it up and gets it to a state he's happy with.

That actually brings me to the topic of websites quite nicely. The internal development site fore life2130 is comming along ok, though I haven't found much time to work on it lately. The production site has most of a logo done (see last paragraph :) and that's about it. I've plugged the libN2L site enough that I'm sure anyone interested knows exactly its state. And... yeah. That' wraps up websites.

What else, what else... I'm sure there are lots of things I haven't covered, but for now I think I'll leave it. Hopefully I can get the render working again tonight. Then off to bed.

Filed Under: Development - Game Development

Where to begin? It has been over two months since I last wrote a game journal, and the libN2L development page is even further out of date. So, is that the end? Is there no more Life2130? No more libN2L?

Nay!

Nay I say. No, in fact things are cooking along nicely. I'm just a useless boob that doesn't have the attention span required to write regular development journals. But all that's going to change as of tonight.

So, as I was saying; where to begin? Well, scanning over my last entry I see that quite a lot has changed. The suggested Life2130 site is now up and running right here, and new libN2L updates are in the pipeline.

I guess first I'll go over the new stuff and changes in libN2L, since it is the root of all of the development I'm doing right now. Firstly, the version for the library has been bumped again, so now it's libN2L-4. The version was bumped because of a file structure revamp and a new naming protocol which I'll be putting up on the libN2L Development site soon. I've also renamed a few classes, and restructured the video class tree a bit, so it didn't seem right to keep with the same version any longer.

Along with the format and structural changes, libN2L has a few new rendering classes including a camera class, and some basic code to allow billboarding. The real excitement right now is the addition of md2 file loading, with basic support for animation. The interface for it is really rough and it leaks like crazy, but it does work. Soon I'll be polishing up the interface and cleaning things up and it should be good to go for our first tech demo. For those of you who care, here are some screen shots of a model in my test environment. They are actually both moving, so it's kind of neat.

Along with the addition of the md2 loader I've been working with particle effects, which is pretty much hand-in-hand with billboarding, at least axial aligned billboards. I've been able to get some pretty neat stuff working in the test environment, but nothing has been integrated into the library yet. I'm not sure exactly what kind of interface I'll need for particle systems so rather than rewrite a dozen times I'll put it off until after or during the first tech demo. That way I'll have some experience working with them. Anyway, once again here are some screen shots.

What else... what else. I've also added some utility classes to work with the VFS to load configuration files, and to validate the settings defined inside them. It's a pretty neat toy with arguably useful application. The basic idea is that the game can create a configuration file template outlining what values it expects to be defined, along with default values if they aren't, and it can have a list of validators attached to it. Validators like vfs node types, it must be a file, it must be a directory, it must be a image, etc. The types can also be more generic like must be a string, must be a float, etc. The whole thing is set up using the dynamic variable system, so the values assigned can be used without any conversion from the file.

Anyway, Onyx awaits. It still needs a site, and I've got some last work to do with the engine before starting. And I'm not getting any younger.

Please note: Nothing is going to change, in fact. Journal updates will be as infrequent as they are now, forever.

Filed Under: Development - Game Development

Yay, updates. So I've been spending lots of time reading about lighting and trying to figure out the best/easiest way to light things in Onyx. Right now it would seem that the best thing to do will be to use regular GL lighting to create the simple shading effects (making things look 3D) and use a modified patch/lightmap for each ship to paint hilights caused by engines, explosions and weapons fire. I'll write more when I have a better idea what I'm doing. Right now lighting is still a bit of a mystery to me, so I'm not sure anything I'd say would be even remotely correct.

Fixes. There have been quite a few fixes. And, there have been quite a few fixes of fixes. The most notable of these bumbles would be my 'fix' to the cGlTexture class to enforce that all textures be sized of the form m^2 by n^2. Basically that textures had to have a size like the following, 16x16, or 32x256 or 512x2048, etc. I have no idea where I read that requirement, but it seems it should have been 2m by 2n. The xSize and ySize only have to be divisible by two, not some power of two. So a whole lot of ugly code to fix that mistake has been removed and a bunch of new ugly code has been put in to fix that requirement.

Along with the fixes I've enhanced the cSurface interface quite a bit to allow more sensical access to the surfaces, as well as some simple primitives to manipulate them. It's truely awesome to have a good software surface API like SDL to be able to muck with things before they get into texture memory. It allows all sorts of trickery like the true type font texture generation that I'll be talking about soon. It really is priceless to have a solid community and well written interface to all these low level things. I can't even imagine trying to do a graphical project without it.

Along with fixes, I've added font support to libN2L, which was a long time coming and a LOT easier than I had expected. Right now I'm only allowing texture fonts, what Photoshop/Gimp people would know as a bitmap scaled font. Luckily, with some surface trickary using SDL I can generate a bitmap font on the fly from a True type font, which makes importing fonts into the engine wicked easy. Eventually I'll have to make some class to support the actual geometry of true types, but for now I'm content with using prerenders. They're anti-alised and mipmaped by any arbitrary quaility level, so it isn't like they're ugly... and when they get converted into a texture font it's wicked fast to render them. So I'm not going to be complaining any time fast.

Thanks again to SDL, the whole thing is tied in and working well with the virtual file system. I was worried for a bit when I saw that SDL_ttf didn't have RWops support but apparently the newest version has it built in, which saves me a lot of tinkering with code I don't understand. I'm a little disappointed that Red Hat is still distributing an old version of SDL's runtime but I would imagine by time I'm ready to release Red Hat will have caught up. It doesn't matter that much anyway since any binary public release I do will all be statically linked anyway.

A good friend of mine asked just a couple of days ago if Life/Onyx/? was going to run on Win32 and I said yes, but there's a good question buried in that question. Does it? The last test build I did on Win32 was over a month ago, and there's a lot of new stuff in the codebase that hasn't been tested. There's also quite a few outstanding problems that I had to jiggle the handle to get working in Win32 LAST time. I can only imagine how much there is now. I'm really getting a sinking feeling that I'll have to waste some time soon getting a test environment set up on my machine to build Win32 versions. All this is forgetting that my successful test months ago was only building libN2L, not any test application itself. I seem to remember that when I tried to build the particle fountain toy the linker went nuts, and I never found out why. I'm just assuming that my ignorance of Visual Studio was the problem. Hopefully.

Speaking of compatibility, I haven't even TRIED this thing on OS X yet. My girlfriend has a Mac in the apartment, but I haven't installed any development tools on it, so I'm really not sure what's going to happen when I actually try to BUILD anything, let alone run it. I guess I've just been assuming that Darwin's UNIX roots would make it easier to cross-compile than windows. I hope that doesn't turn out to be a big mistake. I just loath the idea of wasting a whole bunch of time setting up a test environment. Bah... some day.

I took some of pierre artwork and twiddled it a bit to make a desktop. I'd like to put it up, but the bastard hasn't emailed me back with his approval. I'd do it anyway but I know he'll have a hissy-fit if he thinks it's as ugly as I suspect he will. Oh well, works for me at least. *rolls eyes* Artists.

Speaking of pierre, he's been learning some 3D graphics stuff himself. I never stop being amazed at how quick he's learning, and it really, really PISSES ME OFF. Bastard. I'm thinking he's going to catch up and pass me in a matter of weeks. I can't even begin to explain how depressing that is. Of course, he IS learning DirectX, and you know what Master Yoda says... "If you choose the quick and easy path... you will become an agent of evil."

I think that's been a long enough break. I'm getting more into keyboard handling and I'm going to slap together some quick GUI widgets so I can move onto the Onxy startup. Now that I have fonts, and will have simple widgets I think it'll be time to actually focus on the game itself. Now that I'm only about 3 months late, it's about time.

Filed Under: Development - Game Development

So, yeah. It would seem that textures in fact must have power of two dimensions. How in gods name there's so much discussion about using non-power of two dimension textures alive and well on the net is a total mystery to me. Maybe some magical property on the card has to be toggled, or diddled or twiddled before it'll work, but you know what? I just don't care. That's right. This is me, not caring. La la la... still don't care.

So now I'm going around the code dutifully un-fixing the texture creation code. And let me tell you this, it's great fun.

Disclaimer

The preceeding journal entry had absolutely no value, and should not have been read by anyone.

Filed Under: Development - Game Development

I've been hammering away at this thing for a few hours now... I guess approaching 9 or 10. Unfortunately (for this stuff anyway) I have contract work to attend to tomorrow, so I have to turn in early. Early being 5am.

Anyway, the stream code is looking good. The compile time is awfully high already because of the templates, but the code is simple and modular, and really flexible. I'll be using this streaming code as the foundation for runtime logging events like errors and messages, system events like mouse movement and keystrokes, network server/client abstraction and quite possibly the GL rendering pipeline. I'm not sure the speed will be adequate for the pipeline, though. It's very likely I could implement a direct translation and skip any buffering, which would allow the same interface and syntax to be used for the rendering pipeline as everything else. Unfortunately, I don't know enough about GL yet to give an intelligent opinion.

Regardless of OpenGL's direct involvement, I'll be able to move forward with porting over more signifigent things like system events now that the streaming arch is done. Hopefully I'll be able to whip something up tomorrow to move a pointer around the screen with the real event management and a hacked GL renderer.

This whole streaming stuff has turned out to be pretty darn nice. Already in just testing it I can see a whole lot of possibilities. Best of all I should be able to implement lots of different applications of the streaming seperately of eachother and keep everything nice and bite-size. With the events, I think I'll look into creating a threadsafe stream varient that can have system events pumped into it with a timestamp so I can pull them out at my leasure. That may not even be necessary, though. I really hate having libraries that require the regular call of a generic 'update' method, though, and I'm not sure how else to get around the problem. Perhaps a globally registered n2lUpdate() call or something that'll pump system events and do any other housework that needs to be done.

Perhaps it wouldn't even be a horrible idea to have the gamecode initalized somewhere other than 'main', and to have the developer call n2lRun( x,y,z, myMain ) or something instead. I hate creating overlays like that, but it might do a good enough job of hiding everything away that it would be easier in the long run. Actually, it might be kind of nice to have some kind of central updating service that can run any number of methods based on oscillators. If the game code were broken down into a rendering, event processing and networking etc. subsections, they could be added as members to a created n2l object all with their own calling frequency and order. I'm a little nervous about keeping things unthreaded, though. I'm even more worried about moving to threading. There's a whole lot I don't know about threadsafing, and I'm worried that I'd just end up slowing things down anyway.

I suppose my only real consern is with the OpenGL flip that waits for the screen refresh before proceeding. With monitor refresh's in the 60hz range... potentially a lower, that would set a huge number of artificial limitations on the system. I'm worried that system event processing and worse, internal game state processing could be seriously choppy with the introduction of a forced wait.

To be honest, though. I'm not even 100% sure that filp waits for the refresh in userland. It may hop off into some wonderful magic land and immediately return... in fact, I can check that out if I dump the framerate of my stupid OpenGL test from a couple of weeks ago. Uno momento...

You can't tell, but time has passed

Well, I don't know if it's video driver dependent, but it would seem that my monitor is set up on a 65hz clock, and I was able to get 100+ fps... so it looks magical. Or unsynced. Unsynced is bad since I'll be looking for a way to sync it later. Oh well. Let's count on magic for now and we'll see what the future holds. I don't see it being THAT hard to implement a threadsafe stream type and turning that into the GL pipeline. Then everything could go along happily with the stream rejecting new geometry while it was waiting for a sync. I'm really thinking that's not going to be necessary, though. I must admit, I'm pretty excited. With a rather minimal amount of effort I've been able to see some real results. It's a long way from a game, but it's still encouraging. I suppose time will tell. And now. I must sleep.

Filed Under: Development - Game Development

Well, we're now into 2003 and it would seem by all external accounts that I've once again stopped working. Alas my pets... I have not.

I've been busy, busy. There have been so many additions and changes to the library I don't even know where to start describing them. First I'll say that I've left OpenGL for a little while to attend to some other engine matters that need attention. The largest target of that attention has been the networking code.

After a few days of work I think I have it nailed down pretty good. It should be interesting to see how things hold out under any pressure, but for the time being everything seems nice and stable.

I've been putting lots of time into design for the actual GAME project and I'm getting pretty excited about it. I won't go too far into things for now. Soon enough there'll be a whole section of this site devoted to it, so no point in duplicating work. For the moment I'll first be focusing on smaller benchmarks. The first will be a simple multi-client chat server. It's going to be boring as hell to make, but it's a good way to test the networking code as well as create an arena for the construction of some character capturing routines.

After the chat server and client are done, a pong game is in the works. It's dumb and I hate to waste the time doing it, but I think it will be critical in shaking out any bugs in the networking layer, the graphics code, interface... everything. Most importantly I need to shake out some of the bugs floating around in me. I have many (at this point, while untested) brilliant ideas about how to arrange game structures and client interfaces so that networking, AI and local interfaces will be 100% abstracted. It should make for nice clean development.

To be honest though, I'm beginning to worry a little bit about the expense of some of these ideas. Data spends a lot of time just moving around and changing types. I'm wondering how that's going to play out when it comes down to a real game environment. Especially in a large scale RPG where lots of things are happening all the time. I know I constantly underestimate the processors abilities, but it still feels like a lot of work is going on that shouldn't be.

Well, regardless of all these wonderful issues - the largest issue at hand for me right now is to get to bed. This journal was started around 3:30 or so, but it's now 6:30 - and I have a very long day with a lot of work to be done tomorrow. I'm hopeful that I can have SOME kind of functional chat code working by the end of the weekend.

Things are moving along quite well. I'm getting pretty excited about the whole thing. I have to be honest. I just don't want to get too far ahead of myself.

We shall see.

As a last note, I'm going to leave behind two examples of the new networking code. The first requests google's homepage! Of course, it gets a redirect to the www.google.ca site, but it still completes the request perfectly. That's right. Five lines of code is all it takes.

0001 n2lStartup(); 0002 0003 cNetworkAddress google("www.google.com:80"); 0004 cTCPSocket webHost(google); 0005 cNetworkMessage httpRequest("GET /index.html HTTP/1.0\r\n\r\n"); 0006 cNetworkMessage httpResponse(4096); 0007 webHost << httpRequest >> httpResponse; 0008 0009 n2lShutdown();

This example shows all that needs to be done to create a TCP server and client, connect them together and send "Hello?", then respond with "Hi!".

0001 n2lStartup(); 0002 0003 cNetworkAddress listenAddress( 63212 ); 0004 cNetworkAddress connectAddress( "localhost:63212" ); 0005 0006 cTCPSocket listener(listenAddress); 0007 cTCPSocket connector(connectAddress); 0008 cAutoPtr<cTCPSocket> connected = listener.accept(); 0009 0010 cNetworkMessage request; 0011 cNetworkMessage response(1024); 0012 0013 request = "Hello?"; 0014 connector << request; 0015 *connected >> response; 0016 // response is now "Hello?" 0017 request = "Hi!"; 0018 *connected << request; 0019 connector >> response; 0020 // response is now "Hi!" 0021 0022 n2lShutdown();