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

Re: DRAW & XDRAW... How to use



On Tue, 04 Jan 2000 16:05:46 -0800, jh82
<webmasterNOweSPAM@jh82.i-p.com.invalid> wrote:

>I am in the process of making a huge, graphic fantasy game.  The
>problem I have is that I lost my notes as to how to set up the DRAW &
>XDRAW commands.  I do remember that it involves a ton of POKEs, but I
>can't remember the address to start at, or the byte codes.  I seem to
>remember it being explained in a manual.  If ANYONE can help me, please
>do.  This is going to be a great game, but I can't finish it until I
>can get those instructions.

All that POKE-ing can really slow your BASIC program down.
Plus it eats up a lot of memory storing all those POKE
statements. What you should do is POKE the binary data
into memory, and then save that memory block as a binary
file. This way you can take out all those POKEs and
potentially recover a large chunk of memory for your
"real" programming needs.

Just look at the space savings, using BLOAD to load in
your binary data from a file, rather than using POKEs:

                    PRINT CHR$(4)"BLOAD SHAPETABLE"
23 bytes of memory:  ^     ^  ^^^^^^^^^^^^^^^^^^^^^

                    POKE 768, 1: POKE 769, 0: POKE 770, 4 
20 bytes of memory:  ^   ^^^^ ^^  ^   ^^^^ ^^  ^   ^^^^ ^


The first example uses just 23 bytes call DOS to get your
shapetable data all at once and very quickly.

The second example is only storing 3 bytes, which is not
enough data to do ANYTHING, and already it has used 20
bytes of BASIC memory. So if your shapetable is at all
complex you'll be wasting tons of space. A shapetable of
100 bytes is going to need at LEAST 699 bytes for all
those POKEs.

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

What you do is you POKE the data into memory once, then
save that memory region to disk, like this:

1. POKE 768,1: POKE 769, 2: POKE 770, 3:.........

2. Figure out the length of the data. Let's say your
   binary data starts at 768 and ends at 778. You
   subtract 778 from 768, and add 1 to the result:
    Start: 768   End: 778
    Length is (End - Start) + 1: (778-768)+1= 11

3. BSAVE SHAPES.768, A768, L11

The "A768" specifies the starting address
The "L11" specifies the length of the region to save
---------------

ADVANCED INFO (if you wanna know more) -- You could just
stop here if the above is enough.


--- WHY the "plus one" in '(End-Start)+1'? ---

It's also known as a "fencepost error". Usually we
start counting at 1 but in the Apple II machine
language we normally start counting with zero. While 1
to 10 is ten bytes, 0 to 10 is really eleven bytes:

   Ten bytes: 1 2 3 4 5 6 7 8 9 10
Eleven bytes: 0 1 2 3 4 5 6 7 8 9 10

If you figure length by subtracting the beginning
address from the end address, it doesn't include that
"zeroeth" byte at the beginning. So when it saves it
will start from zero rather than 1 and drop the last
byte off the end of your binary file. That's why you
need to add one to (End - Start) when figuring the
total length of the data.


--- HEXADECIMAL SAVING, LOADING ---

You can also save and load using hexadecimal (base 16)
numbering. DOS tells the two numbering systems apart
by using the dollar sign. The two following BSAVEs
are exactly the same:

BSAVE FILE, A768, L15
BSAVE FILE  A$300, L$E

For reference.. Decimal '768' is hexadecimal '300'
                Decimal '15' is hexadecimal 'E'

You are free to mix and match decimal and hexadecimal
as you choose. Just remember to include the dollar sign
if the number is hexadecimal. Any of these will save
the contents of high-resolution page 2:

BSAVE HIRES.PAGE2, A16384, L8192
BSAVE HIRES.PAGE2, A16384, L$2000
BSAVE HIRES.PAGE2, A$4000, L8192
BSAVE HIRES.PAGE2, A$4000, L$2000

For reference.. Decimal '16384'  is hexadecimal '4000'
                Decimal '8192' is hexadecimal '2000'


-- CHANGING THE BINARY LOAD LOCATION --

DOS will normaly reload the saved data wherever you
originally specified it when you saved the data. Data
saved at 768 with the name "DATA.AT.768" will
automatically be loaded back there if you just type:

BLOAD DATA.AT.768

However, you can change the load location in the BLOAD
statement. If you want to load the data to, say, the
page 1 text screen, you would use either of these:

BLOAD DATA.AT.768, A1024
BLOAD DATA.AT.768, A$400

This does not affect the saved data. If you do not
include the load location in the next BLOAD, it will
load where it was originally located.

-Mr. Boffo

Email: mister_boffo@hotmail.com