Older blog entries for ingvar (starting at number 178)

Nopes, no mailing lists. I might be able to recover the subscriber data for uk-lispers and small-cl-src. I shall see about the archived posts.

Now, that was interesting.

Unplug the ATA controller and the CD-ROM is bootable-from. With a bootable CD-ROM, we can (temporarily) get a network module up and with a network module, we can by sheer force of apt get a new kernel down and with a new kernel, we can then shove the ATA controller back in place, creating vastly more diskspace than before (imagine a decimal order of magnitude), making for lots of nicely chunky free space.

Then, of course, comes the fun of juggling data around and coalese stuff into less unsuitable chunking. Should've gone for LVM, shouldn't I?

Anyway, that means all bar lists should be back on-line and I should hopefully have time to sort them through this week.

Ahahaha. Haha. Hah. Well, that was "fun", having most (if not all) modules eaten by an interesting combination of build tools and "make modules_install". Hopefully everything should be back on track soon.

Web sites up. Mailing lists not up.

New chassis in place. No data transferred over. In short, "things are still not working". Now that I have enough computer for emergency needs, I can look at data transferage.

Dead UPS - Fixed. Failing IDE drive - Not fixed. Dead network card - Not fixed.

Hoppefully, it will be fixed this evening. Until then, src.hexapodia.net will be off-line. So will the uk-lispers and small-cl-src lists. Once things are back, I intend to package up the uk-lispers archive and subscriber list and hand it to Nick Levine.

As some people may have noticed, *.hexapodia.net is down (dud powersupply, looks like).

As some others may have noticed, I am more-or-less in comms withdrawal, for a variety of reasons. Communications will be kept short. Emails may get read but will probably not be answered.

Hermitage in modern society is suprisingly hard work.

The last few weeks, I have spent almost 15 hours of coding towards my latest project (it's not anywhere near done, but it's a basic tank game where you zoom around a grid, and (hopefully) shoot at geometric forms). It's now at a stage where the constant move works and there's some steering (that's a definite advantage compared with the state-of-play when I sat down for this session, feeling a bit odd not coding too-early in the morning).

I have, today, fixed a couple of clipping bugs and optimised the clipping heavily (I start with clipping in 3D, in "camera space", to the view frustrum; I then clip in screen-space, using essentially the Bresenham line-drawing algorithm to fine-nudge things to within screen-space). I use the clipping for two distinct applications, one is in the "draw the grid" that spawned the 3D clipping and the other is in the "draw a geometric solid". Right now, there's only a few things being rendered in the screen update. A new grid (obviously), a radar screen, an aiming reticule and any geometric solid that happens to be in view.

Right now, I'm not using any 3D acceleration, instead preferring to do everything in code I've written, running on the main CPU. It seems my elderly AMD K6 is sufficient to provide a mostly jerk-free animation (though I am cheating and only doing 10 updates per second), even with apache, squid and friends running. "Go, go 233 MHz power!".

As usual, all of the code is written in CL, using CLX for the output layer. Next is writing more utility functions for creating solids (the code currently knows of triangular-base pyramids and six-sided solids with four-corner sides). I use what I thought a neat solution for handling the geometric objects.

Each type of geometric shape is a class. When they're defined (using a solid-defining macro), I say how many corners they have, provide an exhaustive list of their sides, mapping each corner of a side to one corner of the solid, then say how many of the sides can be displayed. This means I will need to order the sides to bottoms and (possibly) tops won't get listed, since there's no change in height for the camera. All vertex and side storage is done in vectors, for reasons that will, I guess become apparent.

The shape-defining macro also defines a whole bunch of methods. One method for each side, specialised on the shape and the number of the side. However, the base "draw solid on screen" routine is even simpler.

(defmethod draw-shape ((shape volume))
  (let ((max (min (to-show shape) (length (sides shape)))))
    (update-cam-vertexes shape)
    (let ((sides (sort (loop for n from 0 below max
			     append (find-side shape n))
		       #'>
		       :key 'y-average)))
      (loop for side in sides
	   do (draw-shape side)))))

This first computes a camera-space value for each vertex and caches it. It then builds a list of sides for the solid, sorted with the farthest first (I, possibly badly, chose a right-hand coordinate system with the Y axis pointing straight out of the camera), then all the individual sides are drawn (by computing a list of all the corners in camera space and first doing an XLIB:DRAW-LINES with a "fill in white" option and then doing it again with black, now only drawing lines.

There's some culling in the side DRAW-SHAPE method (if none of the corners are visible, we're done; if all the corners are visible, we can skip clipping; otherwise, build a list of corners where there is at least one clipping). It seems pretty quick now, though tere's no "100s of objects" and we'll see what happens then.

"Oooops!". I just realised I should probably re-order the list of objects to display instead of hoping to blind luck that things are drawn from far away and then closer.

Just in case someone has a problem downloading stuff from my source repository... I use a fairly agressive method for dealing with assorted scanning to my machine. The scanning IP (or netblock, if no reverse DNS or incorrect reverse DNS is available) gets routed to 127.0.0.1. At the moment, there's 138 entries matching this.

I haven't had a chance to look at lispg since before New Year's Eve, since there was a bit of a flu, followed by some floor-fixing, followed by some well-needed relaxation (when replacing some carpet with laminate flooring ends up with replacing floor joists, it takes time).

Other, long-range, coding is proceeding at some sort of pace.

So, an approximation of development time. Apparently, I started the coding on 2005-11-06. I usually code for max 1h a day (between 06:00 and 07:30, interspersed with assorted web browsing, solitaire-type games, morning necessities and cat-feeding), 5 days a week. This gives us an approximate 5h per week and from then to now is about 9 weeks. However, for at least two weeks of those, I did no coding. So the code as-is represents a bit short of a man-week of work. I think my optimistic estimate of "about a man-week" isn't too bad, for an off-the-cuff guess.

169 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!