Obviously the first step is to create charges that contribute to an electric field. The simple solution is to turn the points on the attractor into electric charges, lets say electrons. We now have a collection of charges creating an electric field. The next step is to implement Coulomb's Law.

The scalar form of Coulomb's Law states that f = k * ( (q0 * q1) / (r * r) ), where k is the Coulomb constant, q0 is the charge of particle 1, q1 is the charge of particle 2, and r is the distance between the particles.

There are a couple things to note about this equation. Most importantly is how the sign of the charge on each particle effects the sign of the force magnitude itself. Two charges of like sign result in a positive force, and two charges of opposing sign result in a negative force. Also, this equation simply gives the magnitude of the force, there is no direction associated with it.

To get a resultant force vector is quite simple. We take the vector formed by the two particles, and reduce it to unit length. We then multiply this unit length vector by the scalar magnitude of the force as determined by Coulomb's law.

To create a "field", we have to find the cumulative force felt on a charge from all sources. So to put it in programmer language, for each individual particle we iterate through all the charged particles in range, accumulating the force vector for each to create a resultant overall force vector. It can be said that this resultant force vector represents the field at that given point.

Obviously we can then resolve this force into acceleration knowing the particle's mass. Maintaining a velocity vector for each particle, we can use this acceleration to create a realtime simulation of the particle's motion through the field. As the position of these particles change, the field changes, creating a feedback system. Any lover of chaos knows we have established the prime requisite for a complex system. Hopefully we can stir some emergence from this system.

Applying these rules to a simple collection of electrons isn't very interesting. The cloud of electrons just explodes outward, and continues on to infinity (assuming no dampening). We need to add some positive charges to the mix, and shake it about. For the interest of science, let us create atomic nuclei with a charge much greater than that of a single electron.

Throwing a couple of randomly positioned positively charged nuclei into the simulation does indeed spice things up. Now we get quite interesting swirling clusters of electrons, some maintaining orbits strongly resembling electrons in the common depiction of the atom.

Sometimes an electron will approach a nucleus on just the right vector and get very very close to it's true position. This causes the denominator of the Coulomb's Law equation to approach zero, and the magnitude of the force to skyrocket. This results in the electron being flung off into space at high speeds. I wanted to address this problem, as it didn't jive with the aesthetics I hoped for.

I remember watching an episode of Fringe not too long ago, where two people were discussing the collision of two dimensions. One of the individuals dropped a reference to the Pauli Exclusion Principle, and then smashed two snowglobes together for effect. This principle explains much about the structure of atoms, and applies here because of what it says about electrons orbiting the atomic nucleus. Exercising some artistic liberties with the interpretation of this principle, I made our nuclei exert an exponentially increasing opposing force on electrons that approached too closely. If you wanted to add some scientific rigor, it would be elementary to make definitions on the characteristics of each nucleus, and apply a different force gradient to approaching electrons based on how many were already in orbit. You could easily create electron shells where the outermost (valence) shell could contain electrons that could easily be pulled off by passing nuclei, just like in chemical reactions!

I didn't go so far as to create multiple shells (yet), but the initial results are promising. The electrons around the nucleus form self-organizing spheres, as they seek the lowest energy by spacing themselves evenly across the surface. When multiple nuclei are interacting, its neat to see how the charge density changes and the electrons pack themselves more densely on the sides of the sphere facing nearby nuclei.

I'm looking forward to modulating the charge of nuclei based on realtime audio FFT data.

The NDS application exhibits much code that is ancillary to the main purpose of the project. Being a platform that is rarely developed for, there is only a small community focusing on NintendoDS development. I figure that any code that exploits the features of the DS or establishes a framework that can be extended and used for new purposes is a good contribution to the community. I won't cover this ancillary code, but be sure to download the project and examine the extra bits like the chat server that will let you telnet into your DS.

The basis of the NdsInterfaceClient is simple. On start, it displays some information about the DS it is running on, and then prompts the user to press B to get a list of wireless access points (APs). The code then calls Wifi_ScanMode(), and enters a loop that constantly polls the number of APs, collects information about each, and displays this information on the screen. The Wifi_ScanMode() call actually tells the dswifi library to poll and maintain an internal list of available APs. You can then query the length of this internal list using Wifi_GetNumAp(), and then get specifics using Wifi_GetAPData(...), passing the index of a particular AP.

For the AP list, I reused some code written by Stephen Stair (the author of the dswifi library). I added some ANSI color for readability, and changed the format for AP data so it offered more info, particularly letting the user know if an AP was WAP protected (and thus unusable by dswifi). One of devkitPro's first feats was to implement a console on the DS. The state of this implementation today is quite elite. The console supports ANSI escape sequences, which allow coloring text and arbitrarily relocating the cursor position. One could create an ASCII game using the console and escape sequences alone. The chat server code shows how to use escape sequences to create a "window" in the console.

Once an AP is selected from the list, the code will determine if the user needs to enter an encryption key. If so, a keyboard appears, and allows the entry of an encryption key. The user can enter either a 40b or 104b encryption key. Based on the length of the entry, the code determines if it is 64 or 128-bit WEP encryption, and attempts a connection to the AP. This is one of the least documented basic steps for using dswifi, and on top of that, there are some curiosities worth mentioning.

WAP encryption is unsupported by the NDS and NDS Lite. Support for WAP was added to the DSi, but it isn't likely we'll see it supported by the dswifi library any time soon, if ever. We are limited to using WEP-secured APs. There are two levels of supported WEP encryption, 64-bit and 128-bit. Here is where a curiosity appears. Both 64b and 128b WEP encryption use a 24b Initialization Vector, which is not included in the length of the encryption key you enter. So the actual length of the entered encryption keys for 64b and 128b WEP encryption are 40b and 104b, respectively. It is fine to refer to these encryption levels as either bit length including the IV, or bit length excluding the IV. Strangely, the dswifi library does both, and defines the following two values: WEPMODE_40BIT and WEPMODE_128BIT. It should be obvious which is which.

So, with the keyboard displayed a user can enter the ASCII representation of a 40b or 104b hex key, which is either a 10 or 26 character long string, respectively. We then need to convert this ASCII representation of a hex value into a 5 or 13 byte actual hex value. To accomplish this, we look at each character in the string and convert it from it's ASCII value to it's hex value. We then pack two of these hex values into a single byte (unsigned char), and append each byte onto our encryption key. Once we have 5 or 13 of these bytes, we pass them to the Wifi_ConnectAP(...) function, and wait for the connection to succeed or fail. This is accomplished by polling Wifi_AssocStatus(), waiting for it to return ASSOCSTATUS_ASSOCIATED, or ASSOCSTATUS_CANNOTCONNECT.

Once we successfully connect to a wireless access point, our DS will be assigned an IP address (we assume the use of DHCP). Now connected to the network, we can then start using functions like gethostbyname(...) to look up DNS entries, or connect(...) to make socket connections to remote hosts. Things are finally getting interesting. To provide a user interface to a variety of functions, we print a simple menu, with each DS button bound to a different function, and wait for a keypress:

 
if(status == ASSOCSTATUS_ASSOCIATED) while(1)
{
	u32 ip = Wifi_GetIP();
 
	consoleClear();
 
	iprintf("\n");
	iprintf("ip: [%i.%i.%i.%i]\n", (ip ) & 0xFF, (ip >> 8) & 0xFF, (ip >> 16) & 0xFF, (ip >> 24) & 0xFF);
	iprintf("--------------------------------\n");
	iprintf("Press Y to nslookup host name\n");
	iprintf("Press X to connect to interface\n");
	iprintf("Press A to listen on socket\n");
	iprintf("Press B to break\n\n");
 
	keypressed = 0;
	while(!(keypressed & (KEY_Y | KEY_X | KEY_A | KEY_B | KEY_L)))
	{
		scanKeys();
		keypressed = keysDown();
	}
 
	if(keypressed & KEY_Y)
	{
		//execute gethostbyname(...)
	}
 
	//etc...
}
 

