User:Xymph/Map views

This page discusses aspects of, and improvements for, map views. 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. And sometimes it's little more than a brain dump.

Crispness[edit]

Two tools are commonly used to create map images for this wiki: the Omgifol drawmaps.py script and SLADE 3. Other tools appear to have been sporadically used to generate map views, e.g. File: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 drawmaps.py exists in three versions. These test images illustrate the differences:

1: original omgifol @ MAP01 (2005-01-11)
2: via omgifol 0.2
3: via omgifol improved
4: via slade3 v3.1.1.1

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:

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

See also the built-in Documentation -> Tutorials -> How to Create Map Images page.

Differences[edit]

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.

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 likely be crisp.

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

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 let's defer those for now. This is related to the marked spots discussion and maptabs RFC; see its demonstration.

TO DO:

~~Recreate and upload all IWAD maps. I will do this soon unless someone objects.~~
~~Contact Simon Judd to request improvement of map image generation.~~ Implemented in v3.1.1.2.
~~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. ;)

Edit: As of the v3.1.1.2 release of SLADE 3, its map images look similarly crisp as omgifol's thanks to linedef sorting, and all map contributors using SLADE 3 are advised to upgrade.

Scaling[edit]

The second visible difference, between the omgifol versions, is that some lines change very subtly. The scaling computations changed from v0.2 to the improved 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[edit]

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. For bigger maps and images, the difference is likely proportional.

Image file size matters in general, both for websites serving them (traffic costs, server load) and for users downloading them (time), so omgifol images are clearly preferable, IMHO. But to Doom Wiki, it is of no consequence.

Controlling scale[edit]

Omgifol drawmaps through v0.2 takes its pixel-size parameter to be the required width, and the height is calculated proportionally. That's why portrait-oriented maps (e.g. MAP32, 1.8M px²) can end up being significantly larger than landscape ones (e.g. MAP03, 0.67M px²) at identical width. The improved omgifol version applies its pixel-size parameter to the largest of either width or height, making for smaller, narrower landscape images (e.g. MM2_MAP20). This is why in the above command-line for image 3, 1079 was used to arrive at the same dimensions as images 1 & 2.

SLADE 3 allows separate definitions of width and height in pixels (positive numbers), shown in step #5 above to match omgifol's test image dimensions, while negative values are taken to be the scale between map units and image dimensions. E.g. setting both to -4 for MAP01 produces a 844x912 px image. That's flexible and useful, although carelessly setting fixed dimensions without regard for the map's orientation can result in excess whitespace (e.g. D2TWID_MAP33), as does setting width and height to different scale values. Also, SLADE 3 does allow changing line thickness, while Omgifol does not.

Factors influencing the appearance of map images are:

map dimensions versus image dimensions, i.e. the scale
overall image dimensions (which affects file size, preferably kept below 250 KB)
line thickness versus map dimensions
level of detail in the map (e.g. large numbers of 2-sided linedefs)
whether monster caches & control sectors are edited out before generating an image

A large image of a small map like Fava_Beans_E1M1 seems excessive but is otherwise nice and clean. Conversely however, small images of big maps (e.g. 50shades_MAP06 & Breach) are, frankly, useless as many lines simply blur together. It's impossible to find one's way around them in tandem with a textual walkthrough. A large image helps a lot to understand the lay of the land (e.g. E1M8B), or compare Sunlust_MAP10 versus Sunlust_MAP10 (talk).

Line thickness should be more than 1 pixel or some lines will disappear when the map is scaled down to a thumb image next to a walkthrough. Omgifol always uses 3-pixel lines while the SLADE 3 default is 1, hence the adjustment in step #4 above, and while some experimentation with other values can be interesting, 3 is usually fine.

Lastly, editing out parts of the map that cannot be accessed by the player, such as monster caches and control sectors, affects the scale and dimensions with which the image is subsequently generated. For example, the 1000x917 px image of the edited Cchest3_MAP23 becomes a 1258x917 px image (trust me) of the original map when adjusting for the same height. The visual appearance is indeed different, but this isn't problematic unless the trimmed sectors are way outside the regular map area. And map editing is, of course, time consuming if all one wants is a quick map. :)

