Neighbouring rooms on inside maps

[Grum]

I have just checked in a patch that allows us to hide the other rooms on inside map. It works by creating an occupation map of the entire map by checking the height map, tile map, and bounding boxes of 2D and 3D objects, and combining overlapping elements into clusters. Objects and actors not on the same cluster (room) as the yourself will not be shown. It currently doesn't work for particle systems and (other) eye candy yet, I plan to fix this, but finding a test case for it was a bit hard (there's a nice teleporter in the Tarsengaard magic school I can use, though )

 

To test the patch, compile with CLUSTER_INSIDES defined. Things I would really like to know:

*) Does it make map loading noticably slower?

*) Are there any objects removed where they shouldn't?

*) Does it work correctly (especially on rooms at the edge of the map)?

[Placid]

Segfault :\

 

Right after login, on map load (progress bar reaches ~90%) the following happens:

GNU gdb 6.6-debian

Copyright © 2006 Free Software Foundation, Inc.

GDB is free software, covered by the GNU General Public License, and you are

welcome to change it and/or distribute copies of it under certain conditions.

Type "show copying" to see the conditions.

There is absolutely no warranty for GDB. Type "show warranty" for details.

This GDB was configured as "x86_64-linux-gnu"...

Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) run

Starting program: /home/alex/el2_cvs/elc/el.x86.linux.bin

[Thread debugging using libthread_db enabled]

[New Thread 47329219347840 (LWP 7848)]

[New Thread 1082632512 (LWP 8931)]

[New Thread 1091025216 (LWP 8932)]

[Thread 1091025216 (LWP 8932) exited]

[New Thread 1099417920 (LWP 8933)]

B: 2

B: 0.6

B: 1.5

 

Program received signal SIGSEGV, Segmentation fault.

[switching to Thread 47329219347840 (LWP 7848)]

0x00000000004700b5 in load_map (file_name=0x7ffffff30120 "./maps/cont2map8.elm", update_function=0x47c324 <updat_func>) at io/map_io.c:611

611 int x = (int) (objects_list->x_pos / 0.5f);

(gdb) bt full

#0 0x00000000004700b5 in load_map (file_name=0x7ffffff30120 "./maps/cont2map8.elm", update_function=0x47c324 <updat_func>) at io/map_io.c:611

x = 5

y = 237

i = 2667

cur_tile = 39

j = 64

bbox = {bbmin = {189, 189, 0}, bbmax = {192, 192, 0}}

cur_map_header = {file_sig = "elmf", tile_map_x_len = 64, tile_map_y_len = 64, tile_map_offset = 124, height_map_offset = 4220,

obj_3d_struct_len = 144, obj_3d_no = 2668, obj_3d_offset = 151676, obj_2d_struct_len = 128, obj_2d_no = 3354, obj_2d_offset = 535868,

lights_struct_len = 40, lights_no = 45, lights_offset = 965180, dungeon = 0 '\0', res_2 = 0 '\0', res_3 = 0 '\0', res_4 = 0 '\0',

ambient_r = 0, ambient_g = 0, ambient_b = 0, particles_struct_len = 104, particles_no = 20, particles_offset = 966980, reserved_8 = 0,

reserved_9 = 0, reserved_10 = 0, reserved_11 = 0, reserved_12 = 0, reserved_13 = 0, reserved_14 = 0, reserved_15 = 0, reserved_16 = 0,

reserved_17 = 0}

mem_map_header = 0x7ffffff2dc20 "elmf@"

occupied = 0x8ceb010 "�I��\v+"

cur_3d_obj_io = {file_name = "./3dobjects/rocks/rock_huge5.e3d", '\0' <repeats 47 times>, x_pos = -3.86315489, y_pos = 121.734833,

z_pos = 0, x_rot = 0, y_rot = 0, z_rot = 80, self_lit = 0 '\0', blended = 20 '\024', pad = "\000", r = 0, g = 0, b = 0,

reserved = '\0' <repeats 23 times>}

obj_3d_no = 2668

obj_3d_io_size = 144

cur_2d_obj_io = {file_name = "./2dobjects/ground/dirt2_2.2d0", '\0' <repeats 49 times>, x_pos = 185.661362, y_pos = 146.741119,

z_pos = 0.00356347673, x_rot = 0, y_rot = 0, z_rot = -40, reserved = '\0' <repeats 23 times>}

obj_2d_no = 3354

obj_2d_io_size = 128