Now the code governing the interaction with the Host interface is very similar to the code in the NdsHostInterface application. We synchronously send a register signal, receive the signal port (and data port) back with the register acknowledgement signal from the Host interface. We then use this signal port to construct a listener, and this data port to pipe input data to the Host. This is the main loop of the NdsInterfaceClient:

 
while(1)
{
	tvTimeout.tv_sec = 0;
	tvTimeout.tv_usec = 1000; // This will throttle the data xfer rate just a tad...
	// I've found that anything less than 1000 microseconds will make select return immediately
	// when called on the DS platform
 
	FD_ZERO(&fdsRead);
	FD_SET(sktServer, &fdsRead);
 
	retval = select(1, &fdsRead, NULL, NULL, &tvTimeout);
 
	if (retval == -1)
		iprintf("select() error\n");
	else if (retval)
	{
 
		if((sktClient = accept(sktServer, (struct sockaddr *)&adrSignalClient, &iClientSize)) < 0)
		{
			iprintf("Failed to accept client connection.\n");
			continue;
		}
		iprintf("Client connected: %s\n", inet_ntoa(adrSignalClient.sin_addr));
		InterfaceSignalHandler(sktClient);
	}
 
	// If there are no signals from the host, and pen is down, send input data on UDP port.
	if(keysHeld() & KEY_TOUCH)
	{
		touchRead(&touchXY);
		pos = 0x00000000;
		pos = (touchXY.px | ((int)(touchXY.py) << 16));
		iprintf("Sending 0x%x", pos);
		sendto(sktData, &pos, 4, 0, &adrData, sizeof(adrData));
	}
 
	scanKeys();
	if(keysDown() & KEY_B)
		break;
}
 
// Broke out of main loop, so unregister from Host and shutdown...
 

That is really the jist of the NdsInterfaceClient. Obviously check out the source code to see how to appropriately construct sockets. In my last article in this series, I'll provide links to the complete source code for both applications. I might take the time to make the NdsInterfaceHost compile on Windows as well as Linux and OSX, but no promises. I'd rather leave the standard Berkeley sockets implementation alone, and let you port it to winsock yourself... or even better let you install a REAL operating system, and run it there. =)

I don't want to go any further without laying out some terminology to use. This project will consist of two parts, an application running on a PC, which I will refer to as the "Interface Host", and an application running on a NintendoDS, which I will refer to as the "Interface Client".

The host application as you may know will be rendering a cube using SDL and OpenGL. It will have a socket listener that will allow the NintendoDS to connect and negotiate terms by which it will send input data to the PC. I wanted to make the project simple but at the same time built with a framework that can be easily extended to do even more interesting things like pipe audio from the DS to the PC or something of the like. In order to do this, we'll define a simple protocol.

The protocol is quite simple. The Host machine will have a TCP listener that will allow Clients to connect and register. Once registered, a Client opens it's own TCP listener that will allow the Host to send commands to it. These listeners are used for signaling, or sending commands back and forth. I will use the terms signal and command interchangeably. After establishing signal listeners on both ends, there is a channel by which communication between the applications is simple. They can use this channel to negotiate terms for a transfer of DS touchpad data, for example.

By having an array of agreed-upon values that correspond to specific signals, and expected data to follow those signals, the applications have the foundation of a protocol. There may be more to the protocol as well, such as an expected order of operations. Again with a focus on simplicity, let us outline a protocol:

Nds Interface Protocol

The idea here is that the machines first negotiate with one another, eventually establishing a method to transfer data from the client to the host. All negotiation occurs over TCP, but the actual data transfer will occur over UDP on an agreed-upon port. I won't go into details of TCP vs UDP. There are articles on the net written by people far more qualified than me if you are curious. The basic reasoning is that we need the negotiation to be reliable, but we can tolerate a missing data transfer. Although in theory a series of UDP packets sent over a network can arrive at the destination in any order, I have never seen this happen in practice. Perhaps because all my practice has been over a LAN... maybe things over a WAN would be different. Regardless... UDP works great in practice and provides the benefits of being simpler and carrying less overhead. UDP is generally used for realtime streaming applications where a lost transfer doesn't break the overall functionality of the system. This is exactly the situation for our input data.

The host machine opens a listener on a port the client knows to look for. The client connects to the host machine on this port, and sends the Register signal. The host responds on the same socket with the RegisterAck signal. This acknowledgement signal is followed by a 32-bit integer telling the client what port to open as it's own signal listener. The host then knows how to communicate with it's newly registered "node". After constructing it's own signal listener, the machines can have any number of conversations initiated by either end. Each conversation will typically occur over the same socket connection, and consist of a signal followed an acknowledgement signal w/ a data payload. A simple beowulf cluster could be implemented using this design. Typically deployed over a non-homogenous array of machines, a beowulf host might send a signal to query each node's capability and the node might respond with the time it required to crunch some numbers using it's potentially unique hardware specifications.

The first applications I wrote that implemented this signaling design used multiple threads. The main thread was the signal listener, and when it got incoming connections, it would accept them and then pass the connected socket to a newly spawned thread that would handle the signal from the client. At the time, I thought this was an elite implementation, and without a doubt the best way to accomplish things. I then got myself into situations where I wanted to construct a signal listener either in a project I didn't want to implement threads or on a platform that doesn't support them. Enter the select() system call.

Multiplexing in a single thread, now THAT is elite. Using select(), you can easily monitor a listening socket for new connections while still handling signals from new sockets and even sending data every frame. The innermost loop of our Interface Client application on the DS will do exactly this. It will be managing the signal listener, handling any new signals and sending touchpad coordinates over the established data socket.

Here is what this synchronous code would look like inside an application's main loop, here being part of the Interface Host's main loop:

 
while(!g_bDone) // Pseudo main loop
{
	// Check listener for new signals. This is done in a time-sensitive manner
	//using select to return immediately if there is no data/connections present.
	tvTimeout.tv_sec = 0;
	tvTimeout.tv_usec = 0;
 
	FD_ZERO(&fdsRead);
	FD_SET(sktHost, &fdsRead);
 
	retval = select(FD_SETSIZE, &fdsRead, NULL, NULL, &tvTimeout);
 
	if (retval == -1)
	{
		cerr << __FILE__ << '@' << __LINE__ << " : select() error waiting on accept." << endl;
	}
	else if (retval)
	{
		cout << "Incoming connection..." << endl;
 
		if((sktClient = accept(sktHost, (struct sockaddr*)&adrInterfaceClient, (socklen_t*)&iClientSize)) < 0)
		{
			cerr << __FILE__ << '@' << __LINE__ << " : Failed to accept client connection." << endl;
		}
		else
		{
			strcpy(g_szConnectedClientName, inet_ntoa(adrInterfaceClient.sin_addr));
			cout << "Client connected: " << g_szConnectedClientName << endl;
 
			InterfaceClientSignalHandler(sktClient);
		}
	}
 
	// Do whatever else here... render objects, process input, etc.
}
 

The next article -- part 4 -- will detail the NintendoDS implementation using the dswifi library, and I'll probably write a 5th article just to wrap it all up.

About six months ago I got a MacBook Pro, so I spent a long while just updating my applications to run on OSX, and also exploring Core Foundation. I've made some neat stuff that I'll share with you guys, as soon as I get out this NDS WiFi programming project that I've been promising for nearly a year. =P

