[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: eBay WTH?
heuser.marcus@freenet.de wrote:
On Aug 21, 1:49 am, "Terry Olsen" <tolse...@hotmail.com> wrote:
I now use my PC for development (faster and more
comfortable) and the finished product (if it gets finished ;-)
will run well on a 1 MHz machine (that's the one parameter that
is definitely fixed).
Do you develop in an emulator or do you use a cross compiler?
Right now I'm in the spreadsheet of OpenOffice ;-)
You see, I'm not yet in the implementation phase so I've not
decided on this, yet. It's a large game project and I want to
create lots of content first so that I know what I have to write.
Generating *good* content is in my experience much harder than
the actual programming. It won't be a programming sensations like
David's raycaster, anyway, so I'm pretty confident that I can pull
it off. Also I'm not inclined to program lots of code and then
realize that I'm on a completely wrong path. Michael's waste basket
isn't for the code - it's for the ideas ;-)
Sometimes its for the code--in fact, sometimes it's even for the
hardware! The "wastebasket" applies at every level of abstraction
in design.
Sometimes you only learn that a given coding approach is the
hard/big/slow/wrong way to go by going there. Often, you learn
what is important by ignoring it until it bites you.
No matter how much thinking and planning you put into a project,
there will *always* be things that crop up that you either didn't
or couldn't have foreseen that require course changes.
When this happens, you will face a moment of truth: keep the
structure you have expended so much effort on and kludge in the
needed functionality, or throw things out and change it (with
correspondingly more effort) into the system you wish you had
fully foreseen from the beginning.
There are arguments and situations favoring each fork of this
dilemma. In industry, pragmatism usually triumphs and the entropy
of the system grows continually until it is simply unmanageable.
For my own projects, I usually find a way to come back and do it
right, since *how* I did something is as important to me as *what*
I did. ;-)
I just recently discovered a design problem in NadaNet, having to
do with the possibility under some circumstances of having packet
collisions that are undetected, but corrupt some data. If I had
not built the 17-processor AppleCrate II, I probably would never
have seen the circumstance that revealed this failure mode.
The circumstance is a flurry of senders all arbitrating for a
not-completely-busy net and sending a request packet (the only
packet that can experience a collision) that is *almost* identical
to the others, and is--here's the kicker--*synchronized* with the
colliding sender to within three machine cycles!
Needless to say, I was surprised to discover that it was possible.
Since then, I've created a model of the peculiar circumstances and
verified exactly what was going on--and now it's hard to see how I
could have failed to anticipate the possibility! (Of course. ;-)
Fixing it required a simple, but fundamental, change to control
packet format. Fortunately, the original format (1994!) was coded
loosely enough to permit the length to remain the same while adding
the complement of the sender's ID (as well as the "true" form of the
sender's ID), which, if checked, is sufficient to make an undetected
collision impossible.
The downside is that this change is incompatible "on the wire" with
NadaNet 2.x--so NadaNet 3.0 is born!
I've been pleasantly surprised at how easily such a "deep" change
can be made, and how relatively well factored the code is. In fact,
in the process of fixing this and taking the compatibility hit, I
added a new broadcast data request and fixed another latent problem
with broadcast booting on a busy network--all while *reducing* the
size of the code!
Of course, the code size reduction is possible because the original
code had room for improvement. Or, as the design law goes, "You
never get something for nothing unless earlier you got nothing for
something." ;-)
In the past I always lost interest because I didn't have enough
stuff to make it "live". This time it's the other way round and
I'm going slowly but steadily forward.
Although there are excellent arguments for waiting to start coding
until a design is fully worked out (in fact, *I've* occasionally
urged that!), there is also much to be said for getting something
running early, to create something concrete and to inspire further
development.
At some point, it may take some discipline to throw out all the
early code and start over, but it will have served its purpose, and
will have contributed to a better design, as well as to more desire
to continue!
I think I would like to use AppleWin but it's fullscreen mode is
broken (at least in the debugger) and the normal screen size is
too tiny for development.
It's unfortunate that it can't be resized to, say, 2x size... But I
find that development is quite easy even on the small screen. After
all, it's not like there's any more information on a bigger version
of the small screen. ;-)
When I get into "development mode", all the details of the
environment--the screen, the keystrokes, the multiple edits
and recompiles--all disappear in the passion to get the result.
The "rituals" of all the manual steps actually don't bother me
at all. In fact, I think they play the same role as background
music for some developers. ;-)
If I get too tired to keep getting the routine right, then I'm
certainly too tired to keep writing code. ;-)
What do you use to develop for A2 on a PC?
Assembler (I would like to use Merlin because I know and like it
but I think that a cross assembler may be the way I'll have to go)
and Applesoft (mostly for the editors and other tools).
This is what I know good enough and I won't learn a new language
for a single project.
It seems that I have to create some sort of simple scripting
language just to save memory but I this isn't really comparable.
And it is well-supported by Merlin macros, as well. ;-)
For most of the graphics I think "8-16 Paint" (the 8 bit variant)
will be sufficient.
You can see that I'm still right at the start and can't give you a
"code finished" percentage yet but I'm determined.
And no - I won't give any details regarding the content ;-)
I like that--no promises, just deliveries!
-michael
AppleCrate II: An Apple II "blade server"!
Home page: http://members.aol.com/MJMahon/
"The wastebasket is our most important design
tool--and it's seriously underused."