-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
636 lines (556 loc) · 30.4 KB
/
index.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
<html>
<head>
<meta HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">
<meta NAME="GENERATOR" CONTENT="Microsoft FrontPage 5.0">
<title>The Echidna Libraries</title>
<link rel="stylesheet" type="text/css" href="notesstyledef.css">
</head>
<body>
<h1>The Echidna Libraries</h1></font>
<ul>
<li><a href="http://github.com/greggman/elibs/">Jump to the code</a></li>
<li><a href="#what">What is this?</a></li>
<li><a href="#interesting">Tell me the interesting bits.</a></li>
<li><a href="#utilities">Utilities and Tools</a></li>
<li><a href="#arguments">Command line argument system</a></li>
<li><a href="#reason">Reasons for going open source</a></li>
<li><a href="#instructions">Compiling / Setup Instructions</a></li>
<li><a href="#license">License</a></li>
<li><a href="#download">Download</a></li>
</ul>
<p><a name="what"></a>In 1990 my friends and I started a company called Echidna. At that time we created some
libraries of routines that we all shared. We needed to create titles for both the Amiga
and the PC and so we wanted to create a set of libraries that would allows us to write the
game once and just use a different version of the libraries for the game to run on a
different platform.</p>
<p>Since that time, some of those routines have turned out to be more re-usable then
others. Routines to do things like:
<ul>
<li>Parse a command line including support for nested response files. </li>
<li>Parse a Windows style .ini file and get values from it</li>
<li>Write formatted data to a text file</li>
<li>Split and combine filenames, paths and extensions</li>
<li>Get a directory listing optionally including subdirectories</li>
<li>Get a list of all environment variables</li>
<li>Walk the command a path so you can visit every directory</li>
<li>Find a file in the command path</li>
<li>Copy a file including date, attributes, commands (and resource fork)</li>
<li>Read/Set/Compare the date of a file</li>
<li>Implement a linked list</li>
<li>Report Errors</li>
<li>Track the call stack</li>
<li>Manage memory</li>
<li>Read/write 8bit, 24bit and 32bit images</li>
</ul>
<p>And a few other things like
<ul>
<li>Ensure that all systems support all functions we need (examples: strdup and stricmp) are
not ANSI and so are on some systems but not others.</li>
<li>Ensure a common set of basic types int8, uint8, int16, uint16, int32, uint32, BOOL</li>
<li>Support converting to and from the Native format of 16 and 32 bit values on the current
machine to/from the target machine.</li>
<li>Supply a bunch of routines for handling common tasks that should fail on error. Like
opening a file, allocating memory. In these cases, if we are writing a command line tool,
we just want it to fail and exit with an error message. We don’t want to have to
check for errors.</li>
<li>Open a file in a system independent way. (ie, open() on a PC is different from open() on
Unix which is different from open() on an Amiga. We have EIO_ReadOpen and EIO_WriteOpen
and just so we don’t have to remember the word order we also have EIO_OpenRead and
EIO_OpenWrite</li>
</ul>
<p>These libraries are far from perfect especially since they have been updated for many
years. There is still code in them for things we needed in 1990.</p>
<p>We learned many things on the way. One of the biggest is never use a common name. For
example calling something a "Point" pretty much guarantees that someday
you’ll have to change that code when you try to use some example 3D program you found
on the net with your libraries because they also declared a type called Point.</p>
<p>Another example, having a define called DEBUG, TEST, WIN, MAC, WINDOWS, WIN, USA,
JAPAN, FINAL, STATUS, X, Y, Z, ROM, will almost surely clash with somebody someday. The
easiest solution we found is to use a prefix.</p>
<p>We find these libraries very useful no matter where we are working or who we are
working for, yet they are our libraries and as such, when we are working for somebody else
they get tense about us using them. They feel if they don’t own them outright somehow
that sets them up for losing out in someway even though we’ve assured them they can
do anything they want with them.</p>
<p>So, in the self-interest of wanting to be able to use our libraries when and where we
please we are making them copyrighted freeware. That means the copyright stays with us but
anybody can use them royalty free and without restriction. We are not doing this to help
others with cool routines. We are doing this solely out of self-interest. It sucks to have
to re-write code. Our libraries make us more efficient and so we want to use them. This
should allow us to use them anywhere unrestricted. </p>
<p>For those people that just don’t get it and still feel they need to own the code
if it is used in their product consider these facts. You don’t own the code to the C
library that came with your compiler nor do you own the startup code that gets linked into
your program to start it nor do you own libraries like MFC, STL, OpenGL or DirectX some or
all of which you are using in your code. Yet somehow that doesn’t seem to bother you.
Please consider our libraries to be exactly the same as those. If you want to use them go
ahead and use them and don’t worry about it.</p>
<p>You are free to download them and see if there is anything useful in them that you
would like to use. Please do not ask us to support them. That is not why they are here.</p>
<b>
<h3><a name="interesting"></a>What's Interesting here?</h3>
</b>
<p>These tools and libraries started in the early 1990 so some parts of it are
more relevant to today then others. The parts you might find interesting</p>
<h4>Most Interesting:</h4>
<ul>
<li>The Echidna Data Linker. Links together complex data for easy
loading into a game</li>
<li>The GF tools, gfxinout, gfshrink, gfpal. These 3 tools can for
example make mips for textures and palletize them including having one palette
across mips. Sample a thousand images, make a one palette for all of
them, then remap all the images to use that palette.</li>
<li>File format functions. In the libraries there are functions for
reading various graphic formats. .PCX, .PSD, .PIC, .TGA, .IFF. Check out
the functions in READGFX.H</li>
</ul>
<h4>Mildly Interesting:</h4>
<ul>
<li>EIO.c / EIO.h this part of the libraries deals with IO across
platforms including path manipulation, copying files, reading folders.
As there is no consistent standard we wrote our own so our tools can be
platform independent.</li>
<li>Definer. A solution to the problem of having separate header files
for 2 or more different languages but that have to remain in sync. For
example keeping your constants in sync and available to both C and assembly.</li>
</ul>
<h4>Less Interesting</h4>
<ul>
<li>Cutbytes. It's a simple program but sometimes when you are trying to
hack something apart it can be easier to just cut it up using a simple tool
like this.</li>
<li>Argparse.c/Argparse.h. It's our solution to argument parsing.
Handles multiple arguments per field and passing the arguments in by files to
get around the limits some system have with long command lines.</li>
<li>Maclang.cpp/Maclang.h. A simple text based macro expansion language
that can be applied to any string.</li>
<li>Readini.c/Readini.h. Functions to read windows style .ini files.
Can make it easy to make configuration files for example.</li>
<li>Ensure.c/Ensure.h For examples of making your own printf and
printing it's results to the VC++ debugger's output pane (see EL_printf())</li>
</ul>
<h3><a name="utilities"></a>Utilities</h3>
<p>There are also several utilities written with these libraries that we find useful.
Consider them the same as the libraries. They are also copyrighted freeware. Use them if
you find them useful, take some code out of them and stick them in your code, you have our
permission.</p>
<p>A lot of them were written back in the DOS days. Currently we do most of our scripting
in Perl so there isn't as much of a reason for things like sizefile, longest, change,
newer and riteargs but you might get some ideas for your own scripts by reading what they
do.
</p>
<p>Examples of some of the utilities:</p>
</font>
<dir>
<table CELLSPACING="0">
<tr>
<td WIDTH="16%" VALIGN="TOP"><font SIZE="2">Bin2list</font></td>
<td WIDTH="84%" VALIGN="TOP"><font SIZE="2">Copies a bunch of files into one file with
offset pointers to them as a header table at the top of the file or as constants in a
separate file.</font></td>
</tr>
<tr>
<td WIDTH="16%" VALIGN="TOP"><font SIZE="2">Bump</font></td>
<td WIDTH="84%" VALIGN="TOP"><font SIZE="2">Increments a version number in a .c/.h file</font></td>
</tr>
<tr>
<td WIDTH="16%" VALIGN="TOP"><font SIZE="2">Change</font></td>
<td WIDTH="84%" VALIGN="TOP"><font SIZE="2">Searches and replaces text. <p>Only simple
search and replace, no fancy expressions</font></td>
</tr>
<tr>
<td WIDTH="16%" VALIGN="TOP"><font SIZE="2">Copyframes</font></td>
<td WIDTH="84%" VALIGN="TOP"><font SIZE="2">Copies a bunch of files in alphabetical order.<p>This
was useful for copying files to the DPS Perception video card because if you used Windows
to copy the files they might not get copied in alphabetical order and the card didn’t
like that when assembling a new video.</font></td>
</tr>
<tr>
<td WIDTH="16%" VALIGN="TOP"><font SIZE="2">Cutbytes</font></td>
<td WIDTH="84%" VALIGN="TOP"><font SIZE="2">Copies a specified number of bytes out of a
file starting at a specified offset</font></td>
</tr>
<tr>
<td WIDTH="16%" VALIGN="TOP"><font SIZE="2">Definer</font></td>
<td WIDTH="84%" VALIGN="TOP"><font SIZE="2">Generates .h,.inc and other types of files
based on a .def (definition) file and an input file.<p>The most common use for this would
be to have one .d header file to define a structure and then have definer generate the .h
and .inc files for C and assembly language. This prevents a common programming error where
you change a structure or constant on your .h file but forget to change it in your .inc
file and then spend hours or days trying to find the bug.</p>
<p>This is also useful for generating .c/.h files from tables so for example of you want
to make a table of monsters you can make a .md file and have definer generate a .c, .h,
.inc files that have both the table and constants created. That way you only have to edit
one file (.md) instead of 3 files when adding a monster to your game.</font></td>
</tr>
<tr>
<td WIDTH="16%" VALIGN="TOP"><font SIZE="2">Echecksize</font></td>
<td WIDTH="84%" VALIGN="TOP"><font SIZE="2">Adds up the sizes of a bunch of files and
returns an error if they are over a certain size<p>This is useful in a build process were
you want to make sure the total size of some data is not larger than some specified size.
For example you want to make sure all your sounds are not more than 512K.</font></td>
</tr>
<tr>
<td WIDTH="16%" VALIGN="TOP"><font SIZE="2">Ecompare</font></td>
<td WIDTH="84%" VALIGN="TOP"><font SIZE="2">Does a binary compare of two files and returns
error if they are different.<p>Useful in a build process for checking if something
actually changed. For example, lets say you create a new palette and then all of your
graphics need to be remapped. Well instead you could keep a copy of the old palette,
generate the new palette, then use ecompare. If the new palette happens to be the same as
the old palette then you don’t need to re-map all your graphics.</font></td>
</tr>
<tr>
<td WIDTH="16%" VALIGN="TOP"><font SIZE="2">Egetsetdate</font></td>
<td WIDTH="84%" VALIGN="TOP"><font SIZE="2">Copies the date from one file to another</font></td>
</tr>
<tr>
<td WIDTH="16%" VALIGN="TOP"><font SIZE="2">Eggsfilt</font></td>
<td WIDTH="84%" VALIGN="TOP"><font SIZE="2">Converts a C / C++ file from DOS/Unix/Mac
style to the native or specified style.<p>In otherwords if you run it on DOS it will
default to converting the file to DOS. That means changing the line endings to DOS style
endings and changing #includes from</p>
<p>#include <echidna:utils.h></p>
<p>or</p>
<p>#include <echidna/strings.h></p>
<p>to</p>
<p>#include <echidna\strings.h></p>
<p>While at the same time keeping the date the same as the original</font></td>
</tr>
<tr>
<td WIDTH="16%" VALIGN="TOP"><font SIZE="2">Elcopy</font></td>
<td WIDTH="84%" VALIGN="TOP"><font SIZE="2">Copies a directory tree with options to copy
only newer files and files that don’t exist in the destination.<p>It doesn’t
fail on exit. This is useful for copying a very large directory on a regular basis like
backing up your entire project from one server to another every night.</font></td>
</tr>
<tr>
<td WIDTH="16%" VALIGN="TOP"><font SIZE="2">Etap</font></td>
<td WIDTH="84%" VALIGN="TOP"><font SIZE="2">Same as unix tap. Copies stdin to a file and
to stdout</font></td>
</tr>
<tr>
<td WIDTH="16%" VALIGN="TOP"><font SIZE="2">Fixlines</font></td>
<td WIDTH="84%" VALIGN="TOP"><font SIZE="2">Converts line ending from DOS/Unix/Mac to the
native or specified format.</font></td>
</tr>
<tr>
<td WIDTH="16%" VALIGN="TOP"><font SIZE="2">Hexdump</font></td>
<td WIDTH="84%" VALIGN="TOP"><font SIZE="2">Prints a Hexdump of a file with various
options for BYTE, WORDs, LONGs etc.</font></td>
</tr>
<tr>
<td WIDTH="16%" VALIGN="TOP"><font SIZE="2">Largest</font></td>
<td WIDTH="84%" VALIGN="TOP"><font SIZE="2">Checks the size of a file and if it’s
larger than the size saved in another file it updates that size.<p>In other words you can
use it to generate a constant the size of the largest file. For example if you want to
allocate a buffer the size of the largest image you could run all images through largest
during your build processes and then use the result to allocate your buffer.</font></td>
</tr>
<tr>
<td WIDTH="16%" VALIGN="TOP"><font SIZE="2">Makelib</font></td>
<td WIDTH="84%" VALIGN="TOP"><font SIZE="2">Makelib splits a .C/.CPP file into a bunch of
temporary files by looking for lines that start with "/**# MODULE". The area
before the first "/**# MODULE" and areas that start with "/** GLOBAL"
are put in all temporary files. This allows you to create a library using one file but
have it split up by routine so that when you link you get only those routines you actually
use. Since the time this was written, some compiler companies do this for you
automatically. Unfortunately I don’t think Microsoft is one of them yet.</font></td>
</tr>
<tr>
<td WIDTH="16%" VALIGN="TOP"><font SIZE="2">Makelist</font></td>
<td WIDTH="84%" VALIGN="TOP"><font SIZE="2">Makes a list based on a word table.<p>Example.
You have a file that looks like this (myspecfile)</p>
<p>Explosion d:\sound\exl2.wav 44k<br>
Engine d:\sound\grrr.wav 22k looping<br>
Cough d:\sound\cgh43.wav 22k<br>
Crash d:\sound\crsh.wav 11k</p>
<p>You have another that looks like this (mywordfile)</p>
<p>Engine<br>
Crash</p>
<p>If you run makelist like this:</p>
<p>Makelist myspecfile "nothing 0k" mywordfile myresult</p>
<p>Then myresult will look like this</p>
<p>Nothing 0k<br>
d:\sound\grrr.wav 22k looping<br>
Nothing 0k<br>
d:\sound\crsh.wav 11k</font></td>
</tr>
<tr>
<td WIDTH="16%" VALIGN="TOP"><font SIZE="2">
<a href="mkloadob.html">Mkloadob</a></font></td>
<td WIDTH="84%" VALIGN="TOP"><font SIZE="2">Takes a "linker file" and builds a
loadable binary file with lots of pointers that need to be fixed up :-)</font></td>
</tr>
<tr>
<td WIDTH="16%" VALIGN="TOP"><font SIZE="2">Mutate</font></td>
<td WIDTH="84%" VALIGN="TOP">Renames files using numbers.<p>This was used to solve the
problem that some 3D program numbered frames 0,1,2,...9,10,11...,99,100,101 which means
they didn't actually sort correctly. Mutate was used to change them to
0001,0002,...0009,0010,0011 etc.</td>
</tr>
<tr>
<td WIDTH="16%" VALIGN="TOP"><font SIZE="2">Newer</font></td>
<td WIDTH="84%" VALIGN="TOP"><font SIZE="2">Checks if one file is newer than another. Used
in batch files to check for dependencies except now I use Perl instead </font></td>
</tr>
<tr>
<td WIDTH="16%" VALIGN="TOP"><font SIZE="2">Parallel</font></td>
<td WIDTH="84%" VALIGN="TOP"><font SIZE="2">Creates parallel arrays from tabular data</font></td>
</tr>
<tr>
<td WIDTH="16%" VALIGN="TOP"><font SIZE="2">Riteargs</font></td>
<td WIDTH="84%" VALIGN="TOP"><font SIZE="2">Writes arguments to stdout and interprets C
style escape sequences</font></td>
</tr>
<tr>
<td WIDTH="16%" VALIGN="TOP"><font SIZE="2">Sizefile</font></td>
<td WIDTH="84%" VALIGN="TOP"><font SIZE="2">Writes the size of one file as text into
another.<p>Useful for computing the exact size needed for a buffer at compile time.</font></td>
</tr>
<tr>
<td WIDTH="16%" VALIGN="TOP"><font SIZE="2">Gfxinout</font></td>
<td WIDTH="84%" VALIGN="TOP"><font SIZE="2">Converts images to and from .PSD, .PCX, .TGA,
.GFF (gff is our internal format)</font></td>
</tr>
<tr>
<td WIDTH="16%" VALIGN="TOP"><font SIZE="2">Gfshrink </font></td>
<td WIDTH="84%" VALIGN="TOP"><font SIZE="2">Shrinks a .GFF file</font></td>
</tr>
<tr>
<td WIDTH="16%" VALIGN="TOP"><font SIZE="2">Gf16bit</font></td>
<td WIDTH="84%" VALIGN="TOP"><font SIZE="2">Converts a .GFF file to a raw 16 bit per pixel
file</font></td>
</tr>
<tr>
<td WIDTH="16%" VALIGN="TOP"><font SIZE="2">Gfpal </font></td>
<td WIDTH="84%" VALIGN="TOP"><font SIZE="2">Converts a .GFF file to a paletted file with a
zillion options.<p>There are options to:<ul>
<li>create a palette</li>
<li>use an existing palette</li>
<li>disallow some colors from being used</li>
<li>allow only some colors to be chosen</li>
<li>dither when converting</li>
<li>output in different formats</li>
</ul>
</font></td>
</tr>
</table>
</DIR>
<h3><a name="arguments"></a>Arguments and Response files:</h3>
<p>All utilities that use the echidna argument parsing functions can take response files.
If you use an @ sign on the command line the tool will read each line in that file as part
of command line. Since it is parsing it as a command line that means that if it encounters
another @ symbol inside that file it will start parsing that file also. This is most
useful for passing lots of arguments to programs like bin2list and echecksize. Example:
<pre>
--file-everylevelstuff.arp--
;
; these files need to be in every level
;
%myprojectdatadir%\mainpalette.pal
%myprojectdatadir%\statusbar.img
%myprojectdatadir%\player.img
--file-level1.arp—
;
; these files are used in level 1
;
%myprojectdatadir%\level1tiles.img
%myprojectdatadir%\level1snds.snd
</pre>
<p>Now, you can run bin2list like this
<pre>
Bin2list level1.dat @%myprojectdatadir%everylevelstuff.arp
@%myprojectdatadir%\level1.arp
</pre>
<p>As you can see you can use multiple response files and environment variables will get
expanded. (Note: Environment variables can also get expanded in our .INI file routines).
You can also use a semicolon for comments.</p>
<p>The argument routines decide which "argument position" to assign your
arguments to by filling them in from left to right. For example if you have a program that
takes an INFILE and an OUTFILE and you supply two arguments then the first argument will
go to INFILE and the second to OUTFILE. Arguments can be forced to a particular argument
position by prefixing it with the name of the position. Example:</p>
<pre>
Myprogram OUTFILE mynewfile INFILE myoldfile
</pre>
<p>Or</p>
<pre>
Myprogram OUTFILE=mynewfile INFILE=myoldfile
</pre>
<p>This is important especially in programs that can take multiple files in multiple
positions. In order for the program to know which position to put your arguments you may
have to prefix all arguments. For example of you had a program called imageprocess that
could take multiple files in for both images and palettes and you wanted to use a response
file it might need to look like this:
<pre>
INFILE=myimage1.tga
INFILE=myimage2.tga
INFILE=myimage3.tga
PALETTE=mypalette1.pcx
PALETTE=mypalette2.pcx
PALETTE=mypalette3.pcx
</pre>
<p>And then you might run the program like this</p>
<pre>
Imageprocess @response.arp myoutfile
</pre>
<h3>Notes about utilities and libraries</h3>
<p>As we are usually using these libraries on someone else’s behalf as well as ours
we expect that minor updates to them will not be considered proprietary to the company we
are working for at the time.</p>
<p>Expect us to update them from time to time though not often. Some examples, there are
still some defines and names that are too generic that need to be changed. For example
ERRORS should be changed to EL_ERRORS and GetLine() could be changed to EL_GetLine or
INI_GetLine etc. If we start using a new platform expect us to add support to these
libraries. If we run into another image format that we have to read/write expect it to get
added. Now that we are using C++ expect C++ classes for strings, lists, maps, arrays etc.
(unless someone can teach me STL :-)</p>
<h3><a name="reason"></a>What are the benefits of proprietary utilities vs the costs?</h3>
<p>Well that depends on what your goals are. For most game companies that goal should be
to make great games (and with the least amount of money). I worked for at least one
company that didn’t take that goal into consideration when setting their utility
policy. They had an image processing utility. It ran from the command line and was script
driven and would convert images to several target formats with lots of various and useful
options specifically for games. Yet they would not let anybody outside of the company use
that tool including outside developers working for them. In their mind this utility was a
competitive advantage that they couldn’t afford to let others see lest they develop
something similar. But wait a minute, name one game company that doesn’t have image
processing tools? You can’t! Why, because it’s impossible to make a game without
them. Any and every game company will have image processing tools. If you hire an outside
developer who doesn’t have them or doesn’t have some that will generate data for
the target platform he will have to write them.</p>
<p>Now back to our goal. You’ve hired an outside developer and given him 9 months to
make a simple game for you. You have image processing tools. You have two choices: (1)
Make him write his own image processing tools. Result: He spends 1 month writing image
processing tools and 8 months making your game. (2) You let him use your tools. Result: He
gets 9 months to write the game meaning in case 2 the game will have 1 more month of
polish, or one more month of features or one more month of levels etc. Which policy meets
your company’s goals better?</p>
<p>Now expand that to include other tools. Maybe your company has sound tools or a sound
library or level editing tools or 3D character exporting tools etc. Every tool/utility you
can supply gives your developer that much more time to spend on the actual game instead of
tools. Not giving him the tools means he had to write is own which means that not only did
you not protect any technology (since he now has the same tools even if you think yours
are cooler) but ultimately you screwed yourself by getting a worse game and hence worse
sales than you could have.</p>
<p>Now I’m not saying you should give your tools away publicly like we are here.
I’m saying that you should always think of what makes your bottom line: "I can
make the most money by creating great games." Now, every decision should be based on
will it make the game BETTER! If sharing your tools will make the game better then DO IT!
"Trade Secrets" do not help you make money if the way you make money is by
making GREAT games. </p>
<p>This partly explains why we made our libraries public. Our goals are also to make great
games. Since we work for various different companies, in order to spend more time making
games and less time writing utilities it’s important that we be able to use our
existing libraries and utilities. If we kept them proprietary then we couldn’t use
them. That would hurt nobody but us. Since it is not practical for us to market, sell and
support these tools, we are not losing money by making them free but we are allowing
ourselves to work more efficiently wherever we are.</p>
<h3><a name="instructions"></a>Instructions:</h3>
<p>These are very brief and probably incomplete.</p>
<p>On any platform you install the libraries you will need to set the environment variable
ELIBS equal to the path to the directory of the libraries. Example: You installed them in
d:\work\elibs then</p>
<pre>
set ELIBS=d:\work\elibs
</pre>
<p>In unix CSH (currently Irix only)</p>
<pre>
setenv ELIBS ~/work/elibs
</pre>
<p>Every .c/.cpp/.h file must have at the top</p>
<pre>
#include "platform.h"
#include "switches.h"
#include <echidna\ensure.h>
</pre>
<p>The header file "platform.h" in your local directory should look like this</p>
<pre>
#include <echidna/platform.h>
</pre>
<p>There needs to be a switches.h in your local directory. I can be empty but you can use
it to set the following switches.</p>
</font>
<table CELLSPACING="0" BORDER="0" CELLPADDING="7" WIDTH="568">
<tr>
<td WIDTH="33%" VALIGN="TOP"><font SIZE="2">EL_NO_ENSURE</font></td>
<td WIDTH="67%" VALIGN="TOP"><font SIZE="2">There are a bunch of macros we call ENSURE
macros (ensure.h). They are very similar to the ASSERT macro that C has but ours print
more information and can be compiled out if this switch is set to 1</font></td>
</tr>
<tr>
<td WIDTH="33%" VALIGN="TOP"><font SIZE="2">EL_DEBUG_MESSAGES</font></td>
<td WIDTH="67%" VALIGN="TOP"><font SIZE="2">There are several macros for printing
diagnostic messages (dbmess.h). Setting this to 1 will turn them on. Do not use these for
printing errors for the user as they will print too much information depending on the
settings.</font></td>
</tr>
<tr>
<td WIDTH="33%" VALIGN="TOP"><font SIZE="2">EL_USE_FUNC_NAMES</font></td>
<td WIDTH="67%" VALIGN="TOP"><font SIZE="2">The ENSURE macros have the option to print the
current function by setting this to 1</font></td>
</tr>
<tr>
<td WIDTH="33%" VALIGN="TOP"><font SIZE="2">EL_CALLTRACE_ON</font></td>
<td WIDTH="67%" VALIGN="TOP"><font SIZE="2">The ENSURE macros have the ability to print
the entire call stack if this is set to 1. You must use the BEGINFUNC/ ENDFUNC/ BEGINPROC/
ENDPROC macros and you must use them consistently in order for this to work.</font></td>
</tr>
<tr>
<td WIDTH="33%" VALIGN="TOP"><font SIZE="2">EL_DEBUG_MEMORY</font></td>
<td WIDTH="67%" VALIGN="TOP"><font SIZE="2">The memory routines can print
allocation/de-allocation info as well as attempt to track memory over writing, double
freeing, etc if this is set to 1.</font></td>
</tr>
<tr>
<td WIDTH="33%" VALIGN="TOP"><font SIZE="2">EL_ERRORS_OFF</font></td>
<td WIDTH="67%" VALIGN="TOP"><font SIZE="2">Many routines use the error reporting
mechanism in eerrors.h. Setting this to 1 turns the messages from those errors off.</font></td>
</tr>
</table>
<p>To build the libraries:</p>
<p>From Windows VC++ 5.0 load the project in <installdir>/lib/echidna and compile
it. You must have added <installdir>inc to your include path in the configuration
settings in VC++. To build any of the utilities you will need to also put
<installdir>/lib in your library path.</p>
<p>From an SGI go to the <installdir>/lib/echidna directory and type ‘make
–f makefile.sgi’</p>
<p>That’s about it. The rest, you’re on your own.</p>
<h3><a name="license"></a>License: (New-BSD)</h3>
<p>Copyright (c) 2001-2008, Echidna</p>
<p>All rights reserved.</p>
<p>Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the following
conditions are met:</p>
<ul><li>Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer. </li>
<li>Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer
in the documentation and/or other materials provided with the
distribution. </li></ul>
<p>THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.</p>
<h3>Echidna is:</h3>
<blockquote>
John Alvarado<br>
Dan Chang<br>
Greg Marquez<br>
<a href="http://greggman.com/">Gregg Tavares</a>
</blockquote>
</font>
<h3><a name="download"></a>Downloads:</h3>
<p>The latest versions are available on github
<a href="http://github.com/greggman/elibs/">here</a>.</p>
</body>
</html>