Older blog entries for ingvar (starting at number 139)

Success, of sorts. After fiddling around and changing the animation code, I no longer get PolyPoint async errors. Alas, I still ain't getting what I would've expected, graphics-wise. Also, the clip-mask seems to be completely blank, something I certainly did not expect. I shall try to hook in suitable data extractions in the not-too-distant future and after that I fear it might be time to hook in protocol analysis and see what actually gets passed to/from X11 (if everything looks fine up until that point, I shall have to move my expected-bug-author from myself to someone else).

Gah. Gahgahgah. I was reading the error message the wrong way. No wonder it wasn't making *any* sense. Now I'm just wondering why a CopyArea call manages to provoke a PolyPoint error...

On the good side, my game-to-be loads finer in Lispworks/Win32 and SBCL/Linux.

On the bad side, they're exhibiting scarily similar errors when displaying the animated player thingbob, namely "the clip-mask pixmap ain't doing its job" (in subtly different ways, though). I am hoping, but rather expecting, that this is because tehre's (IIRC) a possibility that it's trying to use a fixnum as the tiling component (the clipmask seems to be different from run to run, see).

I fear me I shall have to subscribe to another mailing list.

Edit: No, clipmasks are either None or a pixmask (there might, possibly, be legacy code to support a sequence of Rectangles, but I can't trivially spot that in the X11 Core Protocol reference on my bed).

On one of the lisp mailing lists I read, there has been a bit of a discussion regarding the lisp-1/lisp-2 divide. That had me think. It had me think far back, even.

When I started hobby-coding in lisp, way back in the dark ages of the late 80's, I started out using XLisp 1.7. That was a lisp-1 and completely interpreted, to boot. It also had a CL-style macro facility. It worked fairly well, all things considered. Then I met Scheme, another lisp-1. So far, so good.

As was, uni demanded I wrote CL for one of my courses (oddly enough, the first proper programming course), so I grudgingly decided to conquer the scariness taht was a lisp-2, thinking I would end up with no end of compile failures, due to, well, teh sheer lisp-2-ness and having (at that point) 6-8 years of lisp-1 firmly lodged in my spine.

Guess what? After the first 15 minutes, it hasn't been a problem for the last 10 years. Admittedly, I didn't have scads of legacy code that Needed Porting Now, so it may well be different for other people.

Not sure if going from lisp-2 to lisp-1 is going to be as painless, though. Thinking back, I feel that lisp-1 needs (slightly) more naming discipline.

As mentioned elsewhere, I have written a quick essay on one method for making CGI scripts somewhat more resistant to external probing. No one has commented about how mislead I am, so there might (just) be a kernel of sense in there.

Oh, joy...

I am getting "match errors" (whatever those are) when talking X. I am, vaguely, suspecting strange interaction between graphics contexts, pixmaps and windows, but...

Well, well, well. I now have a player image (it's still on the uglier side of ugly and it seems I managed to screw up diagonal translations) and it moves around and (almost) does the right thing when changing direction. I am afraid I'll have to use a suitable clip mask, though, since my memory of "how does this work" from previous experimentations didn't seem to work too well in conjunction with copy-area. Hopefully clip-masks in a gcontexts will help there, though, otherwise, I shall just have to be somewhat creative.

On another note, it seems as if metaur has had an interesting last while

Doodling on my latest little hobby hack, a fairly standard scrolling "walk the levels, shoot things and grab stuff" game. It's been done before, so it's nothing remotely "cool" about it, as it were, but I was wondering if Common Lisp and CLX is fast enough to build a game that is pleasantly playable on my old AMD K6 (233 MHz, IIRC) and based on my very simple "scroll the playfield across the view window" it seems to be decently fast.

(loop for *view-x* from 0 to 128 
      do (progn 
           (draw *game-window*)
           (xlib:display-force-output *display*)))

As a side-note, those who may recall me having wondered about reading PNG files now know what prompted that. Alas, I needed edited graphics faster than I could wrap my head around making Salza or Xach's PNG generation library actually read things from disk, so for now I am using XPM files. They're not brilliant, but at a 64x64 tile size, they're not hazardously large and I should, hopefully, be able to convert them to a sensible format as and when that's needed.

Just noticed one of the things I imagine causes problem for people when programming X (at least "fairly raw X"). The colour handling is, at best, curious. Want to draw anything? Pull out a handy "Graphics Context" (with foreground, background, possibly a font and a drawing policy). These can either be re-used (and if changed, requires a round-trip to the X server) or allocated for an as-needd usage policy.

Of course, there's the added problem of "how many bits of colour do I have" and "Are my colours snarfed from a colormap or are they ``straight to screen´´?". I think the right answer is either "Use a toolkit" or "Make your own adapter code". I, for some reason, seem to go for the latter option.

Micro-tool now packaged (not ASDF-Install-able yet, though).

Current feature-list:

1. Handles documents included by \input and \include
2. Only further processes documents matching *.tex
3. Can parse \epsfig

On "possible future features" is "handle BibTeX files".

Available here