readme

一个开源的嵌入式flash播放器 具体看文档和例子就可

TU-TESTBED README
Thatcher Ulrich <[e-mail]> http://tulrich.com

The tu-testbed is a collection of my game engine experiments.  At some
times it may resemble an engine with demo programs; at other times it
may resemble a code junkyard.  Most of the time it will probably
resemble both.


LICENSE

This code is Public Domain; have a look at LICENSE and MANIFESTO for
details.  Executive Summary: the code is completely unrestricted, so
you can do whatever you want with it.


PLATFORMS

My goal is to have this code work on Linux and Win32.  Linux because I
like it, and Win32 because it's ubiquitous in game development.  At
any given time one platform or the other is likely to be more up to
date, 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.


LANGUAGE

The code is written mostly in C++ at the moment.  For various reasons
that 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 use
instead?

* 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 my
dream language for all seasons would be Lua, extended with optional
static typing, hygenic macros, and a good native-code compiler.  Does
this roughly describe Dylan?  Hm.

Or maybe, C++ with a really good seamless library for dynamic type
support and painless GC.  And a more interactive programming
environment.

For the forseeable future, I'll probably just continue using C++ with
Lua as an extension language.

[I think I've finally decided to stop worrying and love C++: like
democracy, it's terrible but the alternatives are much worse.]


STABILITY

This is experimental code.  One of the things I will probably want to
experiment with is engine APIs and organization.  As a result,
stability of APIs is a low priority for me at this early stage of
development; I may completely change the organization of the code at
any time, run all the source through Perl one-liners to change all the
module names, etc.  Old demos may not build or run.  Engine features
may 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 and
have your own private fork of the code, or just cut-n-paste the bits
you want.  Someday in the far-off future I can imagine the engine
stabilizing and having release numbers and such, but don't hold your
breath.


CONTRIBUTIONS

I would love to get contributions, provided the author is willing and
able to place them in the Public Domain.  I'll put your name on the
contributors list unless you don't want that.  Bug fixes & reports are
always appreciated; likewise with ports.  However, I reserve the right
to not use your contribution, to break ports etc.  It's important to
me to be able to experiment at whim as much as possible so if
something gets in the way I'm liable to remove it.


CODING STYLE

Another thing I'm experimenting with is coding style.  So it's
inconsistent, which is the one thing everybody says not to do :) Well,
I'm still striving for the One True Style, so sorry about that.  It
would be good if contributions attempted to conform to nearby code, or
the style du jour.  Don't sweat it too much though.  See the STYLE doc
for more info.