TU-TESTBED READMEThatcher Ulrich <tu@tulrich.com> http://tulrich.comThe tu-testbed is a collection of my game engine experiments.  At sometimes it may resemble an engine with demo programs; at other times itmay resemble a code junkyard.  Most of the time it will probablyresemble both.LICENSEThis code is Public Domain; have a look at LICENSE and MANIFESTO fordetails.  Executive Summary: the code is completely unrestricted, soyou can do whatever you want with it.PLATFORMSMy goal is to have this code work on Linux and Win32.  Linux because Ilike it, and Win32 because it's ubiquitous in game development.  Atany given time one platform or the other is likely to be more up todate, depending on which one I've been using lately.I'm depending on:* The Independent JPEG Group's jpeglib, for jpeg image handling.  This  software is based in part on the work of the Independent JPEG Group.  See http://www.ijg.org for details.* zlib and libpng, for .png bitmap support.  See http://www.zlib.org  and http://www.libpng.org .  Nice stuff!* SDL (see http://www.libsdl.org) for the base set of media APIs and  helper libraries.  SDL is the greatest thing since sliced bread.  It's covers the non-3D functionality of DirectX, but much prettier  and easier to use.  Plus it's open-source, and cross-platform.  It  has many great, free easy to use add-on libraries for dealing with  image and sound media types.  Really, it's great.* Lua (see http://www.lua.org) for the configuration/scripting  language.  Lua is a beautiful tiny thing.  It's one of the most  minimal languages I know of, yet it's extremely readable, powerful  and easy to use.* OpenGL for 3D graphics.  I really like OpenGL; it's practically the  ideal API ideal for GeForce1-level hardware.  SDL wraps much of the  system-specific OpenGL stuff, which is always the worst part of  dealing with it.  I also have some helpers in the engine to make it  easier to use extensions.* GNU Make as a build tool on all platforms.  I despise the mess that  is MSVC's .dsp, and avoid it if I can help it.  I did some  experimenting with Jam/MR, and decided it was too hard to use, and  mostly a solution to a non-problem.  There's an interesting article  here: http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html  about how to make efficient makefiles without recursively calling  make, although I haven't applied its advice yet in this project.* Cygwin under Win32 for a sane development environment.  I don't  really want to become too Cygwin-dependent for building under Win32,  since most Win32 people probably don't have it installed.  But then  again, I don't want to struggle too much with awkward, incomplete  and Windows-specific tools.  Cygwin is pretty darn good; besides the  usual Unix amenities, it includes power tools like rsync and ssh  that are just too useful not to have.* gcc as the main compiler, and MSVC under Windows.  I would like to try  gcc/mingwin under Windows at some point.LANGUAGEThe code is written mostly in C++ at the moment.  For various reasonsthat I won't go into right now, I think it's high time to retire C++before it rots my brain any further.  The big problem is, what to useinstead?* OCaml?  The compiler is good, free and cross-platform.  The language  incorporates some fancy ideas.  On the downside, the syntax is  absolutely bizarre and very non-intuitive to this C++ coder.  Also,  it seems to me that a certain amount of practicality was sacrificed  in the name of type-system purity.  For example, structs don't  define their own namespaces, so member names have to be  disambiguated somehow, typically with an old-skool name prefix.  This lets types always be combined cleanly and without ambiguity,  but let's face it, that's not such a useful feature in workaday  coding, that it makes up for the namespace thing.  Tradeoffs that  sacrifice practicality for ideology are guilty until proven  innocent, in my book.* Common Lisp?  It's big and ugly like C++, so it probably has the  necessary features.  On the other hand, is it better enough to make  it worth all the pain of interfacing to a C/C++ world?  My guess is  probably not, but I don't really know.* Dylan?  It has a free implementation in Gwydion Dylan; not sure how  mature it is.  I'm absolutely not interested in any language which  doesn't have a good free implementation.  Dylan, to me, looks like  Common Lisp given a makeover by someone concerned with some mundane  issues like syntax friendliness, and interfacing to C.  So that's a  good sign.  May be worth a closer look.* Perl?  Great for quick prototyping.  I really love Perl, but it's  too messy and too idiosyncratic for code I want to see reused by  others, who might not share my subset of Perl fluency.  Also,  obviously, dynamically typed and interpreted, so it's probably too  slow for much of the stuff I'm interested in.* Python/Lua?  I consider these together, for the purposes of this  rant.  They both have many of the virtues of Lisp and Perl, but with  accessible syntax and less cruft.  The main drawbacks are  interfacing to C/C++, and being dynamically typed & interpreted. * Java/C#?  OK, but not enough better/different than C++ to inspire a  switch.* C++ subset du jour?  I have a wary respect/fear/infatuation with  templates.  Templates, awful as they are, may be the killer feature  that every language has to eventually emulate.  I think the "Right Way" to do templates is to provide hygenic  macros, with full compile-time type awareness, without deviating too  much from the basic syntax of the underlying language.  People are  struggling to use templates to implement compile-time  program-transforming programs.  The fact that they continue to do  this, despite how awkward it is, shows how valuable the basic  feature is.  So essentially I want to arbitrarily extend the  compiler, in the same language the compiler compiles.  This sounds very Lisp-y; I'm sure Lisp geeks will insist that Lisp  did all this circa 1985.  Maybe the pitfall here is a classic Lisp  achilles heel: once you have a compiler that can do all that, it  becomes so intertwined with the execution environment, that you  can't ship a product without also shipping the compiler/environment  somewhere inside it.  Maybe where Lisp goes wrong is by insisting on  so much dynamicness & interactivity; if all the fancy compiler work  can only happen at compile-time, it should be tractable to have  full-powered introspective macros.  I bet we'll see C++ extended to make templates much more powerful  and direct, before any other language gets this feature  substantially right.  Scary.* ANSI C?  I ponder this sometimes.  I think I'm too addicted to  structs and namespaces and // though.I really enjoy dynamic typing & interactive programming.  I think mydream language for all seasons would be Lua, extended with optionalstatic typing, hygenic macros, and a good native-code compiler.  Doesthis roughly describe Dylan?  Hm.Or maybe, C++ with a really good seamless library for dynamic typesupport and painless GC.  And a more interactive programmingenvironment.For the forseeable future, I'll probably just continue using C++ withLua as an extension language.[I think I've finally decided to stop worrying and love C++: likedemocracy, it's terrible but the alternatives are much worse.]STABILITYThis is experimental code.  One of the things I will probably want toexperiment with is engine APIs and organization.  As a result,stability of APIs is a low priority for me at this early stage ofdevelopment; I may completely change the organization of the code atany time, run all the source through Perl one-liners to change all themodule names, etc.  Old demos may not build or run.  Engine featuresmay be completely broken, or incompletely working (or more likely,completely missing).If you use this code, it may be most helpful to take a snapshot andhave your own private fork of the code, or just cut-n-paste the bitsyou want.  Someday in the far-off future I can imagine the enginestabilizing and having release numbers and such, but don't hold yourbreath.CONTRIBUTIONSI would love to get contributions, provided the author is willing andable to place them in the Public Domain.  I'll put your name on thecontributors list unless you don't want that.  Bug fixes & reports arealways appreciated; likewise with ports.  However, I reserve the rightto not use your contribution, to break ports etc.  It's important tome to be able to experiment at whim as much as possible so ifsomething gets in the way I'm liable to remove it.CODING STYLEAnother thing I'm experimenting with is coding style.  So it'sinconsistent, which is the one thing everybody says not to do :) Well,I'm still striving for the One True Style, so sorry about that.  Itwould be good if contributions attempted to conform to nearby code, orthe style du jour.  Don't sweat it too much though.  See the STYLE docfor more info.