rss
Today, my World of Warcraft guild completed our first successful 10-man Lich King attempt, complete with our resto shaman single-healing 15% of the fight. Everyone did a great job and things finally came together after two months of attempts (and many more working through the rest of Icecrown Citadel).
After an extended hiatus from posting here, I have finally convinced myself to start writing a blog entry or three now and then.
Since the last time I posted, I've mostly been working on the FFmpeg project, and I am now a developer with commit access. FreeBASIC no longer scratches an itch for me, and itch-scratchiness is a very important factor when it comes to motivation for working on open source projects (at least for me), so I haven't been spending much time at all on FreeBASIC lately. I do check in from time to time to see how things are developing, but my interests have really refocused on C; my work on the FreeBASIC runtime (written in C) only helped fuel this change.
Most of my FFmpeg contributions up to this point have been fringe formats like a decoder for TMV, but I've also added support for slightly more useful formats like Sony Wave64 and RF64, as well as occasional fixes for bugs I run across or find unattended on the bug tracker. It's been an exciting and interesting experience to hack on code that ends up in things like VLC and Chrome, even if I only helped improve a little piece of it.
[category: /ffmpeg | permalink ]
Since someone asked, I decided to try porting FreeBASIC to OpenBSD. Luckily, it was not hard at all due to my previous work on porting to FreeBSD. After a couple of days, I have a basic working port.
You'll need an i386 OpenBSD installation; I have only tested this on the latest release at this time, OpenBSD 4.3, but it will probably work on older releases as well. You will also need an existing fbc executable for OpenBSD, unless you would like to cross-compile and assemble and link the files by hand. Download this file and extract it in your home directory (it expands to fbc): fbc-openbsd-i386-r5084.gz.
To build FreeBASIC on OpenBSD, you'll need to install some packages. This is how I installed the dependencies on OpenBSD 4.3:
export PKG_PATH=ftp://ftp.openbsd.org/pub/OpenBSD/4.3/packages/i386/ pkg_add -i gmake pkg_add -i autoconf # pick the latest version; currently, it is autoconf-2.61p1 pkg_add -i automake # pick the latest version; currently, it is automake-1.9.6p2 pkg_add -i subversion
Using the Subversion client that you just installed, check out the FreeBASIC source in your home directory (substitute the path you'd like in FBC_SRC).
FBC_SRC=~/src/fbc/fbc-svn
mkdir -p ${FBC_SRC}
svn co https://fbc.svn.sourceforge.net/svnroot/fbc/trunk/FreeBASIC ${FBC_SRC}
This is much the same as building for Linux. Currently, I have not tested building with objinfo (bfd) enabled, because the bfd.h header shipped with OpenBSD seems to be broken, but it will probably work if you build and install your own copy of libbfd.
Runtime library:
cd ${FBC_SRC}/src/rtlib/obj/openbsd
../../configure
gmake
gmake MULTITHREADED=1
gmake install
To make things simpler, we will copy the runtime libraries to their proper location so we can link the compiler successfully later before running install.sh. Since the prebuilt fbc binary is configured with /usr as its prefix, we will copy the files to /usr/lib/freebasic/openbsd/.
su mkdir /usr/lib/freebasic mkdir /usr/lib/freebasic/openbsd cp libfb*.a fbrt0.o /usr/lib/freebasic/openbsd/ exit
Graphics library (requires X):
cd ${FBC_SRC}/src/gfxlib2/obj/openbsd
../../configure
gmake
gmake MULTITHREADED=1
gmake install
Finally the compiler itself, using the existing OpenBSD compiler binary downloaded earlier:
cd ${FBC_SRC}/src/compiler/obj/openbsd
../../configure FBC=~/fbc --prefix=/usr --disable-objinfo
gmake
gmake install
Now we will do a full installation of FreeBASIC:
cd ${FBC_SRC}
su
./install.sh -i
exit
If all goes well, you should get a message stating that FreeBASIC has been successfully installed.
Note that this port has been very minimally tested; if you have any trouble, feel free to file a bug report or post questions on the FreeBASIC forums.
[category: /freebasic | permalink ]
I've been accepted to work with the Etherboot project in this year's Google Summer of Code! My project will involve adding COMBOOT support to gPXE. COMBOOT is a specification defined by SYSLINUX for programs to run at boot time; this can be used for showing menus, for example. I will be adding support to gPXE for loading these programs.
[category: /gsoc | permalink ]
I wrote this simple BF compiler in C some time ago, and I decided I'd dump it somewhere if someone is interested. It generates 16-bit x86 assembly language to be assembled with NASM into DOS COM-style executables. It's missing code to clear the memory to 0 as it really should before executing the program, but that's left as an exercise for the reader. :)
bfc.c:#include <stdio.h>
int main(int argc, char **argv)
{
FILE *fin, *fout;
int c, label = 0;
if (argc != 3) {
fprintf(stderr, "usage: %s in.bf out.asm\n", argv[0]);
return 1;
}
fin = fopen(argv[1], "r");
fout = fopen(argv[2], "w");
if (!fin || !fout) {
fprintf(stderr, "couldn't open files\n");
return 1;
}
fprintf(fout, "[BITS 16]\nmov bx, A\n");
while ((c = fgetc(fin)) != EOF) {
switch (c) {
case '>':
fprintf(fout, "inc bx\n");
break;
case '<':
fprintf(fout, "dec bx\n");
break;
case '+':
fprintf(fout, "inc byte [bx]\n");
break;
case '-':
fprintf(fout, "dec byte [bx]\n");
break;
case '.':
fprintf(fout, "call print\n");
break;
case ',':
fprintf(fout, "call input\n");
break;
case '[':
fprintf(fout, "cmp byte [bx],0\njz E%d\nB%d:\n", label, label);
label++;
break;
case ']':
label--;
fprintf(fout, "cmp byte [bx],0\njnz B%d\nE%d:\n", label, label);
break;
default:
break;
}
}
fprintf(fout, "ret\n"
"print:\npush bx\nmov dl,[bx]\nmov ah,2\nint 21h\npop bx\nret\n"
"input:\npush bx\nmov ah,8\nint 21h\npop bx\nmov [bx],al\nret\n"
"A:\n");
fclose(fin);
fclose(fout);
return 0;
}
[category: /languages | permalink ]
About a month ago, I decided to try to run only Linux on my main desktop machine (again - this happens once every few months or so). This time, I decided to use Ubuntu, since 7.10 was recently released and sounded pretty nice, and I wanted to get used to working with Ubuntu anyway since all the machines I manage for PLUG are running it as well (and some are desperately in need of an upgrade). I had tried a few months before with Gentoo, but this didn't turn out so well, mainly because of problems with Wine and multiple monitors. Anyway, I installed Ubuntu, and off I went.
Things worked well at first - in fact, everything went pretty smoothly compared to what I had expected, even installing the proprietary nVidia Linux drivers (I had a GeForce 7900 GT at the time; more on this in a bit). My multi-monitor setup even worked pretty nicely with a small amount of poking at nvidia-settings (sadly, the Ubuntu screen resolution tool was unable to grok the multi-monitor setup for some reason). Sauerbraten worked amazingly, even better than on the same hardware running Windows (probably due to OpenGL + multi-mon weirdness with the nVidia Windows drivers). The only problem was that it would not go fullscreen on a single monitor while letting the other one still display desktop and windowed applications. I settled for Sauerbraten in windowed mode, which worked pretty well in the end as long as it started up in the right position (it grabbed the mouse, so I couldn't really move the window once it was started). I was a pretty happy camper, not even worried that I was missing important emails or anything, since I moved all that to Gmail recently.
Then the problems started. I was content to play around with Sauerbraten and a few other native Linux games for a short time, but soon I had the urge to play some of my Windows games. I installed whatever Wine version Ubuntu had in its repository (pretty recent, if I remember right) and started installing games. First came Steam, which worked decently after a bit of tweaking. Based on previous experiences, I set Wine to use "desktop in a window" mode, which at least avoids games trying to go fullscreen over both monitors. I tried Portal, and it actually ran decently fast (nowhere near native on Windows performance, though), but the Wine relative mouse movement problem pretty much killed my ability to play it - if I moved the mouse at all quickly, it would zip right out of the window, and then I'd click, focusing on some other app. This was not really usable at all, and the same thing happened with all the other games I tried too - CS:S, Psychonauts, GTA:SA. Some of these had other problems as well, mainly graphical weirdness and a definite slowdown compared to Windows on the same hardware (notably, GTA:SA did load amazingly quickly, but it ran very poorly, even on my rather high-end hardware compared to what the game was designed for). Plus CS:S wouldn't even work online at all - I could sit in a server I created and shoot at bots, but that's no fun. All this added up meant that I essentially couldn't play any of the many games I own. This was a deal-breaker by itself.
Then, my nice new GeForce 8800 GT arrived (I had ordered it before I started playing with Linux again). This was the straw that broke the camel's back. I shut down, installed the new card, and booted up, expecting everything to work fine, since the nVidia drivers generally support all their cards, not just a single model. But sadly, the version of the proprietary drivers that Ubuntu packaged was not new enough to support the 8800! I found this a little odd, since the 8 series is not all that new. I decided to try to update it anyway, but I couldn't find any way to do this within Ubuntu's package system, so I just bit the bullet and grabbed the newest driver from nVidia's site. This broke all sorts of fun things, as it edited the X configuration files, and somehow afterwards the GUI login wouldn't even come up. I eventually hacked around on the configuration files for a bit by hand and got it to work, but it all broke again after a reboot.
So now I'm back on good old dependable Windows (Vista now, actually, since I drank the Kool-Aid and wanted to try DirectX 10 with my new card). This is not to say that it was a total failure - I started to get more used to developing solely on Linux, so now my fancy, expensive Windows machine is becoming more of an expensive X terminal connected to my router/server machine (which has always been running Linux - Gentoo, actually, for about a year now) when it comes to development. But for the forseeable future, I'll still be using some form of Windows for my desktop, since the situation with games is just not going to be fixed anytime soon. I don't want to be too harsh on Wine, as I'm sure it does a great job on most kinds of applications, but as things stand now, it's essentially unusable for running (my) games. Plus I don't want to wait some indeterminate amount of time for Wine to support some new feature needed by a newly released game; I want to play it as soon as I get my hands on it. Maybe someday I'll be able to afford two decent desktop machines with monitor, keyboard, etc., and space for it all (or at least a KVM switch, but I don't know of any of those that works with dual monitors) so I would be able to separate gaming from everything else, but for now, I'm stuck with Windows or Linux, not both, and Linux can't do everything I need, so the choice is easy.
(For those still confused, the title is a line from a Monty Python skit.)
[category: /linux | permalink ]
I was poking around at some web sites and came across this page by Jim Scott about generating "cellular textures". It looked simple enough, so I decided to toss together a quick implementation in FreeBASIC (the built-in graphics library makes things like this quick and easy). This is the result after a few minutes.
I used 320x200x8bpp mode since I didn't bother to optimize the distance to nearest point as explained on that page, it runs rather slowly for larger image sizes, and I wanted to play around a bit with palette effects, seemingly a lost art in this age of 32-bit true-color displays. :) I ended up adding just a silly little glow-like effect on the red channel.
Anyway, here's the code, nearly a direct translation of the techniques described on that page:
const scrw = 320, scrh = 200
const numpts = 50
' 0 <= r,g,b <= 255
private function qbrgb(byval r as uinteger, byval g as uinteger, byval b as uinteger) as uinteger
return (r shr 2) or ((g shr 2) shl 8) or ((b shr 2) shl 16)
end function
type Pt
x as single
y as single
end type
dim shared pts(0 to numpts - 1) as Pt
dim shared dist(0 to scrw, 0 to scrh) as single
dim shared pal(0 to 255) as uinteger
dim mindist as single = 999999
dim maxdist as single = 0
screenres scrw, scrh, 8
randomize timer
print "please wait..."
for i as integer = 0 to numpts - 1
with pts(i)
.x = int(rnd * scrw)
.y = int(rnd * scrh)
end with
next i
for y as integer = 0 to scrh - 1
for x as integer = 0 to scrw - 1
' this part can definitely be optimized... see the website linked above for info
dim as single d = 999999
for i as integer = 0 to numpts - 1
var thisD = (x - pts(i).x)^2 + (y - pts(i).y)^2
if thisD < d then d = thisD
next i
d = sqr(d)
dist(x, y) = d
if d < mindist then mindist = d
if d > maxdist then maxdist = d
next x
next y
for i as integer = 0 to 255
pal(i) = qbrgb(i, i, i)
next i
palette using pal(0)
for y as integer = 0 to scrh - 1
for x as integer = 0 to scrw - 1
dim as single c = ((dist(x, y) - mindist) / (maxdist - mindist)) * 255
pset (x, y), c
next x
next y
dim as double startt = timer
do until len(inkey)
for i as integer = 0 to 255
pal(i) = qbrgb(sin((timer - startt) * 2) * 64 + 128, i, i)
next i
palette using pal(0)
loop
To build FreeBASIC on FreeBSD, you'll need (for now) a Linux machine that can run and build FreeBASIC, as well as an i386 FreeBSD machine with the Linux binary emulation support installed. I've used FreeBSD 6.2, 6.3, and 7.0-rc1 successfully, but other suitably recent versions probably work too. Eventually (once everything is working) a prebuilt FreeBASIC release for FreeBSD will be available, but at this point, some things are still half-baked, so only people that want to test and develop should bother. (If you find these instructions too complicated or confusing, it's a good chance things aren't ready enough for you yet, so please just wait until then.) There is currently some bug with the FreeBSD console and FreeBASIC's terminal code, so if a command involving fbc seems to lock up indefinitely, try piping the output through | cat to make fbc think it's not using a real terminal.
On a Linux machine with FreeBASIC already installed, check out the FreeBASIC source code from SVN and build a compiler that runs on Linux (and FreeBSD with Linux binary emulation) and has the ability to target FreeBSD. To do this, follow the instructions on the FreeBASIC SVNLinux wiki page, except in the "Make fbc" step, add --enable-crosscomp-freebsd to the end of the ../../configure line. Check to be sure the resulting fbc_new has freebsd in the help output on the -target line, then copy it to your FreeBSD machine.
Install the following via ports or packages: subversion, gmake. For example, with the package system, pkg_add -r subversion
Using the Subversion client that you just installed, check out the FreeBASIC source in your home directory (substitute the path you'd like in FBC_SRC). Then set up some symbolic links to system libraries and tools so fbc can find them.
FBC_SRC=~/src/fbc/fbc-svn
svn co https://fbc.svn.sourceforge.net/svnroot/fbc/trunk ${FBC_SRC}
cd ${FBC_SRC}/lib
mkdir freebsd
cd freebsd
ln -s /usr/lib/crt1.o
ln -s /usr/lib/crti.o
ln -s /usr/lib/crtbegin.o
ln -s /usr/lib/crtend.o
ln -s /usr/lib/crtn.o
cd ../../bin/freebsd
ln -s /usr/bin/as
ln -s /usr/bin/ar
ln -s /usr/bin/ld
You will also need libbfd, part of GNU Binutils. FreeBASIC currently only has headers for version 2.17, and the library interface changes between versions, so use exactly that version, not newer or older ones.
fetch http://ftp.gnu.org/gnu/binutils/binutils-2.17.tar.bz2
tar jxf binutils-2.17.tar.bz2
cd binutils-2.17
cd intl && ./configure && make && cp libintl.a ${FBC_SRC}/lib/freebsd/ && cd ..
cd bfd && ./configure && make && cp libbfd.a ${FBC_SRC}/lib/freebsd/ && cd ..
cd libiberty && ./configure && make && cp libiberty.a ${FBC_SRC}/lib/freebsd/After this is done, you can remove the entire binutils-2.17 directory.
This is much the same as building for Linux.
Runtime library:
cd ${FBC_SRC}/src/rtlib/obj/freebsd
../../configure
gmake
gmake MULTITHREADED=1
gmake install
Graphics library (requires X):
cd ${FBC_SRC}/src/gfxlib2/obj/freebsd
../../configure
gmake
gmake MULTITHREADED=1
gmake install
Finally the compiler itself, using the Linux binary cross-compiler from earlier (change fbc-linux to wherever you put the Linux binary):
cd ${FBC_SRC}/src/compiler/obj/freebsd
../../configure FBC="fbc-linux -prefix ${FBC_SRC}"
gmake
At this point, you should have a working fbc_new that prints "for freebsd (target:freebsd)" at the end of the ./fbc_new -version output. Copy or move it somewhere and write a small shell script called fbc (perhaps in ~/bin) to run it with the proper -prefix automatically:
#!/bin/sh /path/to/fbc -prefix /path/to/fbc $*That's it! You should now have a (somewhat) working FreeBASIC compiler and runtime libraries on FreeBSD. If you fix something or implement missing features, patches are always welcome. :)
[category: /freebasic | permalink ]
This is a test of the emergency weblogging system. If this were a real emergency, there might actually be some content here.
[category: /test | permalink ]
