Hi,
Long time no post! Just a couple of hints that I figured out when I was
working on my still unfinished "Sabotage" clone...
Driving controllers are very inaccurate... There are only about 8 possible
positions to read or something like that (maybe more, but not much).
If you are multiplexing sprites, using the sprite collision registers is
relatively useless. Use distance routines. Check out my source code for my
game, it's in there.
You can get a TON of extra program time by multiplexing the overscan area.
By this I mean counting the frames... Lets say you have 3 sections of code,
on frame 1 you call section 1, frame 2 you call section 2, and frame 3 you
call section 3. I was able to put, for instance, collision detection and
joystick reading in frame 1, object movement in frame 2, and still had frame
three relatively empty. If you go more than 3 frames the game response
suffered.
Reading the paddles to get full range is VERY tricky... I wasn't able to get
my "sabotage" game to work well with the paddles because of timing issues.
It worked, but you used only about 1/3 of the paddle range, which was
annoying.
Hope that was helpful!
Bob
-----Original Message-----
From: owner-stella@xxxxxxxxxxx [mailto:owner-stella@xxxxxxxxxxx]On
Behalf Of Glenn Saunders
Sent: Tuesday, January 09, 2001 12:11 AM
To: stella@xxxxxxxxxxx
Subject: [stella] best practices
At 12:28 AM 1/9/2001 -0500, you wrote:
>You could switch the every-other-scanline and every-8-scanline sections
>depending on when you need to draw what. In that case you would need to
>hang a label on the every-other-line section and BNE to that rather than
>EndOfLine. I'm sure there's a more efficient way to do this, but this is
>the obvious way to me. (Well, except I'd do it as a DEC loop rather than
>an INC/CMP loop, as you imagined, cutting like 5 cycles out of the 68 or
>however many you have to spend on a line.)
I can do the bottoms up thing, but it just makes some things more confusing.
The screen is scanning from the top down and the graphics are spooling from
the rear end upward. What will be especially difficult is taking a sprite
collision and translating the fine/coarse positions into a playfield write
to generate the tombstone. It looks like tables will be easier than
calculating it.
But after 20 years, there are certainly a heep of 2600 best practices for
programmers, and with this sort of kernel I don't think I can afford taking
the sloppy route. Ram is going to be especially tight, for instance. The
main playfield bitmap will consume 96 bytes all by itself!
It really is fun, though, hearing all the different ways to accomplish the
simple goals with assembly. It's very refreshing compared to how I'm used
to writing things in Basic, Javascript, and CFML.
BTW, I was thinking about having a paddle option for this game, but I don't
think it's going to be possible because of the timings of having to
discharge the pots during screentime. The dual need for a playfield bitmap
and adjusting the width and position of the missiles on the scanline isn't
going to leave much time to read the paddles, although I could maybe make
the missiles 7 scanlines tall and reserve the last line for the paddle read.
But using the driving controllers seems like it will yield an easier kernel.
Glenn Saunders - Producer - Cyberpunks Entertainment
Personal homepage: http://www.geocities.com/Hollywood/1698
Cyberpunks Entertainment: http://cyberpunks.uni.cc
--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