Around the same time I got my new Mac, I also found Dragon Age: Origins. Installing this game created a time anomaly centered around my computer. I played enough DA:O that the heat generated by my video card has likely contributed greatly to global warming, and melted a few iceburgs. The deaths of many penguins was worth the glory of turning back a blight.

After DA:O (like 6 characters and playthroughs later), I got wrapped up in the whole Bioware strategic RPG thing. I played through the entire Baldur's Gate series with all expansions, then the Neverwinter Nights series with all expansions, and I just finished Mass Effect. SOO... needless to say, I've been distracted.

I haven't forgotten about you however, and I will soon piece together the final bits of the NDS WiFi project, and make a post to bring it all together, I promise. =)

My platform independent rendering engine is based on a pure virtual renderer base class that is filled with an instance of a derived class by a dynamically linked code module. Along with the pure virtual renderer class, there are a few pure virtual resource classes as well, the actual instantiation of which are performed by the renderer class. Trying to maintain platform independence, the singleton (factory / manager) class that returns this renderer instance has some interesting code I thought I would share.

It is possible to have a project directory (even though a bit messy) that will compile in both Microsoft Visual Studio and in GCC without having to change a lick of code. Thats child's play for a simple project, but its still possible even for a project that contains a main executable and several other dynamic libraries.

So first off, since we are dynamically linking, we are definitely going to have function pointers returned by dlsym(...) or GetProcAddress(...). The actual DLL/SO modules export only three functions--one to create the instance, one to destroy it, and one to return the version. So we have the typedefs for these as so:

 
typedef int (*fpCreateRendererInterface)(CRenderer **pInterface);
typedef int (*fpDestroyRendererInterface)(CRenderer **pInterface);
typedef int (*fpQueryRendererVersion)(void);
 

Second off, this is platform independent, so obviously we will need to be using some fancy pre-processor conditionals (PPCs) to detect the platform / compiler. Now in certain instances we only want to know what the compiler is, because the actual platform doesn't matter, but in other cases we want to know the actual platform as well because the same compiler is used on multiple platforms (GCC is used in Linux and also Mac). First for the compiler, we can detect Visual C++ by checking to see if _MSC_VER is defined, and we can detect GCC by checking to see if __GNUC__ is defined. For the platform, we can detect Windows by checking if WIN32 is defined (yes, even 64-bit Windows defines this), we can detect Linux by checking if __linux__ is defined, and we can detect OSX by checking if __MACH__ and __APPLE__ are defined.

We can then use these PPCs to create code that is savagely flexible. In this singleton class, I have a static void pointer to the library (Windows' HMODULE is just a void*, don't let them trick you) called m_hLibrary. Lets see how we could dynamically link either a .so file in Linux or a .dll file in Windows and place the returned handle in the same variable... here is the code for the "SGL" (SDL GL) renderer type which can be used in either Linux or Windows, taking into account if the code is in release or debug mode:

 
case rstSGL:
	Log::Entry(-1,__FILE__,__LINE__,"Creating SGL rendering interface...");
#if defined(__GNUC__)
 
#if defined(NDEBUG)
	Log::Entry(-1,__FILE__,__LINE__,"__GNUC__ defined... opening release library");
	m_hLibrary = dlopen("./libRendererSGL.so",RTLD_NOW);
#else
	Log::Entry(-1,__FILE__,__LINE__,"__GNUC__ defined... opening debug library");
	m_hLibrary = dlopen("../RendererSGL/bin/Debug/libRendererSGL.so",RTLD_NOW);
#endif
	if(!m_hLibrary)
		Log::Entry(2,__FILE__,__LINE__,"Error loading shared library. dlerror() = %s",dlerror());
#elif defined(_MSC_VER)
#if defined(NDEBUG)
	m_hLibrary = LoadLibraryExA("RendererSGL.dll",NULL,NULL);
#else
	m_hLibrary = LoadLibraryExA("../RendererSGL/bin/Debug/RendererSGL.dll",NULL,NULL);
#endif
#endif
	break;
 

Please note that NDEBUG is not defined by GCC even when using -O2, so you need to set your release target to define this manually (-D NDEBUG). I find it strange because it is supposedly a standard...

Also note that when linking using dlopen(...), we specify RTLD_NOW to force resolution of all symbols in the dynamic library. If we used RTLD_LAZY, we could exclude a lot of code from our library, and let it resolve symbols later (i.e. from the main executable). Unfortunately this works great on Linux but seemingly has no analogy in Windows, and in order to keep the projects symmetrical across platforms, we use RTLD_NOW to behave appropriately.

So lets look at whats going on here... its a bit over complicated, but I thought I would provide some extra good ideas for you guys. If using GCC, we use dlopen(...) to get the handle to the .so file, and if using VC++, we use LoadLibraryExA(...) to get the handle to the .dll file. If NDEBUG is defined, we link to the release version of the dynamic library (actually look in the current directory or system path as if it were a proper deployment), otherwise we link to the debug version of the library to simplify development.

Oh snap! So we now have linked to a dynamic library regardless of what platform we are running on! This is kickass, so where to now? We need to get pointers to the functions in the library we are going to use. The function that does this in Linux is dlsym(...), and in windows is GetProcAddress(...). Here is what this would look like in a platform independent form:

 
#if defined(__GNUC__)
	fpCreateRendererInterface IntCreate=(fpCreateRendererInterface)dlsym(m_hLibrary,"CreateInterface");
#elif defined(_MSC_VER)
	fpCreateRendererInterface IntCreate=(fpCreateRendererInterface)GetProcAddress((HMODULE)m_hLibrary,"CreateInterface");
#endif
 

