Files
TeslaRel410/BORLAND/BC45/EXAMPLES/OWL/GAMES/METEOR/README.TXT
T
CydandClaude Fable 5 63312e07f9 source410: literal 4.10 source reconstruction + BC++ 4.52 fleet toolchain archived
- BORLAND/: Borland C++ 4.52 (chosen over 4.5 by byte-match: CODE/RP/CW32.LIB
  is identical to 4.52's install lib). BCC32/TLINK32/TLIB/MAKE run natively on
  Win11; CODE/BT/OPT.MAK is the shipped BTL4OPT.EXE's exact flag recipe
  (extender = Borland PowerPack DPMI32, not Phar Lap TNT).
- restoration/source410/: the literal 1995-form reconstruction of the missing
  BT game source (never mixed into CODE/). Round 1-3 state:
  * 6 of 10 surviving original TUs COMPILE CLEAN under the period toolchain
    (BTMSSN, BTCNSL, BTSCNRL, BTTEAM, BTL4MODE, BTL4ARND) - first builds
    since 1996.
  * BT_L4/BTL4APP.CPP pilot reconstruction: 12/12 functions, Fail() lands on
    its binary-recorded line 400 exactly.
  * BT/BTCNSL.HPP: console wire IDs recovered from the binary's ctors
    (Killed=9, Damaged=10, ScoreUpdate=13, DeathWithoutHonor=15 [T1];
    TeamScore=12 flagged [T4]).
  * MUNGA/: 8 engine-header backfills back-dated from the BT412 WinTesla tree
    (VDATA numbering decomp-verified; AUDREND's OpenAL-era virtual removed -
    the period compiler is the drift detector).
  * Tooling: backdate.py (WinTesla->1995 header transform), compile410.sh
    (per-TU verification sweep under authentic OPT.MAK flags).
  * README: corrected roadmap - MECH.HPP is the capstone grown with the mech
    TU reconstructions; BTREG.CPP green = the header-family milestone.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-19 07:33:26 -05:00

24 lines
1.0 KiB
Plaintext

Turbo Meteor is a simple example of how to do line-based animation under
windows. There is much room for improvement in this example. The
following are some suggested improvement you can make:
Improved collision detection: currently, Turbo Meteor uses simple bounding
rectangle tests for collision detection. This is fast, but innacurrate.
A faster method would be to use bounding circles for the quick test, and
then a full point-in-polygon test for the final test.
Object type identification: All the sprites are stored in a single list.
This creates a problem when testing for collisions, because we only want
to check for collisions between shots and meteors, not between shots and
other shots. So as we traverse the list, we must query each object to
see what type it is. Currently this is done based on a 'name' member of
each object. This is slow, because it requires a strcmp() call. A better
way would be to either use RTTI, or implement a simple 'type' member which
is an integer instead of a string.