Source

srb2deutex / docsrc / changes.html

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
<html>
<head>
<title>History of changes for DeuTex</title>
</head>
<body>
<h1>History of changes for DeuTex</h1>

<dl>
<p><dt>DeuTex 4.4.0 (AYM 2000-01-05)
<dd>
	<ul>
	<p><li>Game: Hexen: musics are now identified and extracted properly.

	<p>The old music identification code assumed that any lump whose name
	does not begin with either "<code>D_</code>" or "<code>MUS_</code>"
	can't be a music. It worked for Doom, Heretic and Strife but, for
	Hexen, it caused all musics to be seen as plain lumps and extracted
	accordingly into the <code>lumps/</code> directory. DeuTex even tried
	to interprete <code>STALKR</code> and <code>WINNOWR</code> as pictures
	and said silly things about them having a "width greater than 4096".

	<p>The new code really checks whether the lump begins with
	"<code>MUS\x1a</code>" instead of just looking at its name. A lump is
	now deemed to be a music if and only if it begins with
	"<code>MUS\x1a</code>".

	<p>As a side-effect, certain operations (appending sprites and flats
	and merging) must have become slower. Furthermore, since these used to
	blindly assume that any lump whose name begins with either
	"<code>D_</code>" or "<code>MUS_</code>" is a music, their semantics
	might have changed. If you find they don't do what you want, try again
	using the <code>-musid</code> option and let me know whether it
	improves your condition.

	<p><li>Game: Hexen, Doom alpha 0.4/0.5: levels are now properly
	extracted and included.

	<p>There have been changes in the undocumented details of DeuTex's
	behaviour with respect to levels. The one that is most likely to be
	noticed is that, when including a level, DeuTex now copies the entire
	contents of the <code>levels/</code> pwad, starting from the level
	label. Previously, it included at most the 11 following lumps, and only
	if they had the expected names (<code>THINGS</code>,
	<code>VERTEXES</code> and so on).

	<p>But, basically, if the <code>levels/</code> pwads contain, as they
	should, all the needed lumps and nothing else, there shouldn't be any
	trouble.

	<p><li>Game: Heretic and Hexen: does not abort anymore with
	"<code>Bug: *** idinx (12) ***</code>" when trying to include the
	graphic lumps (resp. <code>CREDIT</code>, <code>E2END</code>,
	<code>FINAL1</code>, <code>FINAL2</code>, <code>HELP1</code>,
	<code>HELP2</code>, <code>TITLE</code> and <code>CREDIT</code>,
	<code>FINALE1</code>, <code>FINALE2</code>, <code>FINALE3</code>,
	<code>HELP1</code>, <code>HELP2</code>, <code>INTERPIC</code>,
	<code>TITLE</code>). More generally, DeuTex now accepts to compose wads
	even when there are graphic files in <code>lumps/</code>.

	<p><li>Game: Hexen: does not abort anymore with "<code>Height of FLAT
	./flats/x_001.ppm is not 64 or 65</code>" when trying to include flats
	<code>X_001</code> through <code>X_011</code>. In addition, DeuTex now
	just emits a warning instead of aborting for other oddball heights
	(i.e. not 64, 65 or 128). Have fun. <code>;-)</code> This is true for
	all iwads, not only Hexen.

	<p><li>Graphics: the annoying "<code>quantisation is slow</code>"
	warnings now appear at most once.
 
	<p><li>Misc: to disambiguate the "<code>&lt;count&gt; warnings
	omitted</code>" message, added optional scope prefix and changed the
	picture extraction function to use it.

	<p><li>Misc: got rid of the "don't bother Olivier" banner. People must
	have got the message by now.

	</ul>

