Generic Maze Program Example 1

---[ Generic Maze Program Example 1 ]-----------------[09/27/2009]---

by Timothy Trussell

---------------------------------------------------------------------

---[Note]------------------------------------------------------------
This code is meant for use with the 32Forth system.
This is the DOS DPMI version of the compiler in Rick van Norman's
OS2FORTH.ZIP package, available on the Taygeta Scientific site:

ftp://ftp.taygeta.com/pub/Forth/Compilers/native/OS-2/os2forth.zip
--------------------------------------------------------[End Note]---

I came across this code when I was examining different methods of
trying to display polygons using different methods. In this case, it
was the concept of Ray Tracing that I was looking into, and things
like the painters algorithm, which led into looking at things like
Wolfenstein3D and DOOM.

The original code for this was done by Larry Myers, who had posted it
looking for help on problems he was encountering with his code. He
called it his "Wolf-3D Generic engine", and after looking at it, you
will agree that it's pretty generic.

This is simply a straightforward conversion, to allow me to look at
some of the different aspects of the code. It is NOT expected to be
fully functional, let alone without bugs or other problems, and the
things that Larry was looking for help with are (I expect) still in
place, waiting for some help.

There are any number of changes that would need to be effected to let
this code become useable for anything beyond what it currently does.

At the moment, it's depressingly slow. Really. Normally, I have to
put into place calls to a wait-for-retrace routine to intentionally
slow down the animation speeds to let them be viewed at a proper rate
but not this little gem.

I have to attribute part of this this to a bottleneck in the fill
routine that Larry used. It appears that his fill routine goes from
left to the right, filling each "polygon" with vertical lines.

I might get adventuresome and recode those for use with a polygon
fill routine that should be a bit more efficient.

On line 387, I have a conditional compilation flag for selecting
the use of a Floating Point processor call to perform a Square
Root calculation (if set to 1 [IF]), or the use of a FORTH code
version (if set to 0 [IF]). Try both, recompiling for each, to
see the difference in speed. To actually see the speed change,
press the #5 key on the numeric keypad.

There are only three assembly routines in this code - the two for
drawing Horizontal and Vertical lines, and the one that blits the
double buffer to the video display screen.

Frankly, the compiled .EXE file that Larry provided runs very much
faster and smoother than my code, though the smoothness may be
because I don't play around with intercepting and recoding the
keyboard interrupt vectors, so the entry of direction commands are
delayed by the BIOS.

In fact, I included a bit of code so that if you press the #5 key
on the numeric keypad the program will do a circle to the left for
a number of calls (6400 actually) to the turn-left function. In this
instance, the program runs pretty smoothly (but still not blazing).

I have some code examples that do more than this, and include the
use of textured fills, and go way too fast for viewing.

The key commands are:

Keyboard control:

Esc - Exits program
Right - Turns right 4 degrees
Left - Turns left 4 degrees
Up - Moves forward 2 units
Home - Moves forward 128 units
PgUp - Moves forward 20 units
End - Moves backwards 128 units
PgDn - Moves backwards 20 units
Center - Spins the viewpoint clockwise with no
input delays

all using the numeric keypad - so ensure you have the NumLock on, as
I am looking for the NUMBERS on the keypad, 1..9.

---[Finishing Up]----------------------------------------------------

So, this represents a stepping stone in learning something more about
graphics that can be done.

------------------------------------------------------[End Maze 1]---

.

Relevant Pages

  • Re: Looking for a free basic compiler for DOS
    ... BC for 7.1 had a lot of compiler switchable options, ... NEVER compile from the ide. ... One trivial example: I have a routine declared as: ... were no manuals, just a readme file. ...
    (comp.lang.basic.misc)
  • Re: SAMBA for VMS (The saga continues!)
    ... > callee (substitute function) code seems small to me. ... determine that the OS routine is now available. ... >>instructions and also disabling the compiler optimizer that you can rely ... they upgrade VMS and then try to install an existing package. ...
    (comp.os.vms)
  • Re: SAMBA for VMS (The saga continues!)
    ... Because it is the only way to prevent conflicts with the compiler ... optimizer and with shared images that may be loaded on any platform. ... This is the case on some modern UNIX platforms and especially on OpenVMS ... they were reserved names as far as global routine names are concerned. ...
    (comp.os.vms)
  • Re: Problem with Return Value from a Function
    ... It was always possible to write an assembly language routine that could be called from PL/I as a function and the location to receive the returned value was passed by reference as an n+1st argument. ... Function references to assembler routines were only possible if the ASSEMBLER option was *not* used, thus the compiler was unaware the the routine being called was an assembler routine and perforce must have compiled the same linkage it would compile when it was calling a routine written in PL/I. ... but I agree that not assigning at all would ...
    (comp.lang.pl1)
  • RE: Capturing last columns letter
    ... Not as bad as you thought Larry. ... message box bit you can simply use the value returned in another routine. ... nifty Property out there somewhere for this purpose, but darn if I've been ... Surely this isn't going to take some gawdawful Select Case ...
    (microsoft.public.excel.programming)
Loading