Damn, its that easy? Indeed it is. We now have a function pointer to a procedure in a dynamically linked library regardless of if it came from a .so file in Linux or a .dll file in Windows. Obviously once armed with the function pointer, the remaining code is the same regardless of platform. We just use IntCreate(...) like it were a normal function. In this case we pass a pointer to a pointer to the pure virtual renderer base class, and inside the dynamic library, we assign the pointer to an instance of a derived class:

 
extern "C"
{
	int CreateInterface(CRenderer **pInterface)
	{
		if(*pInterface)
			return -1;
 
		*pInterface = new CRendererSGL();
 
		return 0;
	}
...
 

This is really quite powerful, and since the only actual call to an exported function is when creating the derived class instance, the performance hit while using the derived class is only from the vftable. More importantly this lets us do something ultra simple in our main code to get a reference to an abstract renderer interface that doesn't require knowledge of the nitty-gritty of either D3D or OpenGL:

 
	Log::Entry(0,__FILE__,__LINE__,"Creating rendering device...");
	Graphics::CreateInterface();
	CRenderer *renderer = Graphics::GetInterface();
	renderer->Initialize(0);
 
	if(g_bSafeDevice)
		renderer->CreateDeviceSafe();
	else
		renderer->CreateDevice(800, 600, 32, g_bWindowed);
 

Yeah, I know. That code is delicious. Its even more tasty when you have a CMesh that contains instances of pure virtual CResourceVtxBuff and CResourceIdxBuff created by the derived CRenderer class in the dynamic library, and CModel that contains a number of CMesh instances as well as a number of CMaterial instances that contain instances of pure virtual CResourceTexture also created by the derived CRenderer class in the dynamic library. So to create a model and render it, you would have to do something like the following:

 
	// example of loading a mesh
	mshOut = new CMesh();
	iStride=mshOut->GetVtxStride();
	mshOut->SetVtxCount(iVertexCount);
	mshOut->SetFaceCount(iFaceCount);
 
	m_pRenderer->CreateMeshBuffers(iStride*iVertexCount,sizeof(int)*3*iFaceCount,mshOut);
 
	// if pRenderer is D3D, this lock would be like IDirect3DVertexBuffer9->Lock(...),
	//while in OpenGL it would be like glMapBufferARB(...). Transparent at this point.
	VtxData=(unsigned char*)mshOut->GetVtxPtr()->LockWrite(0,0);
 
	// Write vertex buffer to VtxData here...
 
	mshOut->GetVtxPtr()->Unlock();
 
	IdxData=(unsigned char*)mshOut->GetIdxPtr()->LockWrite(0,0);
 
	// write index buffer to IdxData here..
 
	mshOut->GetIdxPtr()->Unlock();
 
	// example of loading a material
	mtlOut=new CMaterial();
	mtlOut->SetDiffuse(FloatToLongColor(v3fDiffuse.x, v3fDiffuse.y, v3fDiffuse.z));
	mtlOut->SetAmbient(FloatToLongColor(v3fAmbient.x, v3fAmbient.y, v3fAmbient.z));
	mtlOut->SetSpecular(FloatToLongColor(v3fSpecular.x, v3fSpecular.y, v3fSpecular.z));
	mtlOut->SetMaterialName(sMaterialName);
 
	mtlOut->SetTexture(m_pRenderer->CreateTexture(&imgTexture));
 
	// and you add them to a model which contains std::vectors of meshes and materials...
 
	iMaterialIdxList[j] = mdlOut->AddMaterial(mtlOut);
 
	//...
 
	mdlOut->AddMesh(mshOut,iMaterialIdxList[iMaterialRef]);
 
	// and eventually render!
 
	iMeshCount = mdlCurr->GetMeshCount();
 
	for(j=0;j<iMeshCount;j++)
	{
		pRenderer->SetWorld(&matWorld);
 
		k = mdlCurr->GetMeshMaterialIdx(j);
 
		pRenderer->SetTexture(mdlCurr->GetMaterial(k)->GetTexture());
		pRenderer->Render(mdlCurr->GetMesh(j));
	}
 

Anyway, I guess this isn't all that useful, and maybe I'm just showing off at this point. It does exhibit some good ideas, and show how glorious abstraction can be though. Regardless, I got distracted again. The NDS Wifi example continues. I will post in the next few days to describe the protocol used and give a little primer on sockets. Keep your eyes peeled.

We want to rotate the cube along an axis perpendicular to the mouse motion vector. This will give the impression that the cube is spinning as a direct result of the motion, as if you had quickly ran your hand along it. So we first need to construct a vector that is perpendicular to the motion, and lies in the plane of the screen. Lets assume we have a default OpenGL view setup, where we are looking along the negative z-axis, and the screen lies in the xy-plane. Thus, we want a vector that is perpendicular to the mouse motion and lies in the xy-plane.

Anyone with some math background may immediately recognize the cross-product as a candidate to construct the perpendicular vector. Indeed, if we create a vector from the relative mouse motion (conveniently in our environment the mouse motion is on the xy-plane, so the screen coordinates align nicely), then take the cross-product of this vector with the z-axis, the result is a vector that is perpendicular to the mouse motion and lies in the xy-plane.

 
 
//iRelX and iRelY is the relative mouse motion
 
float fTheta;
float vCross[3];
float fCrossMag;
 
// Assign theta to the magnitude of the mouse motion vector
// This is rather arbitrary
fTheta = (iRelX*iRelX + iRelY*iRelY)/16.0;
 
/*
vCrossX = v1y*v2z - v1z*v2y
vCrossY = v1z*v2x - v1x*v2z
vCrossZ = v1x*v2y - v1y*v2x
*/
 
// Perform cross-product.
// Here v1 is the mouse motion vector and v2 is the z-axis.
// This gives us a vector that is perpendicular to
//the mouse motion and lies in the xy-plane.
vCross[0] = iRelY*1.0 - 0.0*0.0;
vCross[1] = 0.0*0.0 - -iRelX*1.0;
vCross[2] = -iRelX*0.0 - iRelY*0.0;
 
// Normalize this vector for use as axis in rotation matrix
fCrossMag = sqrt(vCross[0]*vCross[0] + vCross[1]*vCross[1] + vCross[2]*vCross[2]);
vCross[0] = vCross[0] / fCrossMag;
vCross[1] = vCross[1] / fCrossMag;
vCross[2] = vCross[2] / fCrossMag;
 

Great. So now we can just take this vector and use it when calling glRotatef(...) in order to transform the modelview matrix, right? Well, not quite. We CAN do this, but if you've played around with glRotatef(...) to manipulate objects in your scene via the modelview matrix, you may have noticed that when you rotate an object on one axis, it actually transforms the other two axes. This basically means that using glRotatef(...) or any other matrix transform in this manner is actually operating in the model's local coordinate system. If we tried to rotate our cube around our constructed axis using glRotatef(...), it would work as expected initially but then subsequent rotations would rotate around the already transformed axis. We don't want this, we want to operate on a fixed coordinate system, what is often referred to as the world coordinate system.

This issue arises because matrix operations post-multiply on the matrix stack in OpenGL. If we could pre-multiply the operations, we would be good, but unfortunately there is no way to tell OpenGL to pre-multiply instead, so we really have to do this operation manually. In order to accomplish this, we need to maintain our own modelview matrix accumulation, and each frame multiply our rotation matrix by this accumulation matrix to get the new modelview transform. Note that if we used glRotatef(...), it would multiply the accumulation matrix by the rotation matrix. Matrix multiplication isn't commutative, and in our situation it makes all the difference in the world.

So we need to get our hands dirty with a little linear algebra. First we need to define a few 4x4 matrices that we can hand to OpenGL:

 
// OpenGL likes this format for a 4x4 matrix
//as declared in the Redbook
float matWorld[16];
float matWorldAccum[16];
float matBuff[16];
 

Also define a function that can construct a rotation matrix when rotating around an arbitrary axis:

 
// Theta is in radians
void MatrixRotation(float *matRot, float fTheta, float fAxisX, float fAxisY, float fAxisZ)
{
	float fCosTheta, fSinTheta;
 
	// m0   m4   m8   m12
	// m1   m5   m9   m13
	// m2   m6   m10  m14
	// m3   m7   m11  m15
	fCosTheta = cos(fTheta);
	fSinTheta = sin(fTheta);
	matRot[0] = fAxisX*fAxisX+(1.0-fAxisX*fAxisX)*fCosTheta;
	matRot[4] = fAxisX*fAxisY*(1.0-fCosTheta)-fAxisZ*fSinTheta;
	matRot[8] = fAxisX*fAxisZ*(1.0-fCosTheta)+fAxisY*fSinTheta;
	matRot[12] = 0.0; // m12,m13,m14 can be used for translation
	matRot[1] = fAxisX*fAxisY*(1.0-fCosTheta)+fAxisZ*fSinTheta;
	matRot[5] = fAxisY*fAxisY+(1.0-fAxisY*fAxisY)*fCosTheta;
	matRot[9] = fAxisY*fAxisZ*(1.0-fCosTheta)-fAxisX*fSinTheta;
	matRot[13] = 0.0;
	matRot[2] = fAxisX*fAxisZ*(1.0-fCosTheta)-fAxisY*fSinTheta;
	matRot[6] = fAxisY*fAxisZ*(1.0-fCosTheta)+fAxisX*fSinTheta;
	matRot[10] = fAxisZ*fAxisZ+(1.0-fAxisZ*fAxisZ)*fCosTheta;
	matRot[14] = 0.0;
	matRot[3] = 0.0;
	matRot[7] = 0.0;
	matRot[11] = 0.0;
	matRot[15] = 1.0;
 
}
 

Now we need to be able to multiply our rotation matrix by the accumulated modelview transformation matrix:

 
void MatrixMultiply(float *matDest, const float *matA, const float *matB)
{
	// m0   m4   m8   m12
	// m1   m5   m9   m13
	// m2   m6   m10  m14
	// m3   m7   m11  m15
 
	// Inner product of each row with each column
	matDest[0]=matA[0]*matB[0] + matA[4]*matB[1] + matA[8]*matB[2] + matA[12]*matB[3];
	matDest[4]=matA[0]*matB[4] + matA[4]*matB[5] + matA[8]*matB[6] + matA[12]*matB[7];
	matDest[8]=matA[0]*matB[8] + matA[4]*matB[9] + matA[8]*matB[10] + matA[12]*matB[11];
	matDest[12]=matA[0]*matB[12] + matA[4]*matB[13] + matA[8]*matB[14] + matA[12]*matB[15];
 
	matDest[1]=matA[1]*matB[0] + matA[5]*matB[1] + matA[9]*matB[2] + matA[13]*matB[3];
	matDest[5]=matA[1]*matB[4] + matA[5]*matB[5] + matA[9]*matB[6] + matA[13]*matB[7];
	matDest[9]=matA[1]*matB[8] + matA[5]*matB[9] + matA[9]*matB[10] + matA[13]*matB[11];
	matDest[13]=matA[1]*matB[12] + matA[5]*matB[13] + matA[9]*matB[14] + matA[13]*matB[15];
 
	matDest[2]=matA[2]*matB[0] + matA[6]*matB[1] + matA[10]*matB[2] + matA[14]*matB[3];
	matDest[6]=matA[2]*matB[4] + matA[6]*matB[5] + matA[10]*matB[6] + matA[14]*matB[7];
	matDest[10]=matA[2]*matB[8] + matA[6]*matB[9] + matA[10]*matB[10] + matA[14]*matB[11];
	matDest[14]=matA[2]*matB[12] + matA[6]*matB[13] + matA[10]*matB[14] + matA[14]*matB[15];
 
	matDest[3]=matA[3]*matB[0] + matA[7]*matB[1] + matA[11]*matB[2] + matA[15]*matB[3];
	matDest[7]=matA[3]*matB[4] + matA[7]*matB[5] + matA[11]*matB[6] + matA[15]*matB[7];
	matDest[11]=matA[3]*matB[8] + matA[7]*matB[9] + matA[11]*matB[10] + matA[15]*matB[11];
	matDest[15]=matA[3]*matB[12] + matA[7]*matB[13] + matA[11]*matB[14] + matA[15]*matB[15];
 
}
 

Great, so we are now equipped to construct and maintain our own modelview matrix! This means we no longer have to ask OpenGL for transformations. We can do them ourselves, and just hand the transformation matrix to OpenGL for rendering the current scene.

 
// Now we contruct a matrix to rotate around this axis
MatrixRotation(matWorld, fTheta*PI/180.0, vCross[0], vCross[1], vCross[2]);
 
// Notice this is matWorld * matWorldAccum, instead of
//matWorldAccum * matWorld, as it would be if we just used
//glMultMatrix with the constructed matWorld rotation matrix
MatrixMultiply(matBuff, matWorld, matWorldAccum);
 
// Assign the world matrix accumulation to the modelview matrix
glMatrixMode(GL_MODELVIEW);
glLoadMatrixf(matBuff);
 
// Update accumulated matrix
for(i=0; i<16; i++)
	matWorldAccum[i] = matBuff[i];
 

Fun stuff, eh? I always feel empowered by doing more things in my client code instead of processing data in a black box. Next part of the article we will get into the NDS and socket programming. I know you are holding your breath. =)

