Clipboard support in Vectre is done, and I finally got its pen tool working the right way. Like Illustrator, creating paths is a fluid process -- one can define cusp and smooth points on the fly. Keeping track of all the right states was challenging, to say the least.
It was tempting to use the Alt key as a modifier, the way the Windows version of Illustrator does. I settled on letting the Ctrl key handle it, since the Alt key is a reserved system key, and even Illustrator gets into annoying conflicts with Windows over it.
SVG export was added also. The more interoperability, the better.
December 15, 2002
Vectre, the spline editor, is just about done.
All that's left is cut/copy/paste, the documentation, and the preferences and transform dialogs, and that should wrap it up.
The Undo feature went well. It works to any user-defined depth, and also supports Redo. If you hold down the Ctrl+Z and Ctrl+Y keys, it's neat because you can see your document regress and rebuild in realtime. Some of the techniques will also be used to redesign Leveller's undo system, which is currently limited to one edit.
The beige color in the above picture is user-definable, of course -- I just added it because I found white to be a little intense sometimes.
December 9, 2002
Sometimes it's good to wait.
Apparently the Mono team is hard at work supporting .NET's Windows.Forms classes to be cross-platform. So maybe it's a good thing Leveller wasn't ported to other platforms yet. By switching to .NET, I can do two things at once: update to a more modern programming system and rapidly deploy on multiple platforms. Assuming Microsoft doesn't pull any patent-enforcement tricks on non-native .NET implementations.
The spline editor (Daylon Vectre) continues to go well. I added three transform tools (scale, rotate, and flip) and started the docs. It'll soon be done, and then I can wrap up the UV mapping feature in Leveller, and version 2.3 can go out. The multitexture and material map support is moved to 2.4, since there's no reason why people should wait for those features in order to use UV mapping.
December 5, 2002
Finally got the new spline editor working enough to show a screenshot.
I use its Adobe Illustrator import feature to test the scenegraph's ability to handle multiple spline path objects. It seems to work okay. The advantage here is that it's a simple utility app, not a full-blown drawing program, so the scenegraph can be just a straight linked list instead of a complex bintree structure.
After getting zooming and panning to work (which was a snap, since the code is nearly identical to what Leveller uses) I added the Pointer tool to manipulate existing splines and then the Pen tool to create new splines. That, I admit, was a new experience. All told, the ordeal wound up stuffing fifty methods into the spline class. At one point I realized I had chosen the wrong fundamental data structure to represent editable Bezier splines, and retrofitting to the right one took two whole days. It was absolutely necessary, though -- if I had hacked the existing structure, the whole thing would be spaghetti by now. Definitely not the kind of project you want to tackle early in your career. :)
A release build currently takes 170K, and if I leave out the splash screen (or provide a way to disable it) this puppy can start in less than a second. You just double-click its icon and its running. Now that's the way it should be. :)
The multi-path support may seem odd given that Leveller's lathe UV mapper only uses one path object. However, I wanted the spline editor to be the testbed for Leveller 3.0's vector layer. All the tools are derived from Leveller's base tool class, so embedding them into Leveller will be straightforward.
As I mentioned, editing is very similar to Illustrator. Implementing it, however, required a complex state transition scheme. Let's say I have a new-found respect for what Adobe's developers had to go through. :) But at least it's nothing like the state machine code in Corel Draw (which I've seen, of course), which has to deal with hundreds of possible states.
One nice thing is that the path class is the same one used by Leveller's Illustrator import plug-in, so the improvements will propogate to it, namely reading of non-1.1 files and proper skipping over of embedded non-scenegraph data (such as pattern tiles).
I have to be honest and say that vector editors are not really my thing. State machines and state transition graphs are a big turn-off. But the experience has been good. It wasn't pleasant most of the time, but ultimately it was easier than I thought it would be. If I ever have to do this again (and I probably will, if I stay in the tools business) I now have a first-hand idea of what's involved.
Providing alphas and betas might be a good idea. Let people try out the editing features and see if there's anything they want changed.
December 3, 2002
And now for something a little different.
I always wondered what the Mandelbrot set looked like in those narrow crevices that lie between the big circular shapes. One needs to use an awfully high iteration level (in this case, 15,000) but XaoS was up to the task. I documented the voyage with the following images. The deeper ones can be clicked to show an enlarged, zoomrect-free version.
I started with a northern circle adjacent to the main body of the set.
At this scale, it becomes evident that the circles don't really touch -- there is an infinitely small gap between them that one could, in theory, forever zoom into.
Navigation gets difficult at this point because the gap, even with the window at full screen size, is only a few pixels high. I found myself having to stop and press 'R' to redraw the region at full precision rather than let the dynamic rendering miss the gap since it starts off using low resolution blocks.
Finally, the gap expands into something with interesting structure. We are so far along into it, that its sides appear almost perfectly horizontal.
Even at 15,000 iterations, a lot of regions tend to be inside the set (the black parts). But the screen redraws already take as long as I dare (about three minutes each). But the trip is worth it: these are shapes I've never seen before; they don't look like anything one usually sees in typical Mandelbrot pictures.
Upon even closer inspection, I notice something interesting...
The gaps of these shapes are filled with "fingers" that widen out into prominences. At low zoom, the edges of shapes tend to be merely bordered with repeating smaller shapes as decoration. But here, something of a higher order is happening.
November 27, 2002
The saga continues. After much consideration, I decided to factor the spline editor as its own standalone application, since this would provide greater reusability for other things. It took a few days just to borrow some of the Leveller code to build the spline editor's window system, but it was worth it. Since the two apps have similar GUIs, the learning curve will be much lower. As for path editing, I'm trying to duplicate Illustrator 1.1 as much as possible (the more recent versions introduced a more complex system which pissed off lots of people, yours truly included).
November 23, 2002
Kudos to Paul Gregory for releasing his 0.7.1 version of the Aqsis REYES renderer, which I've confirmed can now (with a little work) render .RIB files exported by Leveller.
Here's a test 64 x 64 gforge terrain using a bilinear PatchMesh:
Here's the same heightfield as a bicubic PatchMesh. The BMRT 2.6 version is on the right. Aqsis's large shadows are softer, and there appear to be less shadowbias artifacts. I don't understand why the shadows should differ, since only a simple pointlight (instead of an area light) was specified. But it's safe to say that Aqsis' implementation of bicubic interpolation matches BMRT's. I'm guessing that since the reference OpenGL rendering (see below) has similar soft shadows, BMRT's hard ones are due to the light rays actually being backtraced to the lightsource for proper occlusion.
For reference, below is the same heightfield in Leveller, using it's "Good" shading method, which samples only one triangle for each vertex surface normal.
To adjust Leveller .RIB files for Aqsis, do this: don't include the background (this creates a large hollow ambient skysphere that confuses Aqsis) and comment out the "Option 'render' 'minshadowbias' [0.2]" and "Attribute 'light' 'nsamples' [1]" lines in the .RIB File.
November 20, 2002
There were some errors in the lathe map's surface normal generator, and vertices weren't being distributed proportionally across path segments, but the fixes are in. One of the tests was this gforge terrain applied to a basic lathed curve:
November 19, 2002
Since the Adobe Illustrator import plug-in has a Bezier spline class, reading paths is easy, so I added a lathed UV mapping mode. For those without Illustrator, a simple path editor will be included.
None of these mappings, of course, will be all that useful until the various mesh exports (POV, RIB, VRML, DXF, etc.) tie into it. Once that's done, turning out interesting meshes will be straightforward.
The raytracer won't be updated to render non-planar mappings, since its heightfield intersection algorithm is heavily optimized by assuming planarity, and tesselating down to triangles would use too much memory. Since the DXF import has a working triangle rasterizer, the better approach is to switch to a general-purpose scanline renderer.
November 16, 2002
Now that's what I'm talking about... :).
November 15, 2002
Got the DXF import plug-in working.
Since DXF is a vector format, the importer maps the bounding volume of the DXF model onto the entire Leveller heightfield. That's why the teapot looks vertically distorted a bit.
November 14, 2002
I finally decided to write a DXF import plug-in. After reviewing the DXF format, I realized that parsing its 3DFACE records and rasterizing the triangles into the active heightfield as a depth buffer using an ortho projection would be useful enough for most people. As long as the program emitting the DXF data can do so using simple triangle lists, it'll work.
November 13, 2002
The UV mapping feature continues well. I've generalized it to make supporting different mappings easy, and since the default planar style is part of that system, vertical exaggeration will be supported too. In fact, any axis can be distorted now.
The above picture shows a disc mapping. Reminds me of what the characters in Larry Niven's Ringworld Engineers found when coming across the Earth map on the Ringworld. :)
November 11, 2002
Got the Mac version of wxWindows working. Well, most of the sample apps compiled, anyway. Nearly all of them have bugs, many serious. On the other hand, the Mac version is not an official release.
The bad news is, even with wxWindows, porting Leveller to the Mac is still going to be a ton of work. The good news is, OpenGL is supported and appears to run fine.
For a test, I was thinking it's high time to develop a single-source version of the TERDISP utility, add an OpenGL scene pane to it, and do it with wxWindows. That will let me try enough of the basics (menus, windows, dialogs, file handling, graphics, etc.) to get a proper idea of what the process is like. If all goes well, we basically wind up with a "Leveller Viewer Lite" on Windows, Linux, and Mac.
OS X took all the crashing in stride, which is great. It's amazing how rock solid it is.
November 7, 2002
The scene pane now has a virtual trackball. I use the term loosely; it's a simpler rotation system but it has the virtue of taking less code and being well-suited for both planar and spherical heightfields. Wireframe mode now supports the spherical view, and here's a screen shot showing a solid rendering and a wireframe closeup:
wxWindows built and ran perfectly under Windows, but building the sample apps on the Mac has been fruitless so far (sigh).
November 5, 2002
Got the spherical projection working. Turns out I had forgotten one line of code, and the upper left heightfield slab was getting over-referenced for elevations. Here's some image samples:
The feature is almost useless without a trackball navigator, so that's going in next.
Started evaluating wxWindows, the free and open source cross-platform C++ development kit. As much as I'd like to use Qt, due diligence requires one to investigate, shall we say, the more financially prudent alternatives.
November 2, 2002
As was bound to happen, I left out an important item from yesterday's list (see below): higher resolution displays.
I'd discussed them now and then at EA. The consensus was that they're inevitable, and developers should be open to modifying their apps to support them. One can get a 200 or 300 dpi display today, except it's prohibitively expensive, and bitmap elements like icons and toolbars look way too small.
The hardware has to be beefier: just to double the dot pitch from 72 to 144 dpi would need four times the video memory and bandwidth. For a 24-bit 1024 x 768 display going to 2048 x 1536, we need nine megabytes. That's easily in the realm of video memory today, but we must also factor in auxiliary items like backbuffers, texture buffers, depth buffers, etc. At 288 dpi, we're looking at a resolution of 4096 x 3072 and 36 MB just for the primary 24-bit display buffer.
Fortunately, icons have been getting large. If you run OS X or Windows XP, you see them everywhere. Even Redhat Linux is doing it. Since toolbars use mostly icon buttons, they're easy to update (speaking of which, I should update Leveller's, especially the map overlay toolbar buttons. Some users run at 1600 x 1200, and I can't imagine they're pleased).
Dialog boxes are harder. Windows tries to make them size-agnostic with their "dialog units" measurement system, but the reality is that everyone pretty much uses pixels. Fortunately, I've worked a long time on flexible dialog box techniques, and I imagine the big guys are too.
Assuming no technological hurdles, I think 300 or 400 dpi would be a practical limit. Text would appear near-typographic in quality, and individual pixels would be at the threshhold of perception. Printers need greater resolution (typically 1200 or 2400 dpi) because they must emulate gray shades with halftones, but displays don't have that requirement.
November 1, 2002
Daylon Graphics starts its fifth fiscal year today.
Funny how time flies. As is traditional, I evaluate what the company is doing and where it should be going in general terms. Although XaoS took a month longer than planned, it's handy that its release coincides with the fiscal year.
I'm studying DirectX. As a programmer/artist, it's necessary to be fluent in the contemporary tools. I have some old game source code that will be fun to revamp. It will also help me better understand how heightfields, bumpmaps, and textures are used in the gaming development pipeline. When things are going slow, the best thing to do is hit the books.
The economy (or at least the IT industry) is in the toilet. Reminds me of exactly ten years ago when I first moved to Vancouver. There was a recession dragging on that just refused to end. I remember responding to a programmer-wanted ad from Computer Associates downtown. The room next to the interview office was packed with what had to be at least sixty candidates. I remember thinking it was neat because everyone was immaculately dressed, so it looked like a formal dinner party. I never forgot the expression on the interviewer's face, either: It's a buyer's market, so don't call us, we'll call you.
Then things changed, of course. The economy improved. "Client-server" became a buzzword. Modems reached 28.8Kbps and then 56Kbps. MFC debuted. Visual Basic hit version 3. Windows 3.1 included TrueType. The Pentium and the PowerPC arrived. MS Word reached 6.0, which for many people was all the word processor they would ever need. Affordable LAN NICs went from 10 to 100 Mpbs. Video cards reached 1024 x 768 resolution. Monitors became multisync. "Multimedia" became hot after client-server died down. id released Doom. Portables crept out of the toy stage and became more affordable. Cellular phones became popular. Windows went 32-bit. And the Internet went mainstream.
And then things changed again, and here we are. These things go in cycles. Like Chance said in the movie Being There, there is summer, and winter, and summer again.
I don't know if we'll experience the same level of change we did ten years ago. Do people need their software to be 64-bit? Do our games need more eye candy?
I can't speak for everyone, but the only things I'd really like are:
- A mainstream OS that combines the best political and technological features of BeOS, Linux and Windows.
- A perfect spam filter.
- Better AI, lighting, and dynamism in games.
- Better development systems.
- A search engine that finds what you want.
- Cooler, more reliable CPUs.
- Shorter boot times.
- Faster hard drives.
- Reliable, affordable backup for today's hard drives.
- Broadband everywhere.
- Affordable cell phone service.
- Affordable 200+ channel television service.
- Decent battery life for portable devices.
- A working open source business model.
- Abolishment of software patents.
- A working tricorder.
- A car that gets 100 MPG, doesn't pollute, and has an engine that can be fixed by anyone.
- An affordable/reliable/safe aircar.
- The RIAA disbanded (just so everyone would shut up about them and move on).
- That some advertising (like billboards) would go away.
Except for the first five items, nothing on that list is about software. So it may be that the IT industry has finally matured. The only thing really left to write is AI, but that's just so damn difficult.
October 30, 2002
Well, Daylon XaoS is finally done and on sale. I still have to finalize the XaoS section of the website, but at least the hard part is over.
Be interesting to see how it goes. Do vendor-supported GPL'd graphics applications have a future? I hope so, because it's a win-win for everyone. If you need vendor support, you got it. If you need the source code, you got that too. It's hard to go wrong. At the very least, two good things have happened: XaoS has a nice, working Win32 GUI driver, and one can now paste fractal heightfields directly into Leveller.
Even if it all it does is breathe new life into XaoS, that by itself would be something. It's a nice program, after all, and deserves support.
October 27, 2002
Uploaded the VistaPro import plug-in.
Since I had file formats on my mind, I revamped the old format list in the tour section and replaced it with a nicer graphic.
Made big advances in the Daylon XaoS documentation. The holdup is producing all the imagery, because the only way to properly describe XaoS is with pictures. I've hit the PrtScrn key so many times, the button has lost all meaning. :)
A mentor of mine once told me that although you can upgrade a computer to perform better, to get to the next level properly requires getting a new one, because hardware upgrades don't really address core architectural issues. So it was with that thought in mind that I stopped screwing around with the 200 Mhz PC and replaced it with an Athlon 2000XP-based system. In one fell swoop, I can now test Leveller on a fast machine, on WindowsXP, on an AMD processor, and run Linux properly.
Installing Linux fell to me. My PC supplier refused to have anything to do with it, even though they build their own machines. They told me that less than one percent of their clients ask about Linux. If that's true, it means Linux isn't as popular as I'd thought/hoped, or Linux users quietly install Linux themselves after buying their PCs. On the other hand, this part of British Columbia isn't exactly a hotbed of computer use in general.
I have to admit that Leveller looks nice under WinXP. It runs way fast on the Athlon, too. I fired up a 2K x 2K heightfield and the machine just played with it in style. I also got to try out the new memcpy method optimizer, and the AMD memcpy smoked everything else. AMD may not be as big as Intel, but they certainly do some interesting things.
Linux runs better, of course. The KDevelop IDE still can't index its documentation properly (for some reason it proceeds to index every file on the entire hard drive), but it did create default projects properly. So hopefully I can start the porting prototype soon.
October 26, 2002
Well, it took a while, but Leveller now has a VistaPro import plug-in (to be uploaded soon). Turns out Eric Sibert had written some Pascal source code to parse small VistaPro DEMs (those of the 258 x 258 variety) but after some adjustments, I made it handle the other sizes. Ernie Wright's VDEM2STM program converts VistaPro to STM format, which Leveller can read, but it's always been an awkward second step.
VistaPro is not that byzantine a format, but it has enough to trip the casual person: integers are in Motorola endianness, and each scanline is delta-encoded and then RLE encoded. The real problem is that VistaPro is an old program that's been eclipsed by others, and information on the format is notoriously sparse.
The popularity of VistaPro DEMs is probably due to its authors having included tons of DEMs with the program, and considering that governments are shifting to a paid licencing system for satellite imagery, those old DEMs can remain desirable. And it's not a bad format, either, considering it compresses runs of constant slope.
I have no idea if the plug-in will import all VistaPro DEMs. It's possible that there are format variants I'm unaware of.
Exporting to VistaPro is also an idea. The only value there would be for people who need to transfer heightfields to some program that requires it, and at the moment I can't honestly think of any.
October 23, 2002
Paul Gregory, the nice person behind the Aqsis REYES renderer, quickly resolved the Leveller compatability issue. Unfortunately, a new binary of Aqsis won't be available for a while and the sources take some more figuring out to build than I have time for just yet. But it's a good sign nevertheless. Actually, ever since BMRT lost support, it's great that someone else filled the gap. If you don't want to wait, you can grab the Aqsis sources via anonymous CVS from SourceForge and build them yourself.
Thinking about Leveller 2.3 and what it should and should not be. Success has always depended on being clear about the feature set, and not overdoing things. So far, the consensus is emerging that it will have material map editing, multitexturing, and multiple projection modes. For the last item, I'd like to support arbitrary model import with arbitrary UV mapping, but that's on the optimistic side if we hope for a three-month dev schedule.
The sphere projection prototype is strange. It shows gapping between slabs with 1 x 1 pixel stepping, even though its HF sampling code is identical to the planar projection's. I've obviously miffed something somewhere, but it's really subtle.
October 20, 2002
Tested Leveller compatability with the open-source Aqsis Renderman-compliant REYES renderer. Although exported RIB files do get crunched by Aqsis, the output is missing or incorrect. As near as I can tell, it looks like incorrect camera placement, but that would be a pretty unlikely thing for a renderer to misimplement, since it would affect lots of files. I can't fault Aqsis because it's a work in progress, and hopefully with a little work this will be easily resolved.
Tried RedHat Linux 8.0 some more. Had to switch to the Gnome desktop from KDE because I only have 64 Mb of RAM, and KDE saps too many resources. It's ungodly slow. It also uses Nautilus, which happily helps itself to over 10 MB. I wish I knew what it needs all the memory for.
Yes, I can always stuff more RAM into the computer, but the point is, I shouldn't have to. This is Linux, right? The OS that supposedly plays better than Windows with legacy hardware? Ironically, Windows runs way faster on it. I'm fully open to concede that maybe I need to tune things more (I did disable several unused daemons), but I can't help thinking that maybe one point of an OS installer is that it should recognize a limited environment and tune itself accordingly.
The KDevelop IDE was a wash -- it failed to index its own documentation files, and couldn't generate a buildable MDI test app project. I'm not completely untechnical, but it's exactly this kind of thing that rolls people's eyes. I mean, how hard can it be to get a program installed and to have it just work off the bat? Why am I supposed to tell it where the Qt, KDE, and X11 headers are? Doesn't it already know? It does go to enormous lengths to configure the makefile for a new project, but obviously not quite far enough. :)
Don't get me wrong. I still love Linux. It keeps getting better all the time, and I'm still looking forward to porting stuff to it. I am going to add more RAM to the box. I'm just disappointed that the big effort to make it friendlier was compromised. People who do that much work deserve more. It's like you're polishing this rough diamond, trying your damndest to make it sparkle, but someone else keeps doing things that leave smudges. It's all the worse because the mistakes stand out so much more by contrast.
October 18, 2002
Finally got Red Hat Linux 8.0 downloaded and installed.
So far, so good. The new BlueCurve interface with the antialiased fonts was worth it. The installer was the best one I've experienced so far; Red Hat has clearly worked very hard to make it as painless as possible.
The non-commercial version of Qt is included, which is handy. I can dive into trying some prototype porting of Leveller to see how it goes.
I added a new download area on the site because some of the files, such as the recent memcpy test app, are not specific to Leveller. I imagine more material will be added as time goes by. Speaking of that app, I updated it again, and include its source code as well.
October 15, 2002
Added a user preference to let memory transfers be optimized. For simplicity, I currently support the four main methods: rep movsd, FPU registers, MMX/SSE, and AMD's memcpy() substitute (which also requires SSE). Leveller can be asked to autodetect which method is best, and displays the results like this:
Fans of the AMD method take heart: the test uses the default block alignment provided by Leveller's memory manager, which isn't optimized for the AMD code. I should be able to improve things before 2.3 is released.
October 14, 2002
Ask, and you shall receive. :)
Before every edit, Leveller takes time to backup the heightfield to its Undo buffer. On large heightfields (or large work areas) this can be annoying. Lars Norpchen graciously forwarded the source code to XELF's optimized Intel x86 memcpy() functions and AMD's even faster one, and after a little fiddling, he's got a patched 2.2 exe which runs faster.
The catch? Your CPU has to have MMX or SSE support. A fast system bus also helps. I've modified XELF's memory test utility to let people safely try out which memcpy method works best for them. You can get it here.
October 13, 2002
Turns out Leveller 2.2 still doesn't save large documents to network volumes reliably. After some digging around on the Net, I found some notes other people made that Windows NT doesn't like stdlib fwrite() being called with large buffer size arguments. So another fix attempt is in the works -- it simply breaks up large I/O requests into smaller ones. The Win32 SDK docs do state that networked named pipe I/O is limited to 64K transfers, but nothing about general file I/O.
Speaking of documentation, the XaoS docs are coming along. It feels strange writing them for a program I didn't develop, but I think that's more because I'm not as familiar with XaoS as I am with Leveller. But regardless of the program, docs are good -- to understand a thing properly, the best way is to try explaining how it works to someone else.
Blender, the multiplatform 3D modeler (and video/sound editor), became GPL'd open source today. It's developers asked the public to donate 100,000 euros and got them (via PayPal and such), so now they've (afaik) lived up to their end of the bargain. Apparently the source code (like the user interface) is on the hard-to-understand side, but now that it's open, it's only a matter of time before some nice people fluff it up.
I'm glad it worked out. It helps a lot to learn which business models work, especially in these "interesting" economic times. I have nothing against open sourcing Leveller using similar means, and likewise many other developers may have equivalent plans that they'll now go forward with.
Who knows? Maybe someday all for-profit software will be developed that way -- initially closed, funded by the public, and then completely opened. I don't imagine it would work for really big projects that continually need large staffs of full-time developers, but there are also many good programs written by small teams and individuals, and even if only their work gets the treatment, it's still nice to have. A hundred thousand dollars is peanuts to a typical corporation with even a modest payroll, but for one or two people, it can mean living in a house instead of wasting money on rent, or sending one's children to college.
October 10, 2002
Well, it looks like Daylon XaoS didn't make it to my intended release date. Just too much going on these days. I also hadn't heard back from Jan about merging my changes into the final sources. I can ship anyway, of course, but it would be nice to have everything up-to-date at the same time. On the plus side, I realized that XaoS assumes three-button mice (the middle button pans the fractal), which not everyone has, so I added a middle-button emulator by holding the left and right buttons down together simultaneously. I tried using the Ctrl key as a modifier first, but repeating keyboard events slow things down annoyingly.
Timothy Lenz asked about spherical mapping on the Leveller mailing list, and after inserting some test code into Leveller's OpenGL renderer I modified the scene pane to emit spherical views:
October 5, 2002
Finally got some time to update the Daylon XaoS product page. Only the "Help" link works, but it's a start. Jan has received the patch submission and reintegration with the main sources should happen over the next few days.
Added "heightfield" under Wikipedia's list of data types (in their Comp. Sci. section) and then copied the text of Leveller's "About Heightfields" doc page over. You can see the results here. I unfortunately have no idea of how Wikipedia articles are formatted so it came out a litte bland. But, maybe other readers will help.
Which is the amazing thing about Wikipedia. It's on online encyclopedia which, given enough time, will likely become the best repository of all human knowledge. It has a style so open it took me aback the first time I saw it: to change an article, you just click "Edit this Page", make your changes in a form, and click "Save".
That's it. No account creation, no logging in, no beauracracy. Anyone can make any change anytime. It's so simple and so reckless that it seems impossible.
Of course, there's a catch. Wikipedia never throws anything anyway. If someone replaces what you typed with garbage, you can just revert to your (earlier) version and make it the current one. And unless the lamers are interested in constantly vandalizing articles, the system as a whole slowly but steadily drifts towards perfection.
Hmm... lamers could automate the vandalizing process. After all, the whole thing is done over the Net using computers. There's no way for the Wikipedia server to know that it's a human being posting crap. I don't see how hard it would be to (gasp) create a bot that simply follows links through the articles and in the course of a day or two systematically trashes the whole thing.
October 3, 2002
Well, I'm pleased to say that Daylon XaoS is feature complete.
All that's left is to try and resolve an unfortunate timer-related bug. For some reason, saving a configuration file or playing tutorial animations destabilizes XoaS.
Came across an article quoting Microsoft's Steve Ballmer saying that bugs are intrinsic to large software projects. I think it would have been fairer to say that bugs are a reflection about what users are willing to accept.
Think of it this way: imagine a development team with an unusual release process. When they have a release, they don't ship it. Instead, they release it to a private group of a thousand people who use it for a year. Only when these people have stopped experiencing problems is the software then released to the actual public.
The result would be software of nearly perfect quality. The problem, naturally, is that such a development model would not be competitive since it would significantly delay the introduction of new products. Users would switch to a competitor's product, and that would be that. There's also the logistical problem of trying to keep a thousand people from not leaking the product to the public earlier, especially as they would be under great pressure from those saying "I don't care if it has a few bugs, I'll use it anyway."
The dream of perfectly automated testing, of course, remains so. The basic problem is combinatorial explosion: a program of size N develops N-to-some-power possible runtime states. Turing himself realized that no general program can tell if another program has truly halted, because the problem is analogous to Gödel's Incompleteness Theorem. Hence, no handy automated tester.
It also doesn't take much work to show that a function of any useful computation must inherently permit the possibility of error. It's a short way of saying that usefulness requires complexity, but complexity increases the number of possible points of failure.
Ironically, getting back to Mr. Ballmer, it was another Microsoft employee, Steve Maguire, who, with his book Writing Solid Code, showed that you can change your development methods to greatly reduce your bug count. The intriguing question then becomes, is there a development process that could eliminate bugs entirely?
The answer is: maybe. I think such a process is possible in theory, but to be useful in practice, it must not slow down a developer to the point where he/she feels straightjacketed. This has been the classic problem with most bug-prevention systems -- they're more trouble than they're worth. And even if a developer did adopt such practices, he might lose too much time to competitors.
And history bears this out: SAP was known for doing excellent enterprise database software, but kept losing market share to more featured (and buggier) competitors. Compugraphic was known for building excellent typesetting equipment but Linotype often beat them by releasing less-stellar products sooner. And the unsettling thing is, neither of these markets are in the consumer field!
What's interesting is that, as software functionality plateaus (think of how MS Word basically reached its peak with version 6), perfection becomes possible. Time previously spent on adding and changing features can now be spent fixing what was written.
Older Notes