Re: [stella] DD RAM usage/animation

[Thomas Jentzsch <tjentzsch@xxxxxx>]

Glenn wrote:
> When you say save 11 bytes do you mean RAM or ROM?

RAM of course. It's far too early to optimize for just 11 bytes of ROM.
:-)


> I'm just trying to find out whether the packed-playfield is going to
> happen or not. 

It is, see attachment! :-)

I'm using the free cycles inside the grenade row, but maybe those are
more useful for something else.


> I thought I wrote this from Hotmail but I didn't see the message show 
> up.  Anyway, if the timing issues have to do with tearing, as always, we 
> can fall back to the missiles only extending to the width of the safe-zone 
> strip and worst-case, cheat the safe-zone in one playfield pixel.

I would suggest to not to compromise here now. Only if we really need
that additional RAM we should go that way. Else the cycles might be
useful for something else.


> One drawback of the packed playfield is that I'd no longer be able to do 
> the title screen, at least not by loading it into RAM.  I'd have to have an 
> alternate kernel just for that.  Since we might have to drop the title 
> screen anyway to save resources I'm not that concerned about it.

Maybe a big "DD" might still be recognizable.


> I'm also thinking about maybe dropping the visible timer and going with the 
> blinking sprites warning signal like Combat and other timed 1st gen games 
> do.  That might save some space, though probably not much in the way of RAM.


> How much RAM do you think the stack is taking up in the game currently?

I haven't tried anything to reduce stack space at all. Most subroutine
calls can very easily be removed. I think the whole game can be done
with only about 6 bytes of stack.


> Sounds doable still.

Yes, and we can even save a few byte here and there. E.g. we would need
two instead of three values for the missile Y position when doing 2L
precision when basing all calculations on Mx_Y2.


> It's just that I hate leaving every other bit of playfield RAM unused
> everywhere but in the title screen.

> Seems like a real waste.  But if it's necessary for timing purposes I guess
> it's okay.

Yes, you are 100% right. Hm, maybe the free cycles in the grenade line
can be used for preparing some PF data...

> BTW, the method I'm thinking of using for animation is to have a lot of
> little tables to sequence out the X/Y delta like so:

>snip

A simple trick I used for Thrust to get more precise movement of the
missiles was to use two tables, one for even and a different one for odd
frames. That way you can do something like 0.5. But with the low values
you will need, you could also squeeze those two values into one byte.


> This should work okay for vector-like movement.  Doing the physics for the
> cars will be trickier if I want any sort of inertia/centrifugal glide and 
> slide during hair-pin turns.  I don't think the coin-op featured this but I 
> think it would enhance the game.  Could be a variation or difficulty switch 
> option.

This is quite easy to program. It works similar to gravity and I have
already done that with Thrust. But you will need a few additional RAM
bytes. 

Have fun!
Thomas                            
_______________________________________________________
Thomas Jentzsch         | *** Every bit is sacred ! ***
tjentzsch at web dot de |

Attachment: DD_2LKc.zip
Description: Zip compressed data

Attachment: DD_2LKc.bin
Description: Binary data