Part of this old game engine was a resource management class that could load 3D Studio MAX ASCII exported scenes/objects. These files are .ASE files, which is a versatile and simple format that has a surprisingly wide usage by various game engines. ASE files can be used when building Doom3 and Quake3 / Quake4 levels, since the format boasts native support in ID and Loki software's GtkRadiant design tool, so it is a generally accepted format for storing game content. The ASE format specification itself is quite versatile, and can contain material specifications, verticies, faces (vertex indexes), vertex colors, texture coordinates, and even animations with full interpolation parameters just to name a few. Being ASCII, it is rather easy to parse and modify.

In the ASE format, each line of the file serves a single purpose. It is either an opening or closing tag for a field, or an element in a field. It made sense then when I first wrote the import code to parse the file on a line-by-line basis using ifstream::getline(...). This worked great in Windows, and I had no issues with my implementation. Flash forward to now when I am rewriting this code to work in Linux, but using files created in Windows. I never thought the disparities of a 'newline' between platforms would ever cause such a problem.

The ifstream::getline function was specifically designed to get a single line from a file without including the newline or delimiting character(s). The newline character ('\n') is the delimiting character by default, as it serves its purpose most of the time. ifstream::getline(...) reads in all characters up to the delimiter, then extracts and discards the delimiter. The problem arises when considering the definition of a newline on different platforms.

In Windows, the newline for iostream operations is a carriage-return,line-feed combo. It is actually two characters with ASCII decimal values 13, 10 (0x0D, 0xOA in hex), often referred to as a CRLF combo. In Linux, a newline is simply a line-feed (dec 10, hex 0x0A). So when performing ifstream::getline(...) in Linux, what you are doing is reading a line up to the delimiter--newline by default--and if your file was created in Windows only the last half of the CRLF combo is discarded, while the first half is read in as the last character in your string variable. This makes any literal comparisons made against this string variable fail in Linux while working fine in Windows.

I thought for sure there was some elegant way to overcome this and attain platform independent file parsing without forcing a complete rewrite of the import code. This turned out to not be the case. The ifstream::getline function is handy, but by doing you the favor of automatically extracting and discarding the delimiter, it somewhat cripples it's versatility. My impetus was two fold. Obviously first I wanted to be able to read these ASE files with 0x0D,0x0A line delimiters into Linux without having the 0x0D on the end of my read lines. This would be simple enough, but I wanted also code that would work regardless of platform combinations. This meant reading Windows files in Linux, Linux files in Windows, Windows files in Windows and Linux files in Linux.

So this added a bit of complexity to the requirements. First off, it would be impossible to use ifstream::getline(...) because it would extract and discard different characters from the file stream depending on platform. When reading a Linux file in Windows, it would keep reading from the stream, looking for a CRLF combo, and would likely read the entire file without finding one. When reading a Windows file in Linux as I found out, it would read the line including 0x0D, then stop at and discard the 0x0A. If it didn't consider reading Linux files in Windows, the following implementation was elegant, and worked in all other situations:

 
char szLineBuff[256];
ifstream fsIn("test.ase", ios::in);
 
// Note that failbit would be set if this
//failed to extract any chracters before
//the delimiter, and the loop would end.
while(fsIn.get(szLineBuff, 128, '\n').good())
{
	// This extracts 2 characters in
	//windows, just 1 in Linux.
	fsIn.ignore(2,'\x0A');
	// Cleans Windows line in Linux
	if(szLineBuff[strlen(szLineBuff)-1] == '\x0D')
		szLineBuff[strlen(szLineBuff)-1] = '\0';
 
	// Process szLineBuff...
 
}
 

Now I recognize that opening the file in binary mode (ios::binary) would make the '\n' be interpreted as simply '\x0A' on both Windows and Linux. My problem with this is that the file isn't binary. I'm stubborn and think this ASCII text file should be read in text mode, and that there should be a simple way to interpret newlines from any platform on any other platform. There must be a simple and elegant solution out there somewhere...

I'll be honest and say I stopped there, as my code worked for 3/4 of the scenarios I laid out. I have yet to find a Linux native source of ASE files, so the last scenario (Linux files on Windows) hasn't become important for me yet. If anyone has a better solution for this, or knows one that would work in all scenarios while still being somewhat elegant, I'd love to hear about it.

Also, I know I promised a follow-up on the NDS WiFi programming. I only got a little distracted, the example applications are nearly finished. You'll definitely like it when it comes.

