A85: Re: Re: Programming help

[Prev][Next][Index][Thread]

A85: Re: Re: Programming help



-----Original Message-----
From: Justin M Bosch <justin-b@juno.com>
To: assembly-85@lists.ticalc.org <assembly-85@lists.ticalc.org>
Date: Thursday, November 05, 1998 10:08 PM
Subject: A85: Re: Programming help


>
>>You might need to be a little more specific about what sprites you
>>want
>>people to draw for you.  ;-)
>
>I was wondering how much guidance might be needed, so I tried to leave it
>broad at first.  If I could be really desriptive I wouldn't be asking in
>the first place for help, but I will do my best.  I should first say that
>the game might be considered a cross between Donkey Kong and Bomberman,
>if such can be imagined.  Essentially you and an opponent dodge bombs
>that randomly appear on multiple horizontal levels (four, perhaps five in
>a TI-89 port), going up and down between floors.  You can have anywhere
>from two to all four floors occupied by one bomb each, every bomb
>detonating independently of the others.  With four bombs, it is obviously
>necessary to constantly change levels, and two might be considered more
>appropriate for beginners.  Hopefully this will provide some direction to
>anyone willing to help with either the graphics or artificial
>intelligence.  This being my first program, I also have some basic
>questions:
>
>What does the programmer do when the game loops so fast that the
>character is uncontrollable?  Do you just insert a meaningless,
>time-consuming loop at the beginning of the game loop (or the end, or
>wherever)?


Yes, though just a loop is not normally what is used.  A loop with HALTs in
it usually works pretty well, or if only two or three are needed, you can
save space by not looping at all.  The link routines should help the timing,
though.  Remember that interrupts are called approximately 200 times a
second, though I have found (on the 86) that they are called closer to 175
times a second (174 to be exact, but I think the battery level affects
this).  So each halt will delay for up to (depends when the last interrupt
occurred) 1/200th of a second.  So 20 halts would wait ~0.1 seconds...

>
>How do you account for timing differences when running a link connection?
> What I mean is, since the two calculators might execute different
>commads depending on what each person presses, and other factors, how can
>you make sure that the send and receive routines will execute in
>synchronization?  Does one wait for the other?


The two calculators should run at almost the same speed, depending on the
battery level.  If you are using the link routines from ZTetris as I
suggested earlier, then they will automatically sych for you.  The receive
byte will receive a byte immediately if there is one.  The send byte will
wait for a timeout or for a certain keypress before it stops.  In other
words, the send byte routine will wait for the other calc to catch up.  Read
the ZTetris source code for a better explanation/example (where do you think
I have learned everything?  source code!).

>
>I have never understood the whole version number thing.  Obviously the
>first working release is 1.0, but what then from there?  What is worthy
>of a change of a whole number, such as going to 2.0, rather than to, say,
>1.3?


This is left up to the author and most people have their own system.  But
following most major software publishers, a major version number change
would be a completely new product, more or less, meaning that most or all of
it is rewritten from scratch*.  If it is just an update, then usually the
minor number is bumped up (i.e. 1.1 to 1.2).  If it is one or two minor bug
fixes, then it is usually increased by an even smaller amount (i.e. 1.12 to
1.13).  Then you have companies like Microsoft that have versions for each
file like 4.79.1906.  In these cases, the first number is the major version
(complete rewrites), the next is the minor number (updates, bug fixes), and
the last number is the build number(?), meaning how many times it has been
compiled.

Of course, whatever system you use is completely up to you.  The important
thing is to find something that works for you and stick with it, don't
change it every time you release a new program.

*(the most notable exception to this is Microsoft Windows, of course...they
keep all code with bugs in it from the last version [starting with 1.0] and
replace any bug-free code [though bug-free code in a Microsoft product since
DOS hasn't been confirmed yet] with new, bug-ridden code, forcing you to buy
a new OS every few years with even more bugs that requires an even faster
computer and more hard drive space...if DOS ran perfectly on my 4.77Mhz 8088
computer with 64k ram and a 360k 5 1/4" floppy drive, can't they make an OS
that will boot up and run [without crashing every few hours] at least as
fast on my 233Mhz PII with 64m of ram and a 6.4g hard drive?)

>
>I can be sure some of you are laughing right now at that last one, but I
>wonder how many of us actually know.  :-)
>
>Justin Bosch
>justin-b@juno.com
>
>___________________________________________________________________
>You don't need to buy Internet access to use free Internet e-mail.
>Get completely free e-mail from Juno at http://www.juno.com/getjuno.html
>or call Juno at (800) 654-JUNO [654-5866]