[stella] Qb: Opinions sought...

Subject: [stella] Qb: Opinions sought...
From: "Andrew Davie" <adavie@xxxxxxxxxxxxx>
Date: Tue, 6 Mar 2001 23:46:41 +1100
OK, the problem Chris reported regarding the loss of vertical synch on the
4th board.... it's pretty grim, I'm afraid.  Basically, the amount of time
required to move and draw all the cubes is > the available cycles that I can
provide (given the current architecture).  Cubes are moved every 2nd frame,
so they are also drawn every 2nd frame.

I moved the routine from the overscan to the vertical blank - a few more
cycles "2800" available there, but also to no avail.  I *do* have solutions,
but they have consequences.

1) I could limit the number of cubes to 4.  Maybe 5.  Not a viable option.

2) I could move the cubes on one frame, and draw them on the other frame.
This works OK, but there is a significant code penalty (30+ bytes) *and*
when creatures are on moving cubes, the creatures shift-about on the cube
(ie: they are not 'locked' to dead-center).  There's lag between cube
movement and cube drawing, whereas the creatures move and draw immediately.
I didn't like the effect, but it is a solution, as I said.

3) I could change the entire draw system to an EOR draw, and only
draw/move/draw the cubes which are actually moving.  I've done this, and it
does work.  But the worst-case is that it has to erase 3, draw 3 - making
6... which is just as disasterous as the original problem.  Also, this is a
significant code penalty (40+ bytes).

4) I could draw 3 cubes on one frame, and 3 on the other frame.  I haven't
tried this one yet (the others I have), but this would leave the creatures
locked to the cubes.  Probably also a bit of code fiddling - and a fair bit
of extra code to cater for the split board-clear.  Estimate: about 40 bytes.
This seems to be the most viable option, I guess.

The bottom line here is that all of my viable solutions come with
significant code penalty.

As I was down to the last byte - and believe me I've optimised and optimised
and optimised - I've had to remove the title screen whilst I've been testing
things.   And, I don't think I can afford to put it back.  The title screen
code and data cost me 180 bytes.   I know some people feel that it's just
not the real thing without a title screen - and my title WAS pretty
snazzy.... but it cost 180 bytes.  And, it just sits there for a few seconds
and looks pretty.

Perhaps I should just junk it (a shame), and use the remainder of the bytes
to reinstall the points display (which Kurt sorely misses) for the fruits...
and even the heart.  I'm not sure what else I can really junk to allow the
title screen to return (the "1UP" could go easily, and one of the fruit...
that would make mmmh... about 50 bytes).

So, what do you all think... junk a couple of frames of graphics (1UP, a
fruit) and (hopefully) keep the title screen...  or junk the title screen
and install several more frames of graphics?

Something has to give.


 _  _  _| _ _        _| _    * _                               _  ,
(_|| )(_|( (/_\/\/  (_|(_|\/(_(/_                           ,~' 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/

Current Thread