So I did a bunch of NDS programming a few years back using the devkitPro toolchain, specifically devkitARM. They were at release r20 then, and dswifi had just made it on the scene. For those who don't know, dswifi is a library written by Stephen Stair that allows NintendoDS homebrew developers using devkitARM to use the wifi features of the NDS. You can connect to wireless access points, and from there you have network access and a standard Berkley sockets interface, so you can pretty much accomplish anything you set your mind to. I just downloaded the latest version of devkitARM, which is now r26. I was quite pleased with the progress the toolchain had made during my absence, and especially pleased to see dswifi so well integrated. Things pretty much went downhill from there.

NOTE: 09.06.16 - The rest of this post is for historical information only. After I isolated the bug in dswifi that was the root of my problems, I notified the maintainers of devkitPro who committed a fix. There are now new releases of libnds, dswifi and default arm 7 available that correctly handle the DS' MAC address. Please see the addendum at the end of this article for more information. Do not downgrade your devkitPro install if you are having problems. Instead get the very latest versions of all libraries, and you should be good.

There were no examples provided with the nds-examples package that showed how to connect to WEP secured Access Point (AP). The only examples provided were for either using the WFC information stored in the NDS firmware, or for connecting to an unsecured AP. They did have code to enumerate APs and to provide a keyboard interface that I happily integrated. Prior to even testing the included examples I poured a couple hours into writing a code base using the most involved methods possible (swapping out all the simple 0 argument init functions with the 8 argument equivalents) to establish a console and collect and display a list of APs. Selecting an AP from this list that was secured would then provide a prompt to specify either 40-bit or 104-bit encryption. The user could then type in the 10 or 26 character string using a tiny little keyboard on the DS touchscreen. This string was then encoded to a byte array and passed to the Wifi_ConnectAP(...) function provided by dswifi.

Wifi AP list and a tiny keyboard

I then spent three times as long troubleshooting. It took a while for me to remember that I have MAC address filtering enabled on my router (*bonk self*). I loaded up a wifi enabled game, pulled the MAC address of my DS from Nintendo's WFC interface, and put it on my router's Access Control List. I rubbed my hands in greedy anticipation, and loaded up my homebrew app once again. No joy ensued. I still could not connect to my AP.

At this point, I decided to try something simple just to verify the functionality of dswifi (yes, I'm backasswards when it comes to programming), so I loaded up one of the basic dswifi examples. Strangely, it did not work either. I knew it wasn't my DS or router anymore, because I would connect with a proper DS game that was wifi enabled. I didn't see anyone else complaining in the devkitPro forums, but r26 was *just* released and the forums over there aren't exactly teeming with DS programmers. I thought maybe the devkitPro toolchain for x64 Linux might have been the culprit, so I tried in Windows XP as well. Still no joy.

Operating under the assumption that dswifi worked at SOME point in devkitPro, I decided it was time to start digging backwards through the releases, and testing the functionality as I went with the most simple example possible... one that loaded the AP information from the WFC info stored in the DS and automatically tried to connect. This simple example did indeed work back in devkitPro r25 (2009.02.20). I then increased my resolution to try and find *exactly* where dswifi broke in devkitPro.

<SNIP>
Several paragraphs removed at the request of the devkitPro maintainers.
This section basically highlighted my procedures to somewhat subvert the available devkitPro library distributions to create a tool chain that pre-dated issues with the DS MAC address handling. As noted above, the bug I isolated has been fixed in the latest devkitPro library distributions, so this information is no longer pertinent. I found out that in my setup, the simple WFC autoconnect example worked fine when built with dswifi 0.3.7, but refused to work in dswifi 0.3.8. So I configured a motley devkitPro toolchain with different versions of specific libraries in order to get dswifi working for me.
</SNIP>

Telnetting into my NintendoDS Echo Server.

I now have code running on my DS that allows me to connect to my WEP secured AP, and from there get a socket connection to my workstation. Its pretty blasted awesome to be able to telnet into your DS and see what you type into your computer appear on the screen. Its several magnitudes more awesome to use the DS touchscreen and keys to remotely manipulate a 3D chaotic system in realtime. Add the ability to pipe recorded audio data from the DS microphone over the network and into that system where the fourier-tranformed signal is then used to modulate said system, and you might as well be dividing by zero.

UPDATE 2009.06.07:

After butting heads with the maintainers of devkitPro on the forum (they deleted a few of my posts because they don't like people telling users to downgrade or linking to obsolete libraries -- support headaches) who said the examples worked fine in r26, I pulled the source code for dswifi 0.3.7 and 0.3.8 than ran diff against the versions, excluding the svn nonsense:

diff -urNp -x '*svn*'  dswifi-src-0.3.7 dswifi-src-0.3.8 > dswifi.patch

Thanks to diff and a little persistence reading through the patch file, I found exactly where my problem was originating.

Remember how I said I had MAC address filtering enabled on my router? Well recent changes to dswifi did indeed break the example, for me at least... the MAC address bytes were being read from the firmware but written to a main data structure incorrectly:

 
for(i=0;i<3;i++)
	WifiData->MacAddr[i]= ReadFlashByte(0x36+i) + (ReadFlashByte(0x36+i+1)<<8);
 

This loop doesn't write the data to MacAddr as intended. After the loop, MacAddr is filled with the bytes from the following firmware addresses : 0x36, 0x37, 0x37, 0x38, 0x38, 0x39. The intention is obviously to write the bytes from 0x36, 0x37, 0x38, 0x39, 0x40, 0x41. Simple mistake, simple solution. I notified the maintainers, so when you download devkitPro r27, you can thank me when connecting to APs with MAC address filtering. =)

ADDENDUM 2009.06.16:

A fix for the MAC address bug in dswifi was submitted to the devkitPro svn on June 11th. The maintainers built new distributions of three libraries the same day. So if you get the following versions of libnds, dswifi and default arm7, your DS' MAC will be properly presented to access points:

libnds 1.3.5
dswifi 0.3.9
default arm7 0.5.4

Way to go, devkitPro.

You can see the full discourse on the forums here.

With this issue now past tense, I'll work on posting a PART 2 of this article with some actually useful programming information.

I used to be a Microsoft fan boy. I loved DirectX, and spent nearly every waking hour using it while crafting a game engine. I can remember working with Direct3D 6 and tearing my hair out trying to decide between immediate and retained mode. What an ugly API it was too, but I still used it over OpenGL because I had the feeling it was more powerful. DirectX 8 came out and all of a sudden everything was sleek and seemed to fit into place so well, and boy, was I ever excited over DirectX 9.

Tux Plotting

So what happened? At what point did I decide that Microsoft was evil and didn't deserve my time? The feeling culminated slowly. Microsoft pulled one stunt after another, betraying the trust consumers had placed in them. They were constantly using their market share and financial prowess to inhibit innovation and force the consumer's hand to benefit only themselves. It soon became apparent to me that they knew almost no bounds. They would commit horrible atrocities and get away with it because they are Microsoft.

I had been following the development of Bungee's Halo eagerly for some time. This was going to best PC game ever. One day, the Halo website just disappeared. Nobody knew what happened. Microsoft had recently announced they were entering the console market. It soon became obvious what was going on. Halo was to be a launch title for Microsoft's Xbox. They had acquired Bungee. I held my breath and patiently waited for the PC release of Halo. Bungee wouldn't turn it's back on the PC market, would they?

When it finally came, the PC port of Halo was substandard. I played the demo and never got the full version, maybe because Blood Gulch was enough for me, or maybe it was the flaws I saw. The networking code was seemingly never designed to operate with the high latencies found on the WAN. It was possible to accomplish... Unreal Tournament's cubic interpolation allowed the server to accurately render players and detect hits based on their projected locations. When playing the PC port of Halo, I found myself having to perform this interpolation myself, aiming ahead of players a certain distance based on the amount of latency I had with the server. Don't get me wrong, I got damn good at this and could still drop mofos from the far side of Blood Gulch with a pistol while both at full tilt, but I still felt betrayed and forgotten by Bungee with their new guiding hand. And man, oh man, when Halo 2 was released on the PC under Microsoft's new "Games for Windows" (AKA: Games that _only_ run on MS's craptacular new Vista OS) platform, there aren't words to describe how furious I was. Bungee's output was again used to push Microsoft's own agenda, this time trying to wrangle people into buying the new Vista OS, which was almost universally hated. Halo and Bungee aside, there are plenty of other reasons to despise Microsoft...

I had always been a tables layout HTML kind of guy. Who wasn't? When CSS starting making its way into the mainstream and new standards for positioning web page elements were devised, I resisted change for quite some time. Tables were so handy. I didn't need these new fancy DIVs and all this new positioning mojumbo. I could do all that with nested tables using colspan, rowspan, and the ever-useful CENTER tag. Needless to say, the CSS revolution didn't move me. I was still happily making webpages without a single style attribute. I tell you this just so you know I'm not a standards whore who expounds upon and proudly touts every little tidbit thrown out by the W3C.

One day while meandering about on the interwebs and mourning the fact VRML never caught on, I stumbled across a new standard that made me salivate. Scalable Vector Graphics had become a web standard. The W3 Consortium said so! This was blasted glorious! It was only a matter of time before webpages based on SVG would become standard, and we could present content on interactive SMIL animated geometry! SVG had presented epic new parameters to the web.

I quickly downloaded Opera with it's high level of SVG and SMIL compliance, and set to work creating an exemplary SVG based webpage. Previous experience with geometry and transformation pipelines from game engine design lent itself well here. I learned all sorts of new things with Javascript, stuff I had never before even thought of doing. I was dynamically modifying SVG transform attributes, adding and removing JS event handlers, and generally having a ball. I made a tasty little SVG "module" that would allow you to specify an array of images and it would create a task bar much akin to the Mac OS X dock. As your mouse cursor approached one of the "tasks" the image associated with it would grow larger( transform="scale(4.3*glory, 5.2*splendor)" ), nudging it's neighboring task icons to either side. You could even grab the dock itself and drag it to some other location on the screen without changing it's functionality. Obviously the possibilities for content interaction and presentation were limitless. Web design had never been so fun or rewarding.

So after the initial reveling was over, it was time to realize the benefits of the SVG standard, and deploy some content. Internet Explorer 7 was about to be released, I thought for sure it would come with some support for SVG, considering Firefox was already providing some support, and Opera was rocking near full compliance. Well, IE 7 came out without a lick of SVG support. Surely they would wise up, get with the program and provide support in a service pack? Wrong. Hell, IE 8 *just* came out and Microsoft is still pretending like SVG doesn't exist. Not even a hint of support for SVG. Why you ask? Why would Microsoft totally ignore such a great standard that offers so much promise for the web? Two words. Silver. Light. Yes, Silverlight and XAML. Microsoft basically rips off the SVG standard to define XAML, then turns it's back and pretends like SVG doesn't exist, again in order to promote it's own agenda. For some reason as I write this, I am reminded of Death of a Salesman: "You cannot eat the orange and throw the peel away. A web standard is not a piece of fruit!". Microsoft ate the fruit of W3C's labors, threw the rind away, and walked off.

This transgression by Microsoft is magnitudes more serious than the Bungee / Halo fiasco. This makes that seem completely insignificant. This is Microsoft using it's market share to try and KILL a standard. With the majority of end users using Microsoft's browser, they can pretend that SVG doesn't exist, and thus make the majority of the world not realize it exists. No one will push forward with SVG, because the world's most popular browser... Microsoft Internet Explorer stubbornly refuses to support it. The world is being denied an open web standard that can provide interactive and dynamic content on level with Adobe's Flash, but is natively supported in browsers. Can you imagine the community driven image gallery projects like Gallery, CopperMine and 4Images but based on SVG that would exist if Microsoft had supported SVG six years ago when they should have? I don't think you can. Hell, I'll make a prototype just to hint at what you are missing (as long as you aren't using IE).

