Older blog entries for ingvar (starting at number 198)

1 Aug 2006 (updated 1 Aug 2006 at 09:28 UTC) »

Of course, crhodes pointed out that there were some FATAL flaws in my macros. Firstly, I managed to faff decf-if-not-negative (I used > instead of >=). secondly, it suffers from Multiple Evaluation.

(defun decrease-if-positive (base n)
  (if (> base 0)
      (- base n)
    base))

(defun decrease-if-not-negative (base n) (if (>= base 0) (- base n) base))

(define-modify-macro decf-if-positive (&optional (delta 1)) decrease-if-positive) (define-modify-macro decf-if-not-negative (&optional (delta 1)) decrease-if-not-negative)

This morning was definitely lacking in the planned book database recovery (sigh). However, there is now "lives", the UI loop terminates as the number of lives spare hit -1, there's a compass rose that seems to behave as it should and there is a visible warning when an enemy tank fires a missile. Still no REAL handling of enemy tank collision (this should I feel, cause s loss-of-life). There is also a handy utility macro or two (hiding in globals.lisp):

(defmacro decf-if-positive (form &optional (step 1))
  (let ((cur (gensym "CUR")))
    `(let ((,cur ,form))
       (if (> ,cur 0)
	   (setf ,form (- ,cur ,step))
	 ,cur))))

(defmacro decf-if-not-negative (form &optional (step 1)) (let ((cur (gensym "CUR"))) `(let ((,cur ,form)) (if (> ,cur 0) (setf ,form (- ,cur ,step)) ,cur))))

Handling of lives is under way.

Tank AI no longer computes FOV as if it was at (0.0; 0.0) but at the actual tank position (this, no messing, improved the aiming and stuff a LOT).

We now handle collisions between missiles and the camera (read "player") by simply deducting a life. Drawing of small tanks in the infobar is in progress (build a list of points off-set from X and Y fed in as parameters, feed to XLIB:DRAW-LINES, with filling).

There might, just might, be a 0.3 ready tomorrow.

So, the AI is somewhat les sstupid, things no longer shoot themselves, annoying "why are enemy tanks not displayed?" bug has been fixed, there is now automatic replenishment of tanks and landscape as it gets shot up.

I think that means "time to link!". So, without further ado, I give you Pantzer, a cheesy wire-frame "shoot tanks" game. NB, at the moment, you can't be killed. That's, admittedly, a bug. But it's a cool bug. It'll be fixed when I've decided on such pesky things as "how many lives".

Oh, to start, load the system, then run (net.hexapodia.pantzer:ui-loop) (if you want an inter-frame delay that's longer than the default 0.1 seconds, give the delay as an optional argument). Oh, yes, make sure to have CLX around, otherwise the display won't work.

Smarts improved, I think. Alas, the tanks are now amusingly-stupid enough to shoot themselves (this is, as they say, a BUG; the missile materialises within the tank instead of in front of the tank). Tanks no longer share a missile-firing barrel with the player (that was another bug, as they say).

Alas, last re-compile finished just about in time for me to kiss my wife good-morning and amble in the general direction of work.

The enemy tanks now have some smarts (or should I say "stupids"?). They turn and twist and occasionally shoot. Unfortunately, they are displaying a preference for driving away from the player. This is, as they say, suboptimal.

Back to doodling on Pantzer (a "drive a tank through wire-frame landscape" game). I now have enemy tanks. They're apallingly stupid (they know how to move forward in a straight line). Hopefully, I shall be alert enough tomorrow morning to make them a wee bit smarter (essentially, "if you can see player, turn slightly to get a better angle and move quickly; otherwise, turn randomly, preferring to stick with the last used angle and move slower"). This should be slightly fair, even though the player moves at a fixed speed.

THings seems to have settled, if you fancy playing with pre-release code, the python server and client code is available and so is the Common Lisp client library. The latter is ASDF-packaged and will be wanting a serving of trivial-sockets on the side.

o, I've been prodding code. As a matter of fact, I have (mostly) written a client library for creek, in Common Lisp. It was, not ioverly surprising, quicker to write than the Python library. Part of that is down to "I am more used to it", but parts is the ability to skip verbiage.

Most of the protocol glue is handled liek so:

(defmacro defprotofun (namedes (&rest args) &optional doc)
  (let ((fname (if (symbolp namedes) namedes (car namedes)))
        (pname (if (symbolp namedes) namedes (cadr namedes))))
    `(defun ,fname ,args
       ,@(if doc (list doc))
       (send (list ',pname ,@args))
       (parse (creek-read *server-stream*)))))

(defprotofun take (item)) (defprotofun (list-maps listmaps) () "Return all maps defined on the server")

This is because the protocol is designed to be human-friendly and quite close to what you'd do in code, so the "trivial" functions are (essentially) "build a protocol string, ship to server, read response, parse response" (object creation and object cacheing is part of the parsing stage).

After I wrote the first two glue functions, i noticed that they were, effectively, identical and thouhg "Ah, macro time!". I then realised that a few of the protocol command were somewhat unlispish, so the macro got modified to accomodate a (possible) split between "lisp function name" and "protocol call". Then I added the option to add doc-strings.

As soon as the server is slightly more ready and a bit more tested with both client libraries and test-installed, there will be tarballs (one for the python stuff and a signed package suitable for asdf-install).

Apparently, I've been a bit lax in making known what things are and have so, inadvisedly, caused confusion.

The latest hack is "creek", a client/server workflow thingie back-ending ontyo a MySQL database (changing it from MySQL to something else that is (a) supported by Python and (b) has DictCursors should be fairly simple, I am, as far as I know, staying WELL within the standard SQL syntax).

Main reason why naming it might've slipped my mind is taht I've been doodling on it back and forth for the last three years (most coding has been done within the last 3 months, with some coding being done late 2003 and early 2004, most notably the reader for the network protocol).

189 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!