cur_light_io = {pos_x = 111.09507, pos_y = 180.745667, pos_z = 3, r = 2.59999967, g = 1.70000017, b = 1.70000017,

reserved = '\0' <repeats 15 times>}

lights_no = 45

lights_io_size = 40

cur_particles_io = {file_name = "./particles/fire_big.part", '\0' <repeats 54 times>, x_pos = 175.259567, y_pos = 40.7177734,

z_pos = 0.200000003, reserved = '\0' <repeats 11 times>}

particles_no = 20

particles_io_size = 104

f = (FILE *) 0x8c60780

#1 0x000000000047c36e in el_load_map (file_name=0x7ffffff30120 "./maps/cont2map8.elm") at map.c:153

ret = 11019

#2 0x000000000047c564 in change_map (mapname=0x7ffffff30120 "./maps/cont2map8.elm") at map.c:192

No locals.

#3 0x000000000048217f in process_message_from_server (in_data=0x44fa370 "\a\026", data_length=24) at multiplayer.c:741

mapname = "./maps/cont2map8.elm\000\000\000\000����\v+\000\000\000\000\000\000\000\000\000\000^�ު\v+\000\000F\202�F\000\000\000\0009w\b\000\000\000\000\000@K\021\004\000\000\000\000\033\005ݪ\v+\000\000\026\000\002\000\004", '\0' <repeats 52 times>, " \000@\000\000\000\000\002\000\000\000\000\000\000\000\200\000\000\000\000\000\000\000 �\230�\v+", '\0' <repeats 18 times>, "\210�\216�\v+", '\0' <repeats 16 times>, "@Kp\000\000\000\004\000\000\000@\003���\177\000\000H�\027\004\000\000\000\000�\005\030\004", '\0' <repeats 12 times>, "\001", '\0' <repeats 15 times>...

text_buf = "\220Hi, and welcome to Eternal Lands! If you're new to the game and need help, please read the newbie helper guides on the main website. If you would rather learn by doing, talk to the Tutorial NPC, whic"...

#4 0x000000000047a076 in start_rendering () at main.c:118

message = (message_t *) 0x44fa350