At first it was denial... I continued to search the web for news that Microsoft wasn't being that obstinate, and actually had plans to support SVG in IE at some point. I hunted through the forums waiting for some Microsoft engineer to say in a forum somewhere that yes, of course SVG support was on the IE development roadmap. Time dragged on, and eventually I couldn't deny the facts anymore... Microsoft was doing this... HOW COULD THEY?!? AAARRGGHHH!!! The anger was the worst because I had little outlet for it. My friends didn't seem to understand the fury that drove my diatribes about how evil Microsoft was. I hoped that maybe... maybe if they didn't feel threatened by SVG they would relent and offer support for it. I cried a little. Tears fell from my ocular devices, shed for all the potential glory of SVG that would never be realized. I became sullen and discarded web development for years. My webpage lied in repose. It was during this time of depression that I rediscovered Linux.

Frankenstein Milkcrate Machine

I had used Linux before, but never considered it's real potential. I always used it when telnetting to shells, and back in 1996 I built a Frankenstein computer assembled from the corpses of other machines. I installed RedHat Linux (v2 I think) and used it to make a CGI application for the ISP I worked for. It was pretty neat, and I liked the feeling of being totally lost in a new operating system, but at that time I still had much to learn about windows, and only considered Linux as a second-rate OS. Back on the real timeline, I got myself a copy of Gentoo and again installed it in a Frankenstein computer, this time one that was assembled in a milk crate (real classy, eh?). For some reason this time around, my feelings for Linux were much different.

This change in feeling can be likely attributed to two things. One, I felt I had pretty much learned everything that wasn't hyper esoteric about Windows. I knew XP inside and out, I knew Windows server, all about Active Directory, Group Policy Objects, terminal services, etc. I had also used a crap ton of C/C++ Microsoft APIs most people had never heard of like the TS API and the GP API. Two, I had started to hate Microsoft and finding out that from within Linux I could emulate the fast majority of Windows applications uisng WINE and even emulate DOS using DOSBox gave me a great feeling of control and satisfaction. Furthermore, Linux was aimed at people like me.

People who wanted the freedom to customize EVERYTHING if they wanted. People who wanted the source code for all the applications they use just in case they wanted to modify how they operated slightly. People who wanted to work using formats that were standardized and open. People who didn't like being told how to use their computers. People who saw new computer technology and standards not as either a threat or a chance to capitalize, but as a road to innovation where they could potentially improve the quality of digital life for computer users. It is these people who embrace Linux and opensource, and feel oppressed when working with Microsoft Windows.

After this recent excursion into Linux, I approached the operating system as a replacement for Windows, not just a diversion from. This meant I needed to be able to do everything I typically did within Windows without inconvenience. After years of using nothing but Gentoo, Debian and of course Ubuntu, I can honestly say that I have found absolutely nothing I cannot accomplish in Linux with similar or improved efficiency, except perhaps playing TES: Oblivion.

I can take the lack of support for new PC games. Oblivion was a time vortex anyway... I stopped playing it on Windows before I really got into it. I knew otherwise I would sink countless hours into the void. It seemed a game that you could continue playing forever. My father actually proved this wrong though... he played Oblivion into the ground. He only stopped after he got 100% chameleon so nobody could see or hurt him. At that point he resorted to just hanging out on the front porch of his house in Anvil watching the people go by. Apparently this lost its appeal pretty soon.