Useful scale[edit]

With all that covered, back to the original question: what is a useful scale, especially for a multi-map series? If all maps in series (e.g. an IWAD) are rendered at the same scale, the viewer immediately gets a good idea of the size differences between those maps. While SLADE 3 allows setting scales, it is not convenient to generate an entire batch of map images via the GUI. So I updated the Omgifol drawmaps script to accept an optional scale parameter as well, and apply that to all generated maps.

After some experimentation the value 4.0 gives acceptable results for the four official IWADs. A factor of 4.5 would also work, but SLADE 3 accepts only integer scale values, so let's stick to that. However, a fixed scale like that can result in impractically large images for really expansive maps, such as the outdoor levels in the IWADs, and modern maps for limit-removing ports (e.g. Plasmaplant).

To get a feel for this problem, I generated the four IWADs' maps with scale 4.0:

Level	Ult.Doom	Level	Doom II	Evilution	Plutonia
E1M1	1152 x 712	MAP01	852 x 920	440 x 532	1244 x 944
E1M2	1336 x 984	MAP02	480 x 484	869 x 669	1084 x 997
E1M3	1064 x 772	MAP03	754 x 504	943 x 1088	996 x 1008
E1M4	938 x 704	MAP04	522 x 424	1250 x 928	752 x 916
E1M5	1000 x 816	MAP05	792 x 536	900 x 916	1120 x 1112
E1M6	1452 x 1200	MAP06	960 x 648	924 x 768	1128 x 1064
E1M7	1016 x 866	MAP07	600 x 504	1816 x 1096	627 x 1011
E1M8	1662 x 1792	MAP08	984 x 952	1768 x 1306	1064 x 764
E1M9	856 x 808	MAP09	1086 x 1020	1004 x 760	1092 x 1208
E2M1	652 x 504	MAP10	1056 x 1064	486 x 664	744 x 808
E2M2	808 x 1304	MAP11	904 x 724	1048 x 960	784 x 1200
E2M3	896 x 638	MAP12	984 x 1112	1888 x 1720	832 x 848
E2M4	984 x 952	MAP13	800 x 1176	1348 x 1904	970 x 694
E2M5	1080 x 936	MAP14	984 x 888	1224 x 1026	752 x 792
E2M6	832 x 1258	MAP15	1104 x 1838	1204 x 1258	1032 x 1088
E2M7	1000 x 728	MAP16	1208 x 1224	1568 x 1008	888 x 936
E2M8	792 x 1272	MAP17	848 x 842	1040 x 816	848 x 616
E2M9	904 x 488	MAP18	1256 x 1134	1776 x 1784	968 x 944
E3M1	584 x 1096	MAP19	1400 x 1512	1420 x 1680	984 x 640
E3M2	726 x 1096	MAP20	1304 x 1580	3663 x 2469	848 x 832
E3M3	888 x 760	MAP21	880 x 746	3976 x 1960	704 x 768
E3M4	1048 x 958	MAP22	588 x 480	2250 x 1563	1270 x 958
E3M5	1208 x 1164	MAP23	1102 x 1278	868 x 1332	952 x 1256
E3M6	1704 x 1706	MAP24	1512 x 1340	936 x 766	880 x 800
E3M7	936 x 968	MAP25	1038 x 1808	1824 x 1256	1083 x 1084
E3M8	936 x 1006	MAP26	1154 x 800	1448 x 1264	1546 x 884
E3M9	1418 x 1464	MAP27	976 x 1128	3618 x 2604	1024 x 1168
E4M1	552 x 280	MAP28	1122 x 1262	1528 x 1024	1976 x 2000
E4M2	558 x 670	MAP29	1212 x 1160	1800 x 1776	1640 x 2024
E4M3	1208 x 1112	MAP30	682 x 700	2656 x 1064	1240 x 1120
E4M4	716 x 632	MAP31	2194 x 1800	2616 x 2392	812 x 924
E4M5	1008 x 868	MAP32	1000 x 1800	1092 x 2448	1360 x 1048
E4M6	1106 x 730
E4M7	776 x 976
E4M8	928 x 1146
E4M9	582 x 1152
>= 1600	2		4	15	2

