--- kurt.woloch@xxxxxxxxx wrote:
> Hmmm, the Kernal (and thus, the timing issues) is
> another problem, but as I
> see it, M2 is still free. Maybe you could do some
> kind of that trick as used
> in Missile Command for the missiles, and Decathlon
> for the pole, in Pitfall
> for the ropes etc. where a missile is displayed
> which gradually changes
> position with HMOVE's on every, or every other,
> line. As long as the crystal
> ball is well under, or over, the ship, this should
> work, as well as
> displaying the ship and the ball with the same
> player in one frame.
This sounds good, still i have to find the time for
it.
Here are some explanations/limitations of my
kerne(a?)l:
- the kernel is repeated every 4th line
- the players and missiles are changed every 2nd line
- all missiles are only 2 lines high
- one new PF-block _or_ a multi-used-player can start
every 4th line
Drawing the missiles is very simple now:
ldx #ENABL ;2
txs ;2
cpy BLline ;3
php ;3 got this trick from
Combat
cpy M1line ;3
php ;3
txs ;2
...
cpy BLline ;3
php ;3
cpy M1line ;3
php ;3
This makes just 24 clocks for 4 lines.
To draw a higher missile, i need totally different
code,
which would cost some extra time, which i haven't
found
yet. (about 2*15 clocks for the compares an stores,
plus
the 9 clocks for two HMOVEs and one HMCLR to
prevent the players from moving arround (there is no
HMCLR in my kernel now), plus at least 5+3(*2?)
clocks for loading and storing the values for HMM0,
this makes ~50 clocks)
Drawing the fire- and the wire-missiles on different
frames, would add some more flicker to missile fire.
I have to find out, what is possible and looks best...
> If the
> ball gets to near vertically, you could switch to
> another mode where the
> ball is displayed alternating with the ship
> (flickering), and also another
> solution's used for the wire.
I don't want the ship to flicker, because this is the
point where the human player is most focussed at.
So i'll better let some of the other players flicker.
> Sorry, I can't figure out what this means... could
> you further explain how
> you store the terrain data?
I'll try: looking at the smallest level 1 (red PF) you
can divide it into three parts: sky, cave and socket.
For the sky and the socket i need one block each for
the two sides of the PF, which makes a total of 4
blocks. The cave consists out of two blocks for both
borders.
(use fixed-font for the following "graphics"!)
left border blocks right border blocks
/ \
sky-| |-sky
\ /
/ ---- P ---- \_bl1
bl1-| ------ ------ /
\ -------- F ------------ \
/ -------------- ------------ |_bl2
bl2-| ----------------G ------------ |
\ ------------------ ------------ /
/ -------------------------------------- \
soc-| -------------------------------------- |-soc
ket \ -------------------------------------- / ket
Level 4, which is were the demo starts, has
15(cave)+2(sky, socket) blocks for the left, but
only 6+2 blocks for the right border.
> How many "blocks", roughly, are used for each level?
There are between 4 and ~20 blocks used for each
border.
(4..~20) * 2[both borders] * 4[bytes/block]
= 32..~160 bytes/level
> So
> maybe it'll be better to relocate those fuel
> stations to other places in the
> level, or simply put one fuel station there which
> has got a bigger capacity
> instead of the multiple ones...
That's exactly what how i planned it.
> Ah. I didn't try that... I thought the fire button
> was totally inactive...
> has it got other functions too?
No, it just fires the missiles, and the gate-opening
function is only temporary.
=====
Thomas Jentzsch | *** Every bit is sacred ! ***
tjentzsch at yahoo dot de |
__________________________________________________________________
Do You Yahoo!?
Gesendet von Yahoo! Mail - http://mail.yahoo.de
Yahoo! Auktionen - gleich ausprobieren - http://auktionen.yahoo.de
--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