event = {type = 24 '\030', active = {type = 24 '\030', gain = 244 '�', state = 222 '�'}, key = {type = 24 '\030', which = 244 '�',

state = 222 '�', keysym = {scancode = 2 '\002', sym = 2866738270, mod = 11019, unicode = 33350}}, motion = {type = 24 '\030',

which = 244 '�', state = 222 '�', x = 2, y = 0, xrel = -2978, yrel = -21794}, button = {type = 24 '\030', which = 244 '�',

I'm not posting the whole lot because it's huge. Tell me if you need more and i'll post the whole lot.

 

Compile options are:

FEATURES += AFK_FIX # fixes afk messages to count only PM's, and store and count local messages if the option is selected

FEATURES += ALPHA_ACTORS # Enable Alpha Blending of actor models if an alpha blended item is worn

FEATURES += ATI_9200_FIX # flickering fix for ATI 92xx

FEATURES += AUTO_UPDATE # enable minor automatic file updating

FEATURES += CLICKABLE_CONTINENT_MAP # Enables you to click on the continent map to view maps

FEATURES += CLUSTER_INSIDES # Group objects into separate clusters for clipping on inside maps

FEATURES += COUNTERS # enables kill/production/etc counters in the client

FEATURES += CUSTOM_LOOK # allows you to customize your look.

FEATURES += CUSTOM_UPDATE # allows autoupdating of custom look information

FEATURES += EYE_CANDY # (undocumented)

FEATURES += FONTS_FIX # dynamically loads all fonts with the filename in the format font*.bmp, and makes them accessable in the options

FEATURES += FUZZY_PATHS # Makes Tab Map walking not always follow exaclty the same path

FEATURES += IDLE_FIX # Fix for idle animations being stuck in one sequence

FEATURES += MASKING # Allow for item masking on Actors, example, can allow for short sleeves

FEATURES += MINIMAP # Enable the minimap window support (alt+m) (unfinished, but usable)

FEATURES += NEW_ACTOR_ANIMATION # (undocumented)

FEATURES += NEW_TEX # use new texture coordinates for enhanced actors

FEATURES += NOTEPAD # enable in-game notepad

FEATURES += OPTIONS_I18N # make option labels & descriptions translatable

FEATURES += PNG_SCREENSHOT # make screenshots in W3C's PNG format in game, requires libpng

FEATURES += SFX # experimental visual spell effects

FEATURES += SIMPLE_LOD # enable a simplistic distance culling to improve performance

FEATURES += SKY_FPV_CURSOR # Use skybox with clouds/stars/etc, enable first person view, coloured cursors, and other misc changes from Emajekral (Experimental) Extract http://users.on.net/~gingerman/sky_cursor-textures.zip into datadir/textures/

FEATURES += USE_INLINE # enable some optimizations to use inline functions instead of pure function calls

FEATURES += X86_64 # Compile for a computer with 64-bit memory addresses

FEATURES += ZLIB # Enables being able to read gzip compressed files, requires -lzlib/-lz

[Grum]

Drats...

 

I have no idea yet why this happens, will investigate. So far, all I can is that It Woks For Me.

[Florian]

*) Does it make map loading noticably slower?

 

Yes, from "very fast" to "ok".

 

Patch which works great for me on my dual core system (and gcc 4.2 compiler)

Index: io/map_io.c
===================================================================
RCS file: /cvsroot/elc/elc/io/map_io.c,v
retrieving revision 1.5
diff -u -d -p -r1.5 map_io.c
--- io/map_io.c 25 Jul 2007 16:22:09 -0000	  1.5
+++ io/map_io.c 25 Jul 2007 17:22:46 -0000
@@ -22,6 +22,7 @@ static __inline__ void update_occupied_w
{
	int i;

+ #pragma omp parallel for
	for (i = 0; i < tile_map_size_x*tile_map_size_y*6*6; i++)
			if (height_map[i]) occupied[i] = 1;
}
@@ -33,6 +34,7 @@ static __inline__ void update_occupied_w
	int x, y, idx;

	idx = 0;
+ #pragma omp parallel for
	for (y = 0; y < ny; y += 6)
	{
			for (x = 0; x < nx; x += 6, idx++)
@@ -63,6 +65,7 @@ static __inline__ void update_occupied_w
	if (xe > tile_map_size_x*6) xe = tile_map_size_x*6;
	if (ye > tile_map_size_y*6) ye = tile_map_size_y*6;

+ #pragma omp parallel for
	for (y = ys; y < ye; y++)
	{
			for (x = xs; x < xe; x++)
@@ -83,6 +86,7 @@ static __inline__ void update_occupied_w
	if (!obj)
			return;

+ #pragma omp parallel for
	for (i = 0; i < obj->material_no; i++)
	{
			box.bbmin[X] = obj->materials[i].min_x;
@@ -157,6 +161,7 @@ static void compute_clusters (const char
			}
	}

+ #pragma omp parallel for
	for (y = 1; y < ny; y++)
	{
			for (x = 0; x < nx; x++, idx++)
@@ -192,6 +197,7 @@ static void compute_clusters (const char
	}

	cnr = 0;
+ #pragma omp parallel for
	for (ic = 1; ic < nr_clusters; ic++)
	{
			if (cluster_idx[ic] == ic)
@@ -199,7 +205,8 @@ static void compute_clusters (const char
			else
					cluster_idx[ic] = cluster_idx[cluster_idx[ic]];
	}
-
+ 
+ #pragma omp parallel for
	for (idx = 0; idx < nx*ny; idx++)
			clusters[idx] = cluster_idx[clusters[idx]];
}

 

Those pragmas just don't do anything on compilers w/o OpenMP support. (with gcc user -fopenmp)

 

w/o OpenMP i can actually read that 3d objects are loaded, with the OpenMP the loading process is too fast for me to be able to read what's loaded.

 

see http://en.wikipedia.org/wiki/OpenMP for more info on OpenMP.

[trollson]

The OpenMP pragmas are the way to go -- if you know what you are doing

 

If segmenting the map is taking too long, can the results be cached the first time (to file) and only recalculated if the map file is newer than the cached segmentation file (stat)?

[Florian]

*) Are there any objects removed where they shouldn't?

*) Does it work correctly (especially on rooms at the edge of the map)?

Which maps would be good to check that? C1 -> C2 via WS seems to look as before.

 

The OpenMP pragmas are the way to go -- if you know what you are doing

 

Haha, know what I'm doing, good one

 

This looked like pretty stupid number crunching to me, so OpenMP should speed it up if thread creation etc. overhead is not too much slowdown compared to the speed gain.

 

Crash when "loading particles" of Ida map:

0   com.yourcompany.el_osx   	0x0008a8cf load_map + 5363 (map_io.c:619)
1   com.yourcompany.el_osx   	0x0009fc84 el_load_map + 218 (map.c:153)
2   com.yourcompany.el_osx   	0x000a03c5 change_map + 109 (map.c:192)
3   com.yourcompany.el_osx   	0x000a84d2 process_message_from_server + 9232 (multiplayer.c:741)
4   com.yourcompany.el_osx   	0x0009c12f start_rendering + 611 (main.c:119)
5   com.yourcompany.el_osx   	0x0009c1cd SDL_main + 80 (main.c:264)

 

load_map (file_name=0xbfffea98 "./maps/cont2map1.elm", update_function=0x9f748 <updat_func>) at io/map_io.c:619
619							 int y = (int) (objects_list[i]->y_pos / 0.5f);
Current language:  auto; currently c

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000058
load_map (file_name=0xbfffea98 "./maps/cont2map1.elm", update_function=0x9f748 <updat_func>) at io/map_io.c:619
619							 int y = (int) (objects_list[i]->y_pos / 0.5f);
(gdb) bt
#0  load_map (file_name=0xbfffea98 "./maps/cont2map1.elm", update_function=0x9f748 <updat_func>) at io/map_io.c:619
#1  0x0009fc84 in el_load_map (file_name=0xbfffea98 "./maps/cont2map1.elm") at map.c:153
#2  0x000a03c5 in change_map (mapname=0xbfffea98 "./maps/cont2map1.elm") at map.c:192
#3  0x000a84d2 in process_message_from_server (in_data=0x59dd650 "\a\026", data_length=24) at multiplayer.c:741
#4  0x0009c12f in start_rendering () at main.c:118
#5  0x0009c1cd in SDL_main (argc=1, argv=0x5906f50) at main.c:254

 

Same crash for EVTR (as reported above already).

 

If segmenting the map is taking too long, can the results be cached the first time (to file) and only recalculated if the map file is newer than the cached segmentation file (stat)?

 

Well, why not go a step further and compute all clusters at startup? Multithreaded of course. Since the new file I/O and gzip'ed everything the client starts in like 2 seconds on my Mac, Most of the time until login takes loading actor definitions, can't read anything else which is loaded before login.

Edited July 25, 2007 by Florian

[Grum]

We could perhaps add a cluster section to the map format, and store the information in the map itself. In principle nothing would even have to change on the server.

 

EDIT: still puzzled by the crashes...

Edited July 25, 2007 by Grum

[Florian]

NCNC

 

with OpenMP for the for (i = 0; i < MAX_OBJ_2D; i++) loop

 

tload_map.omp_fn.1 (.omp_data_i=0x0) at io/map_io.c:621
621							 int y = (int) (objects_list[i]->y_pos / 0.5f);
Current language:  auto; currently c

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000058
load_map.omp_fn.1 (.omp_data_i=0x0) at io/map_io.c:621
621							 int y = (int) (objects_list[i]->y_pos / 0.5f);
(gdb) bt
#0  load_map.omp_fn.1 (.omp_data_i=0x0) at io/map_io.c:621
#1  0x00089f55 in load_map (file_name=0xbfffebd8 "./maps/cave3.elm", update_function=0x9f750 <updat_func>) at io/map_io.c:232
#2  0x0009fc8c in el_load_map (file_name=0xbfffebd8 "./maps/cave3.elm") at map.c:153
#3  0x000a03cd in change_map (mapname=0xbfffebd8 "./maps/cave3.elm") at map.c:192
#4  0x000a84da in process_message_from_server (in_data=0x18b30950 "\a\022", data_length=20) at multiplayer.c:741
#5  0x0009c137 in start_rendering () at main.c:118
#6  0x0009c1d5 in SDL_main (argc=1, argv=0x5906f50) at main.c:254

 

TG Crypt:

#0  0x1694ba68 in ?? ()
#1  0x12192020 in ?? ()
Cannot access memory at address 0x1
Previous frame inner to this frame (corrupt stack?)

 

TG Crypt: (sorry, only CrashReporter stack trace, gdb can't get one ...)

0   <<00000000>> 	0x16949668 0 + 378836584
1   GLEngine				 	0x11dd7199 gleDrawArraysOrElements_Core + 157
2   GLEngine				 	0x11e5beef gleDrawArraysOrElements_VBO_Exec + 853
3   libGL.dylib				  0x92b23575 glDrawArrays + 97
4   com.yourcompany.el_osx   	0x000e6745 draw_terrain_quad_tiles + 300 (tile_map.c:142)
5   com.yourcompany.el_osx   	0x000e6af1 draw_tile_map + 830 (tile_map.c:268)
6   com.yourcompany.el_osx   	0x0006c89e display_game_handler + 802 (gamewin.c:943)
7   com.yourcompany.el_osx   	0x0005a4ef draw_window + 901 (elwindows.c:1064)
8   com.yourcompany.el_osx   	0x0005ac15 display_windows + 184 (elwindows.c:1231)
9   com.yourcompany.el_osx   	0x0004b3da draw_scene + 137 (draw_scene.c:121)
10  com.yourcompany.el_osx   	0x0009c1d0 start_rendering + 657 (main.c:132)
11  com.yourcompany.el_osx   	0x0009c240 SDL_main + 80 (main.c:264)

Edited July 25, 2007 by Florian

[Placid]

Grum, I logged out in EVTR, so the crash I was receiving could be just the same as Florian's. I'll recompile and logout somewhere else.

[Grum]

Found a bug and fixed it. Unfortunately I have to go for the evening, but bug report are still very welcome

[Florian]

Found a bug and fixed it.

I'd call that a typical copy&paste bug ...

[Grum]

You're not supposed to check the commits and see my stupidities

 

 

j/k of course. Yes, copy&paste error. I hope this fixes the crashes?

[ttlanhil]

Well, I haven't given it an exhaustive test, but what I've tried says that it's accurate, but slow.

How hard would it be to only calculate the cluster the player is in at first, and do the rest in the background?

[Puntif]

Have you tried the house next to PV storage? It has rooms separated by doors/walls.

[Grum]

Well, I haven't given it an exhaustive test, but what I've tried says that it's accurate, but slow.

How hard would it be to only calculate the cluster the player is in at first, and do the rest in the background?

Hard.

 

As for it being slow: I suppose only map loading is slow right? (i don't really notice, the hard disk on my laptop is so slow that it might as well be hand-driven). My idea was to extend the map format to include the cluster map, and not compute them at load time (or only when a cluster map isn't present). That should speed things up to being negligible.

 

EDIT: update: eye candy effects are now hidden as well (thanks Karen).

EDIT 2: Many rooms in the tarsengaard magic school are surrounded not by null tiles, but ordinary black tiles. Some of them have so many black tiles that they connect two or more rooms, so it might be possible that you still see more than one room there. If you use the sky box, you can easily spot the black tiles and see what I mean (well, at least if you don't have the corresponding textures, like me )

Edited July 29, 2007 by Grum

[Florian]

Have you tried the house next to PV storage? It has rooms separated by doors/walls.

Works.

[Grum]

Have you tried the house next to PV storage? It has rooms separated by doors/walls.

Works.

No, it doesn't. Looks like here too, the rooms aren't separated by null tiles, but by black ones. So the entire map becomes in fact one big cluster.

 

I wonder if we should fix the maps, or if I should simply test for black tiles as well.

[ttlanhil]

I wonder if we should fix the maps, or if I should simply test for black tiles as well.

Well, pretending black tiles are null would make it so you can't just click the other end of a blackmaze

I'm not sure if making it so you can't see a room on the other end is a good thing or not... Heck, I'm not even sure if this change would make any objects in the blackmaze no longer be shown, since they're between rooms...

[Grum]

I wonder if we should fix the maps, or if I should simply test for black tiles as well.

Well, pretending black tiles are null would make it so you can't just click the other end of a blackmaze

I'm not sure if making it so you can't see a room on the other end is a good thing or not... Heck, I'm not even sure if this change would make any objects in the blackmaze no longer be shown, since they're between rooms...

Ehm...yeah, good point. I realize the black tiles are there for a reason but they're abused a lost on certain maps. Well, guess we'll have to badger Roja into having them fixed then, if she wants this patch to work

 

EDIT: ehm...not trying to invalidate the point, but the other side of a maze would still be connected by the height map, no? So it would still belong to the same cluster.

Edited July 29, 2007 by Grum

[ttlanhil]

EDIT: ehm...not trying to invalidate the point, but the other side of a maze would still be connected by the height map, no? So it would still belong to the same cluster.

Oh, completely true. Didn't consider that. Although you can still lose 3D objects outside a room.

 

Ooh, wait, I think I remember a case where you have to TPTR over an unwalkable area, not just blackmaze. I guess all maps where that's intended will have to have a single walkable tile every now and then, just frequently enough to keep the parts in the same cluster (Ugg, eh? )

[Grum]

EDIT: ehm...not trying to invalidate the point, but the other side of a maze would still be connected by the height map, no? So it would still belong to the same cluster.

Oh, completely true. Didn't consider that. Although you can still lose 3D objects outside a room.

 

Ooh, wait, I think I remember a case where you have to TPTR over an unwalkable area, not just blackmaze. I guess all maps where that's intended will have to have a single walkable tile every now and then, just frequently enough to keep the parts in the same cluster (Ugg, eh? )

Depends on what's in between. At the moment two cluster are connected when

a) there's a walkable path between them

they're connected by ground tiles

c) there's a 3d object overlapping (or directly neighbouring) them both

d) there's a 2d object overlapping (or directly neighbouring) them both

e) any combination of the above

 

