RE: Introduction & Question

Just to springboard off those thoughts...

In the Major Havoc source (6502 Assembler, not C in 1981-1983), the code
is a crazy hot mess (respectfully of course!). I suppose that is what
you get when a project goes on for an extended period, has multiple
programmers (Owen + Mark, plus standard Atari Libraries (coin routines,
Vector Generator, etc(=) from Ed Logg and the brand new RPM module
"Rusty's Pokey Music") and several hardware revisions (3 CPU's at one
point, Speech, ROM Paging).

It is sort of funny because when I was a teenager, I learned everything
in Assembly Language (hurray for global variables!) and Object Oriented
Programming always seemed like a mysterious 'backwards' way of doing
things. Now that I have been doing OOP for 12+ years, looking back on
the raw assembly language, I can't even comprehend how to prevent a
litany of bugs due to overlapping memory blocks, bad offsets or scope
clobbering for temp variables.... whoa Nellie, it is a totally different
way of looking at things and not a fun set procedures to try and track
down problems.

We all have mostly lived in both worlds... it will be interesting to see
how the younger generation of programmers deal with that old code
someday! I wonder if they even will? It may be a lost art at this point
ehh?

-----Original Message-----
From: owner-vectorlist@vectorlist.org
[mailto:owner-vectorlist@vectorlist.org] On Behalf Of Neil Bradley
Sent: Monday, May 21, 2012 12:55 AM
To: vectorlist@vectorlist.org
Subject: Re: VECTOR: Introduction & Question

> Oh man, I'd love to see the source for that! I always regarded marble
> madness pretty highly back when I had it on NES. It always felt so
> much more high-tech and polished than other games. Stuff had shadows
> (fake ones, but they looked real to me back then!) and the ball felt
> like it moved pretty realistically.

Well, yes, I have Marble Madness, but as you can probably guess, I'm
under NDA and can't give out the source. It's also missing the "OS" part
(more of a BIOS/set of functions than an actual OS - linked with the
code) so it really wouldn't do a lot of good without a LOT of work. And
no 6502 code, either.

What I can tell you about it is that it looks like
straightforward/competent C. Odd that most everything is one module per
function which I haven't seen done in practice in a long time. It has
some pretty cool routines for dealing with collision as well. It's like
a lot of C of that era.

I dunno. Seeing all these games in practice, I've always envisioned that
the code for them is somehow this magical holy grail where I'd read it
and inherit the power of the gaming gods. While there definitely are
some interesting tricks, it's all fairly straightforward code and not as
spectacular as you might think.

-->Neil

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

----
C. Neil Bradley - Excessive process falsely elevates the incapable and
ties
                   the hands of the exceptional.
------------------------------------------------------------------------
---
** Unsubscribe, subscribe, or view the archives at
http://www.vectorlist.org
** Please direct other questions, comments, or problems to
chris@westnet.com
---------------------------------------------------------------------------
** Unsubscribe, subscribe, or view the archives at http://www.vectorlist.org
** Please direct other questions, comments, or problems to chris@westnet.com