firefield

I’ve decided to stop updating this blog — instead I have created a new one (with all the old posts here) on firefield.wordpress.com. I have no reason to keep this site as I only use it for my blog. Since I can get all of this for free on Wordpress I think it’s the better bargain.

glw is another of my projects. It is supposed to be a rendering target management library for OpenGL that’s portable and runs on any graphics system — from the lowly SVGAlib and the Linux framebuffer all the way to X and the graphics system of Windows and Mac OS X (and anything in between).

I have to handle input as well as all graphical resources. This is because X is bloated (and possible also others) and doesn’t allow too much flexibility with regard to this kind of thing. I think it will work somewhat OK though as I have a reasonable design of the input API.

I installed Plan 9 today on a spare disc I had lying around. Plan 9 is an operating system which in may ways resembles Unix — only with a much much cleaner design. A lot of people say that in Unix everything is a file; this is not entirely true as many (especially network) resources are simply not available in the filesystem. In Plan 9 everything is available in the filesystem — directly.

I think that Plan 9, the operating system, is a very well designed system with a lot of great thinking — quite frankly I doubt that there is anything out there that is any better with regards to abstraction. It, however, does deserve to be called two things: unfriendly and extremely friendly. It is unfriendly not by design, but by the state it’s in — so I guess that’s not really something I should be writing at all. The unfriendliness does not come from Plan 9’s design itself but rather from the software it carries. This is very much so, possible to fix. I doubt that the current set of developers are willing to do this though as they seem to be content with the current status quo. It is extremely friendly to those who know what they are doing and allows complete — as in with no exceptions — control over the system using text manipulating programs like awk, sed and grep.

It’s damn ugly though.

I’ve apparently decide to get really sick. This sucks.

Anyways, glw is not progressing too much right now. I’ve implemented a few missing parts but nothing big. I’m contemplating a redesign of the input model. The new model would take 4 functions — a read function (glwReadInput), a grab function (glwGrabDevice), n ungrab function (glwUngrabDevice) and a function to check if a device type is supported by the library (glwSupportsDevice — altneratively glwDevicesSupported). I like this design because it allows a user of the library to add support for devices the library didn’t have support for, when the user software was compiled. It also means that I can add support for misc devices without forcing people to upgrade their binaries.

How to get output, exactly, is still a bit of a mystery — I guess an extra funciton (glwDevicePosition) would be in order.

Oh, and yeah. Fullscreen mode. I’m not quite sure how I want to do this. It appears that the best and safest option is XVidMode, but XRandR also looks like a good choise — the problem with XRandR is that it’s not available if you use Xinerama. Otherwise I would rather use that.

I’m getting up too early for someone who is on a holiday.

I got rid of a lot of spammers last night — I made sure that people can only comment if they register. The spam was too much (something like 20 posts per day).

I’ve finished the mouse handling parts of glw — it took me some time because I was too much in a hurry and forgot to read the documentation right. Not a good idea.

Keyboard input is messed up though — I’ve done something terribly wrong. I’ll have to have a look at it by Sunday. RIght now, I have to sleep.

glw (my portable OpenGL window library) has a few bugs in the things I have implemented — this is of course to be expected for such an early product — so far I have squashed a few bugs resulting in seg faults on shut down (apparantly I was doing too much) but I still have a few other bugs lying around. I have an old attempt which did it right so I’m going to have to investigate what the difference is and see if I can fix my newest attempt.

I have been wondering why there is no portable window mangement library for OpenGL, so I’ve started to write my own. It’s nearing completion and have the very basic features implemented already. A few vital things (OpenGL support for example) are missing — as soon as I have that done, I’ll release the code for X (sorry, I won’t be writing a Windows port).

If you have an X server running on Windows or Mac OS X you should be able to use the code, as it only depends on X and GLX (besides the standard C library of course).

I am studying Dijkstra smoothsort algorithm at the moment, with the hope that I will be able to implement it at some point in time. RIght now I don’t get what he was writing at all. Anyways, I was trying to sleep but around 5-ish, I decided that I couldn’t because of something that really bothered me.

I had an idea about sorting — the simplest way to sort I could come up with looked to me like it would sort in O(n) time, so I got up and wrote down what the algorithm would do and implemented it. I then decided that this was sos simple that there had to be others who had written this before me, but alas, I have found no references to the algorithm anywhere. I call it chain sort beacuse I envision the data as being hung on chains on a bar.

The algorithm is as follows:

Let C be a collection of chains.
For each element, E, in a list of elements, L.
Add E to it's chain C[E]

Let R be a list of elements
For each chain, c, in C
For each element, e, in c
Add e to R.

I have posted a request for more information about the algorithm on fedoraforum.org.

I also implemented the algorithm in the follwoing C++ code

template vector chain_sort(vector O_)
{
T_ min = *min_element(O_.begin(), O_.end());
T_ max = *max_element(O_.begin(), O_.end());
vector result(O_.size());
vector< vector > chains( 1 + max - min );
for (unsigned int v = 0; v < O_.size(); v++)
chains[O_[v] - min].push_back(O_[v]);
unsigned int counter = 0;
for (unsigned int i = 0; i < chains.size(); i++)
for (unsigned int j = 0; j < chains[i].size(); j++)
result[counter++] = chains[i][j];
return result;
}

I just mailed a job application for OFiR today. I have no idea what the outcome will be, but I (naturally) hope that I can be of some use to them. The job I hope to get, is mostly ment to be a job for the summer (somewhat equivalent to the Google Summer of Code project, only less google) –. though I’m not opposed to the idea of something more long term.