In today's era of large monitors, an image with a maximum dimension (height and/or, especially, width) of 1600 pixels seems (IMHO) of acceptable size for displaying in a browser without excessive scrolling around at 100% scaling. As indicated by italics in the table, only a few maps in most IWADs exceed that dimension. TNT: Evilution is notable however for almost half its maps being (very) expansive. And a modern level like the aforementioned Plasmaplant would be 2801 x 3399 pixels at scale 4.0, too. As rendered, its 2060 x 2500 dimensions correspond to scale 5.44 instead, but an even larger scale factor to bring its height (closer) to 1600 would blur together too many of the 2-sided linedefs.

So a mechanism is needed to keep large maps down to acceptable image dimensions. That's actually simple: fall back on the already specified maximum dimension for the largest of width and height. Limiting the above expansive maps to 1600 pixels results in the following new dimensions, with the effective scale added in italics:

Level	Ult.Doom	Level	Doom II	Evilution	Plutonia
E1M7		MAP07		1600 x 966 4.54
E1M8	1483 x 1600 4.48	MAP08		1600 x 1182 4.42
E2M3		MAP12		1600 x 1457 4.72
E2M4		MAP13		1133 x 1600 4.76
E2M6		MAP15	961 x 1600 4.60
E2M9		MAP18		1593 x 1600 4.46
E3M1		MAP19		1352 x 1600 4.20
E3M2		MAP20		1600 x 1079 9.18
E3M3		MAP21		1600 x 791 9.97
E3M4		MAP22		1600 x 1112 5.63
E3M6	1598 x 1600 4.27	MAP24
E3M7		MAP25	918 x 1600 4.52	1600 x 11024.56
E3M9		MAP27		1600 x 1152 9.07
E4M1		MAP28			1580 x 1600 5.01
E4M2		MAP29		1600 x 1578 4.50	1296 x 16005.07
E4M3		MAP30		1600 x 642 6.65
E4M4		MAP31	1600 x 1313 5.49	1600 x 14636.55
E4M5		MAP32	889 x 1600 4.50	715 x 16006.13

Most of the new scale factors are not significantly larger than the default, with the exception of Evilution's MAP20, MAP21 and MAP27.

Conclusions[edit]

Scale 4.0 (for Omgifol drawmaps) or -4 (for SLADE 3) is the best scale to render the vast majority of regularly-sized maps, and especially useful when generating a series of maps so the viewer gets a good feel of the size differences between them.

Limiting the largest dimension (width and/or height) to 1600 pixels for larger maps is an acceptable compromise. With Omgifol that's handled automatically, but setting a fixed pixel limit for one dimension in SLADE 3 requires adjusting the other dimension such that little excess whitespace results, which can take some experimentation.

For modern, expansive maps with a great level of architectural detail, a larger dimension limit such as 2000-2500 pixels may need to be chosen to prevent lines blurring together. Line thickness should be 3 (in SLADE 3, already default in Omgifol).

The drawmaps commands to generate the IWADs' maps thus become:

python omg/demo/drawmaps.py DOOM.WAD E?M? 1600 4.0
python omg/demo/drawmaps.py DOOM2.WAD MAP* 1600 4.0
# same for TNT.WAD & PLUTONIA.WAD

The current drawmaps script with scale support can be downloaded from my homepage. This version also offers verbose logging of the actual scale and dimensions used for each map if the -v option is specified. This feature provided the data for the above tables.

Lastly, if no scale is specified and multiple maps are generated, then verbose logging will include the average scale used to draw those maps within the specified (or default) size.

