> From: "Manuel Polik" <manuel.polik@xxxxxxxxxxx>
[snip/snip]
> I hope this gives you at least the idea. For example I could imagine
> that you precalculate 2 PF bytes during the overscan and do one on the
> fly. If you could do it all on the fly, you might free lots of bytes.
Thanks Manuel for your posting regarding the precalculation of playfield
on-the-fly, and the suggestions as to RAM saving. I basically understood
what you were suggesting, and did spend a while thinking about how things
are, and how they could change.
I decided to have a go at packing my RAM usage (being very stingy with
bits - as Thomas would (and does) say... every bit counts). I implemented
variable overlays - as I posted earlier today - and this provided huge
benefit to my particular game. In the end, I added a whole lot of
functionality (level counters, creature counters, movement, AI, etc...) and
actually reduced my RAM usage. I'm 100% certain now there's no RAM shortage
in this game. I'm at $e7 and holding. Very few nested subroutines or stack
usage, so I'm sure I can go up to about $f8 if I really wanted to.
> _____
> | |
> | B2|-->
> |___|
> ^
> |
> __|__
> | |
> | B1|
> |___|
>
> In your demo the blocks B1 & B2 would overlap. How did you prevent this
> in the Atari 800 version? Are there any movement restrictions in the
> gameplay? If yes, which?
The Atari 800 version and this Atari 2600 version behave similarly, and it's
quite simple. Each cube you see 'owns' a square/position. You (or any
creature) can only move a cube into an unoccupied position. Once you
actually DO start moving, you immediately 'occupy' that position and free
the one you were on. Thus, other cubes can start to slide to where you
were. Yes, there's some overlap... but barely noticeable, and certainly
just what I want :) As for how it was avoided in the Atari 800 version...
the cubes were drawn in sorted order, back to front - and yes, they probably
overlapped in exactly the same fashion, though from a different perspective
:)
> And yet another thought: You simply could do only 3*3 blocks instead of
> 4*4, then you'd have only 15 bits horizontal resolution and you'd just
Yes, I actually wrote most of the code to auto-adjust to this possibility,
just by changing an equate (CUBEXY) at the start of the code. However, I
wanted to make the cubes nice-sized relative to the sprites, which they
currently are. In any case, there's no RAM problems, so the cubes can stay.
I can actually run 16 cubes (enough RAM!) but limit it to 8, because that's
all that's needed for good gameplay.
> And one final thought: Maybe it'd work to just do a grid and the target
> with the PF. Let players ride on missiles or vice-versa :-)
I spent a few weeks thinking about how I'd like to do it - and of course
that's the way I've done it. Everything has fallen together quite nicely -
ESPECIALLY the timing in my kernal. I also like the design how it fits well
with the 2600 capabilities.
> Ok, all RAM thoughts done. You might not need 'em, they're just in case
As always, your feedback and suggestions are most welcome and appreciated.
Cheers
A
--
_ _ _| _ _ _| _ * _ _ ,
(_|| )(_|( (/_\/\/ (_|(_|\/(_(/_ ,~' L_|\
,-' \
see my Museum of Soviet Calculators at ( \
http://www.taswegian.com/MOSCOW/soviet.html \ __ /
L,~' "\__/
@--> v
-
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
