From DoomWiki.org

m (Xymph moved page User:Xymph/Sandbox to User:Xymph/Map views: Preserve on its own path so sandbox can be used for future... sandboxing)
(Add more discussion)
Line 1: Line 1:
Gonna discuss aspects of {{cat|map views}} here. Having dabbled in [[Frans P. de Vries (Xymph)#Utilities|PostScript map printing]] in the (distant) past, I have a soft spot for this topic. :)
+
Gonna discuss aspects of {{cat|map views}} here. Having dabbled in [[Frans P. de Vries (Xymph)#Utilities|PostScript map printing]] in the (distant) past, I have a soft spot for this topic. :) This page aims to tie together all available info that's fragmented in various talk pages (or even only hidden in some contributor's heads), and document the bits I figured out for myself.
  
 
==Crispness==
 
==Crispness==
Two tools are commonly used to create map images for this wiki: [[Omgifol‎]] and [[SLADE 3]]. The former exists in three versions. These test images illustrate the differences:
+
Two tools are commonly used to create map images for this wiki: [[Omgifol‎]] and [[SLADE 3]]. Other tools appear to have been sporadically used to generate map views, e.g. [[:File:MAP22-castle-of-grief.svg|MAP22-castle-of-grief.svg]], [[:File:No_Rest_for_the_Living_Map01.png|No_Rest_for_the_Living_Map01.png]] and [[:File:Lost_episodes_of_doom_e1m3.png|Lost_episodes_of_doom_e1m3.png]], but it's unknown what and where they are, and they don't seem to be in active use anymore, so they are not covered here.
 +
 
 +
Omgifol‎ exists in three versions. These test images illustrate the differences:
  
 
<gallery>
 
<gallery>
Line 38: Line 40:
 
The result is a clean and crisp map image. Yay.
 
The result is a clean and crisp map image. Yay.
  
Image 1 is part of the very first batches of map uploads by [[Fredrik]] (author of omgifol‎) for the UDoom, Doom2, Evilution & Plutonia IWADs in [http://doomwiki.org/w/index.php?title=Special:Contributions/Fredrik&offset=20050112050000&target=Fredrik January 2005] (some superseded by [[User:Ryan W|Ryan W]], see below). Source code of that pre-0.2 version of omgifol is not available, but most likely the sorting statement was not yet present then. It's unknown how many maps have been uploaded using this version, but assuming that v0.2 was the first public version (released in May 2005), any maps uploaded by anyone since then will be crisp.
+
Image 1 is part of the very first batches of map uploads by [[Fredrik]] (author of Omgifol‎) for the UDoom, Doom2, Evilution & Plutonia IWADs in [http://doomwiki.org/w/index.php?title=Special:Contributions/Fredrik&offset=20050112050000&target=Fredrik January 2005] (some superseded by [[User:Ryan W|Ryan W]], see below). Source code of that pre-0.2 version of omgifol is not available, but most likely the sorting statement was not yet present then. It's unknown how many maps have been uploaded using this version, but assuming that v0.2 was the first public version (released in May 2005), any maps uploaded by anyone since then will be crisp.
  
 
Image 4, however, has the same ragged look as image 1, and therefore SLADE 3 most likely does not sort the linedefs before drawing. Pity.
 
Image 4, however, has the same ragged look as image 1, and therefore SLADE 3 most likely does not sort the linedefs before drawing. Pity.
Line 54: Line 56:
 
The second visible difference, between the omgifol versions, is that some lines change very subtly. The scaling computations changed from v0.2 to the current version, probably resulting in small rounding differences in placing the vertexes. And the original images were likely done on a 32-bit platform while my test images are done on 64-bit, also resulting in rounding differences.
 
The second visible difference, between the omgifol versions, is that some lines change very subtly. The scaling computations changed from v0.2 to the current version, probably resulting in small rounding differences in placing the vertexes. And the original images were likely done on a 32-bit platform while my test images are done on 64-bit, also resulting in rounding differences.
  
The third difference, between omgifol and slade3 images, is that the former reserves a 4-pixel border while in the latter this is about 25-26 pixels. That's a matter of style. Neither topic is very interesting, so enough about these.
+
The third difference, between omgifol and slade3 images, is that the former reserves a 4-pixel border while in the latter this is about 25-26 pixels. That's a matter of style. Neither difference is very interesting, so enough about these.
  
 
More relevant is the question of what a useful scale for a wiki-suitable map image is, in relation to the map's overall size.
 
More relevant is the question of what a useful scale for a wiki-suitable map image is, in relation to the map's overall size.
 +
 +
===File sizes===
 +
First, however, the file size itself depends on the tool: the above omgifol test images (since v0.2) are 17 KB, the slade3 one is 68 KB. Even accounting for omgifol using 24-bit PNG without alpha channel (transparency) and slade3 32-bit with alpha, this factor 4.0 increase seems steep.
 +
 +
Image file size matters, both for websites serving them (traffic costs, server load) and for users downloading them (time), so omgifol images are clearly preferable here.
 +
 +
===Controlling scale===

Revision as of 07:51, 22 April 2016

Gonna discuss aspects of map views here. Having dabbled in PostScript map printing in the (distant) past, I have a soft spot for this topic. :) This page aims to tie together all available info that's fragmented in various talk pages (or even only hidden in some contributor's heads), and document the bits I figured out for myself.

Crispness

Two tools are commonly used to create map images for this wiki: Omgifol‎ and SLADE 3. Other tools appear to have been sporadically used to generate map views, e.g. MAP22-castle-of-grief.svg, No_Rest_for_the_Living_Map01.png and Lost_episodes_of_doom_e1m3.png, but it's unknown what and where they are, and they don't seem to be in active use anymore, so they are not covered here.

Omgifol‎ exists in three versions. These test images illustrate the differences:

omgifol images are generated via the command-line:

# image 1 & 2:
python omg/demo/drawmaps.py doom2.wad MAP01 999 PNG
# image 3:
python omg/demo/drawmaps.py doom2.wad MAP01 1079

slade3 images are generated via the following GUI steps:

  1. Open dialog tab Edit -> Preferences -> Interface -> Colours & Theme
  2. In section "Map Image Export", set Background 'White' (default) & Opacity 255 (non-transparent)
  3. Switch to dialog tab Advanced
  4. Find the map_image_* entries, and set _thickness to 3
  5. For the test image, set _height to 1079 and _width to 999
  6. Load doom2.wad
  7. From the WAD directory, preview MAP01
  8. Use the Save Map Image button, to the left just above the preview, and Save

Differences

Looking closely at the full-size images, there are three visible differences. In image 1, the end points of many (gray) 2-sided linedefs appear on top of the (black) 1-sided linedefs they connect to. See for example where the diagonal steps in the starting room meet the walls. This gives a ragged look to the overall map.

In images 2 and 3, this problem is solved by drawing the black lines after all the gray ones, thanks to this sorting statement:

    # draw 1s lines after 2s lines so 1s lines are never obscured
    edit.linedefs.sort(lambda a, b: cmp(not a.two_sided, not b.two_sided))

The result is a clean and crisp map image. Yay.

Image 1 is part of the very first batches of map uploads by Fredrik (author of Omgifol‎) for the UDoom, Doom2, Evilution & Plutonia IWADs in January 2005 (some superseded by Ryan W, see below). Source code of that pre-0.2 version of omgifol is not available, but most likely the sorting statement was not yet present then. It's unknown how many maps have been uploaded using this version, but assuming that v0.2 was the first public version (released in May 2005), any maps uploaded by anyone since then will be crisp.

Image 4, however, has the same ragged look as image 1, and therefore SLADE 3 most likely does not sort the linedefs before drawing. Pity.

IMO the map pages of the official IWADs serve as "reference" for how all map pages could (eventually) look. Therefore they should have crisp map images, with the added benefit of distinguishing Doom Wiki more from its Wikia origin. Caveat is that the E1M*, E2M1-E2M5, E2M9 & E4M1 images use walkthrough spots added by Ryan W, so defer those for now. This is related to the marked spots discussion and maptabs RFC; see its demonstration.

TO DO:

  1. Recreate all IWAD maps. I will do this soon unless someone objects.
  2. Contact Simon Judd to request improvement of map image generation.
  3. Revive the maptabs RFC and see if progress can be made towards adding spotted images (with walkthrough text to match) to all IWAD map pages.

Bottom line: until SLADE 3's map images are improved, the preferred wiki maps are those by omgifol (v0.2 or later)‎, IMHO. Given that it does not have a GUI, and not all regular map contributors will even read this here discussion, chances are that ragged map images will continue to be uploaded. Such is life in wiki-land. ;)

Scaling

The second visible difference, between the omgifol versions, is that some lines change very subtly. The scaling computations changed from v0.2 to the current version, probably resulting in small rounding differences in placing the vertexes. And the original images were likely done on a 32-bit platform while my test images are done on 64-bit, also resulting in rounding differences.

The third difference, between omgifol and slade3 images, is that the former reserves a 4-pixel border while in the latter this is about 25-26 pixels. That's a matter of style. Neither difference is very interesting, so enough about these.

More relevant is the question of what a useful scale for a wiki-suitable map image is, in relation to the map's overall size.

File sizes

First, however, the file size itself depends on the tool: the above omgifol test images (since v0.2) are 17 KB, the slade3 one is 68 KB. Even accounting for omgifol using 24-bit PNG without alpha channel (transparency) and slade3 32-bit with alpha, this factor 4.0 increase seems steep.

Image file size matters, both for websites serving them (traffic costs, server load) and for users downloading them (time), so omgifol images are clearly preferable here.

Controlling scale