Back to the point though, I try not to spend too much time playing games anymore. I started playing text MUDs back in like 1996. I hardly ever left the house anymore. My friends were pissed because I wouldn't join in the D&D campaigns we constantly ran. My parents were pissed because the phone line was CONSTANTLY in use and nobody could call without getting a busy signal. I was only pissed when Creeping Death, Age of Legends or Carrion Fields went down. Diku/Merc/ROM was the stuff dreams were made of. I would often have dreams about being on the text mud. My dreams actually consisted of text on a screen. It was absurd.

When the first graphical MUDs started appearing, I was ALL over that. I was playing the first real graphical MUD, Meridian59 back when it was only the town of Tos. A single large room. I beta tested and played the hell out of pretty much every significant (and some insignificant) MMORPG that came out. Beta tested for Meridian59, Ultima Online, Asheron's Call, Star Wars Galaxies, and finally Ever Quest. For some reason after Ever Quest, I abandoned MMORPGs. I haven't touched one since the EQ beta. I just decided to not sink my time into games like I used to. MMORPGs were becoming the ultimate distraction... to the point of absurdity. People were living richer lives in virtual worlds than they granted themselves IRL. I digress. Perhaps I'll pontificate about it at a later time.

For all my haughty talk, I still like a good distraction once in a while just as much as the next guy. Fortunately there are a scad of options for digital entertainment in Linux. Many of the best games for Linux are found under emulators. I play PSone games using ePSXe, n64 games using Mupen64Plus, SNES games with zSNES, GBA games with VisualBoy Advance, DOS games with DOSBox, and Windows games with WINE. There are plenty of options for gaming input devices in Linux. Any device that is HID compliant will likely run without problems. There are devices that will let you plug PS/PS2, NES, SNES, and n64 controllers right into your computer and use them with your emulators. There aren't any good n64 adapters on the market since the Adaptoid went out of production, but I'm planning to take the time to make a microcontroller circuit for connecting them. Maybe I'll share.

With no shortage of solutions for the biggest complaint about Linux (no games), I don't have any immediate shortcomings I can describe. Maybe its my rose-colored glasses. Maybe its the huge array of upsides clouding my judgement.

Tasty Desktop

Linux can be crafted to be as flashy or as spartan as the user likes. You can choose between a number of window managers (Gnome, KDE, XFCE, Enlightenment). You can have screen widgets. You can customize every single icon. You can install custom docking managers like Avant Window Navigator or Kiba Dock. You can go all out and install Compiz (previously Beryl) to give yourself wobbly, burning, alpha blended, motion blurred, dynamically zooming windows that exist across 4 desktops on the surface of a transparent 3D cube that you can rotate under a custom sky dome. There is no question that the Linux desktop environment is far superior in scope, functionality and configurability when compared to Windows.

Oldschool Tasty Desktop

First Julia

It may look meager, and by all counts really *is*, but at the time when those chaotic curls first appeared on my screen as a result of a some complex math, I was floored. I carefully adjusted the boundaries and sampling frequency of the system, and effectively zoomed in.

First Julia Zoom

I adapted my rendering engine and created a Fractal Playground, where I could explore and play in the infinite number of fractal landscapes out there. I was limited only by the speed of my processor and the precision of 64-bit floating point maths. To me, exploring these fractal landscapes was as exciting as going on vacation to some new place. Rewriting the governing equation, defining new complex math operations, adding and modifying terms... it was like a grab bag of free vacations. I never knew where I would end up next. Some of these places were drab and repetitive, while others astounded me as soon as I stepped off the tarmac. The ones that I really remember are the ones that were drab on the outside, but with a little digging revealed themselves as fractal geodes... containing an unrivalled inner beauty encased within a plain shroud.

Buried Treasure

I moved on from the typical convergence digrams where the color of a sample was defined by the number of iterations required to push it's magnitude past a threshold value. It was possible as well to track the actual orbit of a sample in complex space as you iterated it. Instead of just looking at the magnitude of a sample as it was iterated, I started plotting the values on the complex plane.

Encapsulating Sine

There was much more to be done however. This playground was fine for exploring, and giving brief reports on these landscapes, but it vastly lacked "production" features. The images I saved were limited in size to my screen resolution. The playground had a fullscreen mode, and I resorted to using the windows PrntScrn functionality to copy the full screen images to the clipboard and saving them off that way. I knew it was possible to create fractal images of arbitrary resolution... sometimes I hard coded a routine to dump a huge image of a system. It was a clunky way of accomplishing things, and many times while exploring I wished for the ability to do this dynamically. I also needed a better way to interface with the complex systems. Bringing up a dialog box and tabbing through controls, or even clicking on menu items was an annoyance while exploring. Fullscreen mode and modifying parameters (besides the zoom and pan) were mutually exclusive.

I was a bit daunted at first at the notion of entirely reworking the playground. My main code module (the one that contained the Windows entry point) had like a hundred global variables and was just under ten thousand lines long. In my state of fractal fervor, every new feature on the playground, every little test and modification was implemented as a kludge. I only cared about immediate results, and had cast maintainability to the wind. I built an empire out of bubblegum and bailing twine.

I rewrote the core routines, and this time built them out of brick instead of sticks and mud. I encapsulated everything, and made the multitude of non-exclusive boolean options for the system into a bitfield. There was now a single "state" variable where each individual bit represented a switch I could flip for a given option. One of the biggest and most effective changes was implementing a physically-based camera that existed in complex space. Physically-based, meaning the camera had momentum and friction, and moving it was all based on applying forces. When zooming/panning the weight of the camera would carry it for a bit even after releasing the controls. Note that this pre-dated the weighted interface of the iPhone by quite some time, and this idea was purely my own.

Now with the interface exclusive from the OS, I had a platform for fractal exploration that I never needed to bring out of fullscreen mode. With input and update routines built much like a game engine, I could define esoteric keypresses to my heart's desire, and the only change would be in the class's UpdateInput method. As I thought of new options, I defined a new bit in the bitfield and added accessors. It was simple to add routines for dumping the current scene to a huge detailed image, or saving each frame to make videos from. Now THIS was the kind of vehicle I needed for traversing the world of complex geometry.

Around this time I was an active member of the electronica scene in my area. I talked with some of the people setting up shows and got myself an invite to be a VJ for an upcoming event. I secured myself a projector and hauled my behemoth number cruncher (thanks, Stu!) to the venue. I had myself a little electroluminescent keyboard that worked perfect for manipulating the system in the darkness of the drum & bass arena. People were definitely impressed. One dude recognized the Mandelbrot set and was amazed to see it in such a dynamic light. That was probably the biggest compliment of the night. Everyone thought the convolving text routine where I feed text into a vector diagram and let the system swirl it around was mighty badass. All in all, it was quite a success.

Bolstered by the positive feedback from my first VJ gig, I was determined to expand the capabilities of this new application. Around this time I started experimenting with strange attractors. I used vector vector maps in the original fractal playground to build a "hit map" where computed locations of sample orbits were added to two-dimensional array that far exceeded the depth of a typical image. After subsampling the complex field and running thousands of iterations, I ran some statistical routines to get an idea of the spread of this data. I managed to clamp this data into a range acceptable by images, and interpolated the data into this clamped region to get some visual output. The results reminded me of images of strange attractors I had seen before. I didn't really know what a strange attractor was, but I figured they must be scads easier to work with than these complex vector diagrams.

I created a new application (again using parts from my game engine) for visualizing and manipulating strange attractors. These strange attractors proved to be quite varied and appealing. I especially enjoyed the way they moved when modulating the parameters over time. I produced hundreds of high resolution images and a few videos of these systems, all which were received well. I needed to get this new form of chaos integrated into my VJ software so I could switch between the systems on the fly. It was around this time that I migrated out of Windows and into linux, so this application would be the first to be resurrected in OpenGL.

Iconic Engineered Attractor