The only thing that would get us into trouble would be if you's have to jump across a real void, with absolutely nothing between the two. For that, black tiles would actually be useful.

[Florian]

Have you tried the house next to PV storage?

Works.

No, it doesn't.

Well, works in the sense of "does not cut off rooms which should be there" ...

[Roja]

This seems really great Grum if it works! I finally got to try it out, and I'm going to play the game with it for a while to see what bugs I find.

 

I did find one thing, it seems like you don't have ground tiles included in the occlusion?

 

 

And as a side note, not sure if this is related to this or not(probably not)...here you see blue from water being "close by", but it's really not close by. In the map editor, and older clients that blue would not show up so far away from water tiles. Here it is showing up all over the map it looks like. This is in fact a BIG problem for MANY areas.

Edit: Looks like ALL inside maps, regardless of there being water or not, have this blue.

[Grum]

This seems really great Grum if it works! I finally got to try it out, and I'm going to play the game with it for a while to see what bugs I find.

 

I did find one thing, it seems like you don't have ground tiles included in the occlusion?

Hmm, strange, they should be. Which map is that you're standing on?

And as a side note, not sure if this is related to this or not(probably not)...here you see blue from water being "close by", but it's really not close by. In the map editor, and older clients that blue would not show up so far away from water tiles. Here it is showing up all over the map it looks like. This is in fact a BIG problem for MANY areas.

