Unmap Canvas Items

[Kirsle]

I'm programming a Perl Tk game that uses a scrolled canvas as the visible area of the game. It's a tilebased maze game with 32x32 pixel tiles (think Chip's Challenge if you remember it).

The map data is a scalar, and it kind of looks like this:

##:##:##:##
##:  :  :##
##:  :  :##
##:##:##:##

The columns are split horizontally at the colon, and the rows are split at the line break.

In each cell are two symbols, the first one is the tile which appears on top, and below is the tile which is hidden underneath the first. In this case, # is a wall and a space is a floor tile.

I decided that a game map should be 70x70 tiles large, or with 4900 tiles, which each set on top of 4900 hidden tiles beneath them. So we're looking at 9800 canvas items that need to be drawn for any one map in the game.

This works fine so far. The items can all be drawn in a couple of seconds and the game can go from there.

The problem is with closing out of the program. On Perl's exit command, it has to delete everything in the main window before shutting down, which freezes the window for quite some time.

I tried a Destroy handler to make it destroy the canvas first, but it gives the same result. The canvas has to destroy all its items before being destroyed itself.

The only solution I could come up with to make the shutting down process go easier is to actually go through and delete each item from the canvas, one at a time, and updating the main window between each. So visually, you see each tile disappear one at a time down the line. This will stop any confusion by the end user thinking the program is completely frozen when it's not.

This still took bloody ages though, I estimate it took at least a full minute for the canvas to be fully cleared, during which most of the time the CPU usage was up to 100% until the canvas was about 3/4ths cleared, at which time the deletion also sped up.

The other solution was to shrink the map size to 40x40 tiles rather than 70x70 which allowed the program to complete this process much sooner.

So the question is, is there any way to destroy all items on a canvas in a quick and easy way? If 9800 items can be drawn in a second, why can't they be destroyed in a second too?

Any help would be appreciated.

 

[icrf]

An interresting problem. How much memory does the game take up when it's loaded? I'm curious if the first 75% of the items are being removed from virtual memory and the last 25% are from memory, and that's why they're faster.

Otherwise, if it's just overhead from Perl/Tk for having 9800 child items, can you group them somehow? Have 10x10 tiles on a master tile or something? Maybe tile canvases of tiles on the canvas?

- Andrew
Text::Highlight - A language-neutral syntax highlighting module in Perl
also on SourceForge including demo

 

[Kirsle]

When the program opens (but doesn't load the map), it takes up 13.4 K of memory (with a value of 00 under the CPU tab). This is Windows XP by the way.

When the map is loaded, the memory usage is 15 K, still with 00 CPU.

When the program is in the process of erasing tiles (on a 40x40 map) one by one, as I adjusted them to just before posting this thread, the CPU goes up to 80 for the process.

Then it was doing this for the 70x70 tile map, the CPU would spike to 100 for the process and remain there for some time. The tiles would delete approximately once every .5 seconds or so. Towards the end, approximately 3/4 of the entire process, the tiles would start disappearing two or three per second which would constantly increase as the CPU usage dropped and there were fewer tiles left to erase.

So as I mentioned in my first post, it was no problem once the map was loaded. The program could continue to run efficiently as there wasn't any considerable amount of memory consumption. In the 9800 tiles, it would also include things such as monsters and items on the tiles to, which would respectively be destroyed as they interacted with other tiles (the player picking up a key, for example). So there'd be a maximum of 9800 canvas items at any time.

So the CPU was only a problem when a mass deletion of canvas items was attempted.