Thumbnailing[edit]

A user's perception of map view thumbnails – embedded next to walkthroughs – is influenced by the images' area and ratio of width and height. I think a series of map pages (e.g. of an IWAD or megawad) look best if the thumbnails' perception doesn't differ wildly from page to page. But currently the image(/file) tags used in walkthroughs define only their widths, typically 300px but sometimes varying that for unusual dimension ratios. Image tags also allow define the height, with the Wiki engine scaling the thumbnail within either maximum while preserving aspect ratio, e.g. 300x400px or 330x300px.

What would be suitable "standard" dimensions in the context of walkthrough sections? Let's explore a variety of situations:

Walkthrough[edit]

Nearly square @ 300px

Letters in italics refer to marked spots on the map. Sector, thing, and linedef numbers in boldface are secrets which count toward the end-of-level tally.

Essentials[edit]

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean pretium id diam eget consectetur. Cras viverra pharetra augue vitae pellentesque. Nunc magna nibh, suscipit id velit nec, dapibus facilisis nunc. Integer eget nisi efficitur, vehicula dolor id, fringilla ex. Quisque a fermentum arcu. Aliquam venenatis metus aliquam, auctor lacus vel, sodales risus. Fusce interdum molestie convallis. Vivamus cursus euismod iaculis.

Vivamus sit amet condimentum velit. Vivamus fringilla quis augue a rhoncus. Nunc lacinia commodo massa lacinia semper. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Curabitur eget sapien sit amet libero semper accumsan. Sed nec ultricies turpis. Quisque ut cursus nisl. Nullam tincidunt ex sit amet ligula efficitur vehicula. Suspendisse ornare eu ex ut dapibus. Suspendisse bibendum laoreet hendrerit. Praesent cursus, massa et mattis finibus, velit eros interdum felis, quis venenatis orci ligula sed dolor. Curabitur sit amet luctus turpis, eu varius sem. Nam laoreet est eget dui dictum elementum. Quisque porta quam et nisl consectetur, et vulputate elit aliquet. Etiam maximus ex a libero semper viverra.

For (extreme) portrait-oriented images, limiting height to 360px gives acceptable results. For (extreme) landscape-oriented images, extending width to 330px or 360px helps their perception too. For the middle ground of square-ish images, 300x300px naturally works well. Determining the (slightly arbitrary) area threshold where to switch from one dimension limit to another will take more work.

Goal for thumbnail area[edit]

The maximum possible area at the default width and height is 90000 px² for a square image. For other aspect ratios, my gut feeling is that two-thirds of that area, or roughly 60000 px², is a good target to aim for in order to result in reasonably consistent user perception of thumbnails. For images that are more landscape or portrait oriented, either the width or height (respectively) can be increased to keep the area within that ballpark, but only up to a limit of 360px or maybe 390px.

In order to get a better idea of how this approach impacts a wide variety of typical full-size image dimensions, I wrote a script to generate the following table. The original dimensions increment from 400 to 1600 at 150 px steps, and thumbnail dimensions start at 300x300px until the resulting area drops below 60000. Then the limit for the smallest dimension is increased in steps of 10% (30 px) until >=60000 px² is reached again, or the maximum increase of 30% is reached. The resulting dimensions and area are listed in the '+X0%' columns.