Edit: Looks like ALL inside maps, regardless of there being water or not, have this blue.

That's even stranger, because I haven't seen that happen yet and the cluster code shouldn't affect how the ground tiles are displayed, just hide those that aren't connected. I'll go over my modifications to the code to check (I did in fact make a mistake while developing the code, so I won't rule out other errors).

 

If anyone else compiling with -DCLUSTER_INSIDES sees this behaviour, please let me know.

 

EDIT: may have found something, but need to check. Not before the weekend, I'm afraid

Edited August 22, 2007 by Grum

[Grum]

Okay, the ability to read the cluster maps from file is now built in the client (support for writing those maps will be added to the map editor later). A new and hopefully improved checkmap script is available from http://ghnet.nl/~ge/downloads/checkmap.py , which adds the ability to convert your maps to include the clusters. Usage has changed a bit from previous versions:

Usage: ./checkmap.py [options] file [ file ... ]
where options is one or more of the following:
-w, --write	 : write a new map if it was changed
-h, --heightmap : show the height map
-t, --tilemap   : show the tile map
-2, --2dobjects : show bounding boxes of 2D objects
-3, --3dobjects : show bounding boxes of 3D objects
-c, --clusters  : show visibility clusters
--no-cluster-map		: Don't write the cluster map to file
-iVERSION, --input=VERSION	  : force input map to be read as v.VERSION map
-oVERSION, --output=VERSION	 : write new maps with version VERSION

The only two map version support atm are 0 (the current version), and 1, which adds the new light format and (unless --no-cluster-map is specified) the cluster maps. So to automatically convert all your maps, you can simply

./checkmap.py -o1 -w /path/to/EL/maps/*.elm

Note that this is a not very optimized Python script, and computing the clusters is a fair amount of work, so the conversion of all maps may take a while.

 

Florian (and all other people who found that on the fly computation of the cluster maps was too slow), can you try converting your maps and check if the current version is faster? If all's well, reading the clusters should add a negligible amount of time to the map loading time, so please let me know if that's true. All other comments/bug reports/etc. are of course always welcome too.

 

Roja, still working on your bug report, I've managed to reproduce the blue ground, will try to find what's causing it.