<p><dt>DeuTex 4.3.0 (AYM 1999-12-24)
<dd>
	<ul>
	<p><li>Graphics: fixed ancient bug where DeuTex sometimes failed to
	include custom patches if they were not explicitly listed in the
	<code>[patches]</code> section. If the first patch used in
	<code>texture1.txt</code> was a custom patch, it <em>had</em> to be
	listed in <code>[patches]</code> or DeuTex would forget to include it.
	This is the same bug Olivier mentioned in the home page&nbsp;:

	<i><blockquote>
	  The support for wall patches in DeuTex has been modified. You must
	  now explicitely declare all your patches in a [PATCHE] section.

	  <p>If you don't do this, DeuTex will attempt to work as usual, but
	  there seems to ba a bug in this part of the code, so sometime some
	  needed patches are not loaded.
	</blockquote></i>

	After some summary testing, looks like it's fixed.

	<p><li>Misc: more error handling improvements.

	<p><li>Misc: bumped version number and cleaned things up for public
	release.

	<p><li>Misc: decreased maximum number of warnings per picture from 10
	to 5.

	<p><li>Platform: fixed <code>ftruncate()</code> being undeclared when
	compiling with DJGPP and updated the building-on-DOS section of the
	doc.

	</ul>

<p><dt>DeuTex 4.2.2 (AYM 1999-11-20) (not for public consumption)
<dd>
	<ul>
	<p><li>Misc: made certain failure messages more informative.
	
	<p><li>Platform: fixed several bugs that showed in the DOS precompiled
	executables for 4.1.0 and 4.2.0 (most common symptom : DeuTex aborting
	    with a "<code>Can't read WAD</code>" error message).

	<p>Lengthy technical explanation&nbsp;: in 4.1.0, I removed the
	"<code>huge</code>" pointer qualifiers that were scattered throughout
	the source not unlike nitrates in groundwater. The reasoning was that,
	since DeuTex is always compiled in the "huge" memory model anyway,
	those qualifiers were redundant. As I found out at the end of a long
	and painful debugging session, they weren't.

	<p>Had I read the doc of the compiler, I would have known that, even
	when in the huge memory model, pointers are "<code>far</code>" by
	default, not "<code>huge</code>". Far pointers wrap around at
	64&nbsp;kB&nbsp;; this is not what you want when you're trying to work
	with lumps larger than that. And, apparently, there is no way to
	specify that pointers should be huge by default.

	<p>On top of that, there was a genuine bug in
	<code>WADRreadBytes2()</code> that would have prevented the DOS port
	from working, even if all pointers had been huge. But this one was
	fixed in 4.2.1.

	<p>I switched to DJGPP, with which you can get working executables
	without having to contaminate your code with carcinogenic keywords. The
	bad news&nbsp;: firstly, the executables are somewhat larger. Secondly,
	since DJGPP executables use protected mode, they tend to be more fussy.

	<p>Thanks to Kim Parrott for reporting the bug and alpha testing my
	fixes.

	<p>All the above applies only to the DOS precompiled executables. Other
	platforms did not have these problems.

	</ul>

<p><dt>DeuTex 4.2.1 (AYM 1999-11-16) (not for public consumption)
<dd>
	<ul>
	<p><li>CLI: fixed segfault on "<code>deutex --vers</code>".

	<p><li>Graphics: new option <code>-usedidx</code>. When called with
	this option, DeuTex scans all the graphics in the wad and prints
	statistics about which palette indices they use. (By "graphics" is meant
	"any data that is converted into an RGB triplet by looking up
	<code>PLAYPAL</code> or <code>TITLEPAL</code>". That includes flats,
	graphics, patches, sneaps, sneats and sprites.) I've added this command
	for my own use, to help me decide which index should be used to store
	the transparent colour for Hexen.

	<p><li>Misc: made certain failure messages more informative.
	
	<p><li>Misc: made printing of lump names garbage-proof.

	<p><li>Platform: fixed a huge DOS bug that made DeuTex fail with
	a "<code>Can't read WAD</code>" error whenever it had to read more
	than 65535 bytes from a wad at once.

	<p><li>Platform: flushing <code>stdout</code> before writing to
	<code>stderr</code> so that messages come out in the right order when
	both outputs are redirected.

	<p><li>Sound: all conditions that used to be fatal errors when
	extracting sound lumps now just elicit a warning message, indicating
	which lump it was and what action was taken.

	</ul>