Original	Ratio	Thumbnail	Area	+10%	Area	+20%	Area	+30%	Area
400 x 400	1.00	300 x 300	90000
400 x 550	0.73	218 x 300	65400
400 x 700	0.57	171 x 300	51300	189 x 330	62370
400 x 850	0.47	141 x 300	42300	155 x 330	51150	169 x 360	60840
400 x 1000	0.40	120 x 300	36000	132 x 330	43560	144 x 360	51840	156 x 390	60840
400 x 1150	0.35	104 x 300	31200	115 x 330	37950	125 x 360	45000	136 x 390	53040
400 x 1300	0.31	92 x 300	27600	102 x 330	33660	111 x 360	39960	120 x 390	46800
400 x 1450	0.28	83 x 300	24900	91 x 330	30030	99 x 360	35640	108 x 390	42120
400 x 1600	0.25	75 x 300	22500	83 x 330	27390	90 x 360	32400	98 x 390	38220
550 x 400	1.38	300 x 218	65400
550 x 550	1.00	300 x 300	90000
550 x 700	0.79	236 x 300	70800
550 x 850	0.65	194 x 300	58200	214 x 330	70620
550 x 1000	0.55	165 x 300	49500	182 x 330	60060
550 x 1150	0.48	143 x 300	42900	158 x 330	52140	172 x 360	61920
550 x 1300	0.42	127 x 300	38100	140 x 330	46200	152 x 360	54720	165 x 390	64350
550 x 1450	0.38	114 x 300	34200	125 x 330	41250	137 x 360	49320	148 x 390	57720
550 x 1600	0.34	103 x 300	30900	113 x 330	37290	124 x 360	44640	134 x 390	52260
700 x 400	1.75	300 x 171	51300	330 x 189	62370
700 x 550	1.27	300 x 236	70800
700 x 700	1.00	300 x 300	90000
700 x 850	0.82	247 x 300	74100
700 x 1000	0.70	210 x 300	63000
700 x 1150	0.61	183 x 300	54900	201 x 330	66330
700 x 1300	0.54	162 x 300	48600	178 x 330	58740	194 x 360	69840
700 x 1450	0.48	145 x 300	43500	159 x 330	52470	174 x 360	62640
700 x 1600	0.44	131 x 300	39300	144 x 330	47520	158 x 360	56880	171 x 390	66690
850 x 400	2.13	300 x 141	42300	330 x 155	51150	360 x 169	60840
850 x 550	1.55	300 x 194	58200	330 x 214	70620
850 x 700	1.21	300 x 247	74100
850 x 850	1.00	300 x 300	90000
850 x 1000	0.85	255 x 300	76500
850 x 1150	0.74	222 x 300	66600
850 x 1300	0.65	196 x 300	58800	216 x 330	71280
850 x 1450	0.59	176 x 300	52800	193 x 330	63690
850 x 1600	0.53	159 x 300	47700	175 x 330	57750	191 x 360	68760
1000 x 400	2.50	300 x 120	36000	330 x 132	43560	360 x 144	51840	390 x 156	60840
1000 x 550	1.82	300 x 165	49500	330 x 182	60060
1000 x 700	1.43	300 x 210	63000
1000 x 850	1.18	300 x 255	76500
1000 x 1000	1.00	300 x 300	90000
1000 x 1150	0.87	261 x 300	78300
1000 x 1300	0.77	231 x 300	69300
1000 x 1450	0.69	207 x 300	62100
1000 x 1600	0.63	188 x 300	56400	206 x 330	67980
1150 x 400	2.88	300 x 104	31200	330 x 115	37950	360 x 125	45000	390 x 136	53040
1150 x 550	2.09	300 x 143	42900	330 x 158	52140	360 x 172	61920
1150 x 700	1.64	300 x 183	54900	330 x 201	66330
1150 x 850	1.35	300 x 222	66600
1150 x 1000	1.15	300 x 261	78300
1150 x 1150	1.00	300 x 300	90000
1150 x 1300	0.88	265 x 300	79500
1150 x 1450	0.79	238 x 300	71400
1150 x 1600	0.72	216 x 300	64800
1300 x 400	3.25	300 x 92	27600	330 x 102	33660	360 x 111	39960	390 x 120	46800
1300 x 550	2.36	300 x 127	38100	330 x 140	46200	360 x 152	54720	390 x 165	64350
1300 x 700	1.86	300 x 162	48600	330 x 178	58740	360 x 194	69840
1300 x 850	1.53	300 x 196	58800	330 x 216	71280
1300 x 1000	1.30	300 x 231	69300
1300 x 1150	1.13	300 x 265	79500
1300 x 1300	1.00	300 x 300	90000
1300 x 1450	0.90	269 x 300	80700
1300 x 1600	0.81	244 x 300	73200
1450 x 400	3.63	300 x 83	24900	330 x 91	30030	360 x 99	35640	390 x 108	42120
1450 x 550	2.64	300 x 114	34200	330 x 125	41250	360 x 137	49320	390 x 148	57720
1450 x 700	2.07	300 x 145	43500	330 x 159	52470	360 x 174	62640
1450 x 850	1.71	300 x 176	52800	330 x 193	63690
1450 x 1000	1.45	300 x 207	62100
1450 x 1150	1.26	300 x 238	71400
1450 x 1300	1.12	300 x 269	80700
1450 x 1450	1.00	300 x 300	90000
1450 x 1600	0.91	272 x 300	81600
1600 x 400	4.00	300 x 75	22500	330 x 83	27390	360 x 90	32400	390 x 98	38220
1600 x 550	2.91	300 x 103	30900	330 x 113	37290	360 x 124	44640	390 x 134	52260
1600 x 700	2.29	300 x 131	39300	330 x 144	47520	360 x 158	56880	390 x 171	66690
1600 x 850	1.88	300 x 159	47700	330 x 175	57750	360 x 191	68760
1600 x 1000	1.60	300 x 188	56400	330 x 206	67980
1600 x 1150	1.39	300 x 216	64800
1600 x 1300	1.23	300 x 244	73200
1600 x 1450	1.10	300 x 272	81600
1600 x 1600	1.00	300 x 300	90000

