[Loom-devel] [raph@acm.org: Re: Isometric tile engine, using the Canvas.]

[Joakim Ziegler]

Here's Raph's reply to the mail I sent asking for tips on the tile engine. It
seems my suspicions were correct, Gdk-pixbuf *should* be very memory
economical.

----- Forwarded message from Raph Levien <raph at acm.org> -----

Delivered-To: joakim at styx.net
Date: Thu, 03 Feb 2000 03:50:35 -0800
From: Raph Levien <raph at acm.org>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5-15 i686)
X-Accept-Language: en
To: Joakim Ziegler <joakim at styx.net>
Subject: Re: Isometric tile engine, using the Canvas.

Joakim Ziegler wrote:
> 
> Iain and I have been looking at making an isometric tile engine for GNOME the
> last few days. It'd be very useful for strategy and boardgames, for instance
> (we're thinking about porting NetHack over when the code is stable enough).
> 
> Now, the tile model would be multilayered, with a list of graphics bits with
> alpha channels per tile, and we render from back to front, top to bottom
> (layering-wise). This model lets us do just about anything we want with
> iso3D. However, some tests Iain wrote using gdk-pixbuf canvas items, one per
> tile (pointing to two unique tile pixmaps) made us rethink using a single
> canvas item per tile (actually several per tile, one per layer). Even 100x100
> tiles was very slow on my midrange box, and with 1000x1000 tiles, Iain's X
> server died. :) Iain's tiny test program is at
> http://www.avmaria.com/iso.tar.gz , by the way.
> 
> So we're considering several possibilities for how to implement this. One
> idea was to cluster tiles in, for instance, 10x10 tile chunks, and make
> canvas items to hold these. That model makes it a bit trickier to do our
> fine-grained z-level model properly when rendering, though (basically it's
> only good for the bottommost tiles, all sorts of terrain and scenery and
> whatnot still needs to be separate items.
> 
> So, basically, we're wondering what your thoughts on the subject are. Is it
> normal for a canvas with a large amount of gdk-pixbuf canvas items on it to
> scroll slow and use lots of X server RAM, or are we doing something wrong?
> Does the chunking scheme sound like a good idea to you, or would it be better
> to write separate canvas items to hold tiles that do things in a different
> way from the gdk-pixbuf ones? It seems to me that the main problem is the way
> gdk-pixbuf canvas items that aren't inside the visible at the moment are
> cached (at least for the ram use problem), but I'm not sure.
> 
> All tips, thoughts and ideas would be gratefully received.

Sounds interesting. I'm at Linux Expo Paris right now so don't have the
time to think about this in detail.

Gdk-pixbuf should _not_ be using large amounts of server ram (maybe a
few hundred K tops). I'll take a look at the test program and see if I
can identify the problem.

My queue of things to do has lots of packet loss, so if you don't hear
back from me, please retransmit.

Raph

----- End forwarded message -----

-- 
Joakim Ziegler - styx research director - joakim at styx.net
FIX sysop - FIXmud admin - FIDEL & Conglomerate developer