<p><dt>DeuTex 4.2.0 (AYM 1999-11-14)
<dd>
	<ul>
	<p><li>Doc: fixed error in documentation of <code>-pkgfx</code>,
	<code>-pknormal</code> and <code>-usedtex</code>.

	<p><li>Game: Strife: fixed DeuTex aborting when extracting textures
	for versions of Strife &gt;=&nbsp;1.1. The problem was that
	Strife&nbsp;1.1 and above use a different format for the
	<code>TEXTURE1</code> and <code>TEXTURE2</code> lumps (Strife&nbsp;1.0
	uses the same format as Doom). New options "<code>-tf
	strife11</code>", "<code>-itf strife11</code>" and "<code>-otf
	strife11</code>" to support that format. Option <code>-strife</code>
	has been changed to imply "<code>-tf strife11</code>". New option
	<code>-strife10</code> that is identical to <code>-strife</code>
	except that it does <em>not</em> imply "<code>-tf strife11</code>".
	Summary&nbsp;:

	<p><ul>
	<li>if you have the Strife&nbsp;1.0 iwad, use "<code>-strife10</code>"
	(or "<code>-tf normal</code>"),

	<li>if you have Strife&nbsp;1.1 or above, use "<code>-strife</code>"
	(or "<code>-tf strife11</code>").
	</ul>

	<p>Thanks to Kim Parrott for reporting the bug and Len Pitre for
	pointing me in the right direction.

	<p><li>Sound: fixed two bugs in reading Sun audio (<code>.au</code>)
	files. Fixes error "<code>WAV: can't read data
	of./sounds/foo.au</code>" (sic) when trying to build a wad. One of
	these bugs prevented from reading Sun audio files on little-endian
	machines. It had been there for a long time&nbsp;; v3.8 has it and the
	v3.6 binary behaves like it had it too. I doubt that anyone had ever
	been able to use <code>.au</code> files on little-endian machines
	before.

	</ul>

<p><dt>DeuTex 4.1.0 (AYM 1999-11-01)
<dd>
	<ul>
	<p><li>CLI: new options <code>-sneas</code>, <code>-sneaps</code> and
	<code>-sneats</code>.

	<p><li>Code: removed all occurrences of "<code>huge</code>" on the
	theory that, on platforms where it's meaningful, we always use the
	huge memory model anyway.

	<p><li>Code: replaced certain occurrences of "<code>Int32</code>" by
	"<code>iolen_t</code>".

	<p><li>Code: replaced certain occurrences of "<code>256</code>" by
	"<code>NCOLOURS</code>".

	<p><li>Doom alpha 0.4: <code>AMENA0</code> and <code>MSKUL*</code> are
	now correctly recognized as graphics and not as lumps anymore. The 21
	graphic lumps that ended up in <code>lumps/</code> are now properly
	extracted (into <code>sneaps/</code> and <code>sneats/</code>). (The
	first item involved propagating to <code>IDENTgraphic()</code> the
	changes made to <code>PICtoRAW()</code> in v. 4.0.2. The second item
	needed heavy hacking, creating a new image type (christened "snea")
	and managing an alternate palette for <code>TITLEPAL</code>.) Still
	extracted as lumps&nbsp;: <code>GNUM[0-9]</code> and
	<code>HUFONT</code>.

	<p><li>Doom alpha 0.5: the 86 graphic lumps that ended up in
	<code>lumps/</code> are now properly extracted (into
	<code>sneaps/</code> and <code>sneats/</code>). Still extracted as
	lump&nbsp;: <code>HUFONT</code>.

	<p><li>Graphics: errors that used to cause DeuTex to give up on
	extracting a picture now just make it skip the rest of column. It also
	prints detailed messages about what it didn't like and in which picture
	it occurred instead of bailing out silently.

	<p><li>Misc: new option <code>-di</code> to debug entry
	identification. Useful mainly to hackers.

	<p><li>Misc: cosmetic changes in the generated
	<code>wadinfo.txt</code> and in the phase messages.

	<p><li>Misc: no more messages "<code>Creating PWAD</code>" and
	"<code>WAD is complete...</code>" during level extraction.

	<p><li>Misc: set a limit of 10 warnings per picture, to prevent
	invalid pictures from uselessly flooding the output.

	</ul>