Conclusions[edit]

It seems to me that this approach works well for dimension increments up to at least (360px) 20%, and the only question remaining is whether 390px (30%) is acceptable for either width or height, or both, within the overall map page layout. The tricky part about that choice is that it's also influenced by the amount of walkthrough text next to the thumbnail, the browser window width, and perhaps other factors.

Dealing with the thresholds and increments is of course less easy to do when manually building out a map skeleton into a (more) complete page, so then the above can be used as merely a guideline. But I've already written a bot script to address the issue of replacing map caption strings, and this script will (soon) include the computations to modify the thumbnail dimensions as well. Then, at least for stock levels and megawads, and any other levels for which a .ini file is compiled, this approach can be rolled out consistently.

Xymph
46,763

From DoomWiki.org

Contents

Crispness[edit]

Differences[edit]

Scaling[edit]

File sizes[edit]

Controlling scale[edit]

Useful scale[edit]

Conclusions[edit]

Thumbnailing[edit]

Walkthrough[edit]

Essentials[edit]

Walkthrough[edit]

Essentials[edit]

Walkthrough[edit]

Essentials[edit]

Walkthrough[edit]

Essentials[edit]

Walkthrough[edit]

Essentials[edit]

Walkthrough[edit]

Essentials[edit]

Walkthrough[edit]

Essentials[edit]

Walkthrough[edit]

Essentials[edit]

Walkthrough[edit]

Essentials[edit]

Walkthrough[edit]

Essentials[edit]

Summary of examples[edit]

Goal for thumbnail area[edit]

Conclusions[edit]

Xymph 46,763

From DoomWiki.org

Contents

Crispness[edit]

Differences[edit]

Scaling[edit]

File sizes[edit]

Controlling scale[edit]

Useful scale[edit]

Conclusions[edit]

Thumbnailing[edit]

Walkthrough[edit]

Essentials[edit]

Walkthrough[edit]

Essentials[edit]

Walkthrough[edit]

Essentials[edit]

Walkthrough[edit]

Essentials[edit]

Walkthrough[edit]

Essentials[edit]

Walkthrough[edit]

Essentials[edit]

Walkthrough[edit]

Essentials[edit]

Walkthrough[edit]

Essentials[edit]

Walkthrough[edit]

Essentials[edit]

Walkthrough[edit]

Essentials[edit]

Summary of examples[edit]

Goal for thumbnail area[edit]

Conclusions[edit]

Xymph
46,763