<p><dt>DeuTex 4.0.3 (AYM 1999-10-02)
<dd>
	<ul>
	<p><li>CLI: new option <code>-doom2</code> as suggested by Matthew
	Miller.

	<p><li>Graphics: now accepts to extract pictures as large as
	4096&times;4096 (previously the limit was 320&times;200). This fixes
	"<code>Failed to write sprite</code>" errors when trying to extract
	<code>PSYBA0</code> and <code>PSYBB0</code> from
	<code>strain.wad</code>. Thanks to Matthew miller for reporting the
	bug.

	<p><li>Misc: added a useful URL to the GIF warning.

	<p><li>Platform: now builds without errors on FAT filesystems
	(replaced <code>.deutex</code> and <code>.deusf</code> by
	<code>tmp/_deutex</code> and <code>tmp/_deusf</code>).

	<p><li>Sound: fixed a bug that caused DeuTex to extract sounds with
	unlikely sample rates like 4&nbsp;GHz whenever the sample rate in the
	lump was higher than 32767&nbsp;Hz (for example <code>DSVILACT</code>
	and <code>DSVILSIT</code> from <code>ncc1701.wad</code>, with a sample
	rate of 44.1&nbsp;kHz). Thanks to Matthew Miller for reporting the
	bug.

	</ul>

<p><dt>DeuTex 4.0.2 (AYM 1999-09-19)
<dd>
	<ul>
	<p><li>CLI: new options
	
	  <ul>
	  <li><code>-doom02</code> (implies <code>-ipf alpha</code>,
	  <code>-itf none</code> and <code>-itl none</code>)

	  <li><code>-doom04</code> (implies <code>-ipf alpha</code>,
	  <code>-itf nameless</code> and <code>-itl textures</code>)

	  <li><code>-doom05</code> (implies <code>-ipf alpha</code> and
	  <code>-itl textures</code>)

	  <li><code>-doompr</code> (implies <code>-ipf pr</code>)

	  </ul>

	<p>Use those options where you would have used <code>-doom</code> and
	friends. For example, to extract the contents of the Doom 0.4 iwad
	that is in <code>c:\doom0_4</code>, type "<code>deutex -doom04
	c:\doom0_4 -xtract</code>".

	<p><li>Code: replaced certain unjustified uses of <code>Int32</code>
	by <code>long</code>.

	<p><li>Doc: removed <code>old/readme.txt</code>. It's so out of date
	that it's more confusing than useful.

	<p><li>Game: Doom alpha and Doom PR: it's now possible to extract
	graphics, patches, sprites and textures from those iwads. Three new
	options&nbsp;:

	  <dl>
	  <dt><code>-ipf {normal|pr|alpha}</code>
	  <dd>Use <code>alpha</code> for Doom alpha 0.2, 0.4 and 0.5.<br>Use
	  <code>pr</code> for Doom PR (press release pre-beta).<br>Use
	  <code>normal</code> for everything else.

	  <dt><code>-itf {normal|nameless|none}</code>
	  <dd>Use <code>none</code> for Doom alpha 0.2.<br>Use
	  <code>nameless</code> for Doom alpha 0.4.<br>Use <code>normal</code>
	  for everything else, including Doom alpha 0.5.

	  <dt><code>-itl {normal|textures|none}</code>
	  <dd>Use <code>none</code> for Doom alpha 0.2.<br>Use
	  <code>textures</code> for Doom alpha 0.4 and 0.5.<br>Use
	  <code>normal</code> for everything else, including Doom alpha 0.5.

	  </dl>

	<p>You shouldn't ever have to use those options directly. It's better
	to use just <code>-doom02</code>, <code>-doom04</code>,
	<code>-doom05</code> and <code>-doompr</code>, which take care of
	setting ipf, itf and itl properly for you.

	<p>Note that extracting levels and some other lumps from the Doom
	alpha iwads does not work yet.

	<p><li>Platform: new target in the makefile to generate a binary DOS
	distribution with the executables and the user documentation in DOS
	format, with DOS-ish names.

	</ul>

<p><dt>DeuTex 4.0.1 (AYM 1999-09-10)
<dd>
	<ul>
	<p><li>CLI: reworked the command line arguments parsing, with
	the following consequences.

	  <ul>
	  <li>Options can now be abbreviated freely, as long as the
	  abbreviation is not ambiguous. For example, you can use
	  <code>-heretic</code>, <code>-hereti</code>, <code>-heret</code>,
	  <code>-here</code> or <code>-her</code> but not <code>-he</code>
	  because that could also be the abbreviation for <code>-help</code>
	  (or <code>-hexen</code>, for that matter). On the other hand,
	  <code>-h</code> <em>is</em> allowed because it's not an abbreviation
	  (there's really a <code>-h</code> option).

	  <li><code>-heretic</code> and <code>-hexen</code> now work (they
	  were "hidden" by <code>-h[elp]</code>). 

	  <li><code>-v<var>@</var></code> has been split in <code>-v0</code>,
	  <code>-v1</code> ... <code>-v5</code> because the new code does not
	  allow excess characters after an option.
	  <code>-v<var>string</var></code> where <var>string</var> is anything
	  else than "<code>0</code>" through "<code>5</code>" now triggers an
	  error (it used to be accepted silently). I hope no one relied on the
	  old undocumented behaviour.

	  <li>Certain silly command line arguments that would have worked
	  before would now trigger an error. For example, it used to be
	  possible to type <code>-extramarital</code> or
	  <code>-extermination</code> for <code>-extract</code> but not
	  anymore. The old code defined relatively short options
	  (<code>-ext</code>) and accepted command line arguments as long as
	  the defined option was an initial substring of the command line
	  argument. The new code does the reverse; it defines relatively long
	  options (<code>-extract</code>) and accepts command line argument as
	  long as they're an initial substring of the defined option.

	  </ul>

	<p><li>Code: replaced direct testing of <code>__MSDOS__</code>,
	<code>__OS2__</code>, <code>__GNUC__</code>,
	<code>__BORLANDC__</code> by <code>DT_CC</code> and
	<code>DT_OS</code>. This is hopefully going to make Udo's job a
	bit easier.

	<p><li>Code: now uses the same <code>fopen()</code> modes for
	all platforms: "<code>{rw}b</code>" for binary mode and
	"<code>{rw}</code>" for text mode, as per the ANSI/ISO C
	standard. This will fix the problem Udo Munk reported with the
	Cygwin build opening binary files in text mode and thus failing
	miserably. Note that certain DOS C compilers can be configured
	so that "<code>{rw}</code>" opens files in <em>binary</em> mode.
	Don't do that&nbsp;! If you have problems with text files on
	DOS, make sure your C compiler is configured so that
	"<code>{rw}</code>" opens files in <em>text</em> mode.

	<p><li>Code: added to the distribution archive
	<code>gifcodec.c</code> that I had forgotten to include (it's
	not used anyway).

	<p><li>Code: added to the distribution archive
	<code>src/{deusf,deusfos,deutex,deutexos}.def</code> that I had
	forgotten to include. I guess that's Windows/OS/2-only stuff.

	<p><li>Doc: updated <code>making.txt</code> and renamed it as
	<code>INSTALL</code> for homogeneity. Removed obsolete reference
	to <code>alpha.sh</code> and the file itself.

	<p><li>Doc: made more legal updates.

	<p><li>Doc: documented <code>DOOMWADDIR</code> in the man page.

	<p><li>Misc: changed the default graphics format for Unix from
	GIF to PPM, so that fewer user sites are broken if and when GIF
	support is removed. For the same reason, added a warning message
	when <code>-gif</code> is used or the first time an image is
	read from a GIF file.

	<p><li>Misc: changed the lookup order for images to PPM, BMP,
	GIF (was BMP, GIF, PPM).

	<p><li>Platform: fixed a couple of things that didn't work on
	16-bit platforms (real-mode DOS).

	<p><li>Platform: now compiles on DOS with Borland C++ 4.0.
	
	<p><li>Platform: now compiles on DOS with MSC 6.0. The MSC 6.0
	build is functional but limited because it can't allocate blocks
	larger than 64 kB, which is insufficient for certain images. I
	can't use <code>halloc()</code> instead of <code>malloc()</code>
	because it does not supporting resizing (i.e. there's no
	<code>hrealloc()</code> function).

	<p><li>Platform: in response to Udo's remarks, DJGPP and Cygwin
	are now properly identified (<code>__DJGPP__</code> and
	<code>__CYGWIN__</code>).

	<p><li>Platform: added sanity checks on specified-size types
	<code>Int32</code> and friends.

	</ul>

<p><dt>DeuTex 4.0.0a3 (AYM 1999-09-05)
<dd>
	<ul>
	<p><li>Code: removed incongruous <code>#define</code>-ing of
	<code>O_BINARY</code> and <code>SEEK_SET</code>.

	<p><li>Code: after Udo Munk's report, fixed warnings in
	  <ul>
	  <li><code>src/color.c(74)</code>
	  <li><code>src/ident.c(583)</code>
	  <li><code>src/ident.c(658)</code>
	  <li><code>src/mkwad.c(78)</code>
	  <li><code>src/mkwad.c(79)</code>
	  <li><code>src/mkwad.c(80)</code>
	  <li><code>src/mkwad.c(81)</code>
	  <li><code>src/picture.c(903)</code>
	  <li><code>src/picture.c(912)</code>
	  </ul>

	<p><li>Doc: updated <code>making.txt</code>.

	<p><li>Legal: as agreed to by Olivier Montanuy, DeuTex is now
	entirely GPL'd. Well, <em>almost</em> entirely, since it
	includes code written by different authors in <code>lzw.c</code>
	and elsewhere. Changed the notices in the source files and added
	new file <code>LICENSE</code> to clarify things.

	<p><li>Makefile: should now work with all C compilers (removed
	<code>-Wall</code> from <code>CFLAGS</code>).

	<p><li>Makefile: <code>clean</code> now removes the DOS
	executables if they exist.

	<p><li>Makefile: does not compile with debug information in by
	default anymore.

	<p><li>Makefile: new targets <code>dall</code>,
	<code>ddt</code>, <code>dds</code>, <code>ddeutex</code>
	and <code>ddeusf</code> for compiling with debug
	information and all warnings.

	<p><li>Makefile: new target <code>help</code>.

	<p><li>Makefile: new target <code>distdos</code>.

	<p><li>Platform: replaced <code>unlink()</code> by
	<code>remove()</code> for portability. Thanks to Udo for
	reporting this.

	<p><li>Platform: on 8.3 filesystems, make should not choke on
	<code>docsrc/changes.html</code> anymore. Thanks to Udo for
	reporting this.

	<p><li>Sound: corrected some misleading endianness
	comments in <code>sound.c</code>.

	</ul>

<p><dt>DeuTex 4.0.0a2 (AYM 1999-08-14)
<dd>
	<ul>
	<p><li>Game: easier to use with Strife (now looks for
	"<code>strife1.wad</code>", new option "<code>-strife</code>").

	<p><li>Game: easier to use with Hexen (new option
	"<code>-hexen</code>").

	<p><li>Command line: new options "<code>-hexen</code>" and
	"<code>-strife</code>".

	<p><li>Command line: new option "<code>--version</code>" (prints
	version number and returns 0).

	<p><li>Doc: various changes in the man page, in the output of
	"<code>-help</code>" and "<code>-man</code>" and elsewhere.

	<p><li>Makefile: various improvements.

	<p><li>Distribution: set modes straight.

	</ul>

<p><dt>DeuTex 4.0.0a1 (AYM 1999-08-12)
<dd>
	<ul>
	<p><li>General: fixed many segfaults that were caused by
	attempts to <code>fclose (NULL)</code>.

	<p><li>Game: Strife is now supported.

	<p><li>Wad: new options <code>-be</code>, <code>-le</code>,
	<code>-ibe</code>, <code>-ile</code>, <code>-obe</code> and
	<code>-ole</code> to control the endianness of the wads.
	<strong>Caution</strong>: don't use them if you don't know what
	you're doing&nbsp;! As far as I know, wads are always
	little-endian regardless of the architecture of the host.
	Therefore, I see no reason for someone in his/her right mind to
	create a big-endian wad. Those options are here more for the
	sake of completeness than anything else.

	<p><li>Wad: made "<code>%</code>" legal in names, to deal with
	Strife's "<code>INVFONG%</code>" and
	"<code>INVFONY%</code>".</p>

	<p><li>Wad, graphics: end-of-flats marker is now
	<code>F_END</code> by default instead of <code>FF_END</code>.
	The reason for this change is that, with <code>F_END</code>, you
	don't need DeuSF to get Doom to see your new flats. Should you
	need to, it's still possible to get <code>FF_END</code> by using
	<code>-fend</code>.

	<p><li>Graphics: the default transparent colour is now a dark
	blue-green (rgb:00/2f/2f). It used to be cyan (rgb:00/ff/ff)
	which was blindingly bright, especially compared to the usually
	dark colours used in Doom textures. It's no fun to tweak shades
	of dark brown on a cyan background.

	<p>To reuse images done with/for a previous version of DeuTex,
	you need to either invoke DeuTex with "<code>-rgb 0 255
	255</code>" or convert your images by replacing all occurrences
	of colour (0, 255, 255) by colour (0, 47, 47). To preserve
	compatibility with WinTex, I didn't change the default
	transparent colour in WinTex mode&nbsp;; it's still (0, 255,
	255).

	<p><li>Graphics: fixed segfaults due to bug in conversion of
	bitmap images to Doom pictures. Occured in certain 2-pixel high
	images such as <code>STBFN045</code> in the Strife iwad.

	<p><li>Graphics: now supports pictures and textures up to 509
	high (was limited to 128).

	<p><li>Graphics: now supports pictures and textures up to 1024
	wide (was limited to 512).

	<p><li>Graphics: new option "<code>-pf</code>" to deal with the
	different picture format in the Doom alpha iwad (the underlying
	functionality is not implemented yet !)

	<p><li>Graphics: using <code>-ppm</code> does not cause anymore
	DeuTex to abort with "<code>Bug: *** psvit ***</code>".

	<p><li>Graphics: fixed "<code>-ppm</code>" message.

	<p><li>Sound, platform: a bug that must have prevented reading
	<code>.wav</code> files on big endian machines has been
	squashed.

	<p><li>Command line: options can't start with a slash
	("<code>/</code>") anymore. I don't think anyone used it and was
	a silly feature for a Unix program.

	<p><li>Command line: not case insensitive anymore.
	
	<p><li>Command line: changed the wording of error messages to
	use "option" instead of "command".

	<p><li>Command line: added options "<code>-?</code>" and
	"<code>--help</code>" as synonyms for "<code>-help</code>".

	<p><li>Doc: new option "<code>-man</code>" to print help in
	<code>troff -man</code> source format for inclusion in the man
	page.

	<p><li>Doc: the version number is now a free-form string.

	<p><li>Doc: Made on-line help more compact.

	<p><li>Doc: updated "<code>making.txt</code>".

	<p><li>Doc: made a proper <code>README</code> file.

	<p><li>Makefile: renamed "<code>unix</code>" target as
	"<code>strip</code>".

	<p><li>Makefile: new target "<code>install</code>".

	<p><li>Makefile: new target "<code>dist</code>".

	<p><li>Platform: reworked the handling of endianness. DeuTex
	used to deal with that through a set of macros that swapped
	bytes whenever the required endianness was not the same as the
	native endianness. To known the native endianness, DeuTex relied
	on a macro defined via <code>-D</code>.

	<p>There were two problems with this scheme. Firstly, Olivier
	got the meaning of "little endian" and "big endian" backwards
	and defining <code>LITTLE_ENDIAN</code> in fact caused DeuTex to
	believe it was being compiled for a big endian machine. As the
	glibc headers happen to define <code>LITTLE_ENDIAN</code> if the
	machine is little endian, compiling DeuTex on a glibc little
	endian Linux system was impossible unless you made changes to
	the source.

	<p>The other, more fundamental, objection against the old
	approach is that, as it needed the user to tell it about the
	native endianness by modifying the makefile, it prevented
	unattended builds and made things difficult for naive users.

	<p>The new method eliminates this problem by using a different
	algorithm that does not need to know the native endianness. The
	end result is that you don't have to worry about endianness
	anymore.

	<p><li>Internal: in <code>TXTinit()</code>, removed useless
	"<code>% 0xFF</code>" in index of <code>TXTval</code>.

	</ul>

</dl>

</body>
</html>
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.