Glenn wrote:
> A good way around the ball problems, I think would be to use a single
> playfield bit for the grenade. You just lose a little horizontal
> positioning accuracy and you can't smoothly animate it. But it might
> be a lot simpler to just do that than to try to use a sprite there.
Hm, that might be an option, though I think a ball would be a *lot* more
flexible. 1 or 2 pixel wide objects aren't possible then anymore.
> There might be enough time to give it a unique color and allow for a
> grenade on every row that way.
With "every row", I hope you mean every row *between* the tombstones.
Right? ;-)
> Of course, that eats up more RAM that way. If only one bit is going to
> appear on any given grenade line then it might be possible to just reserve a
> single byte for each grenade line, with 4 different kernels that selectively
> blank out the other playfield registers. Depending on the X position of the
> grenade, the proper kernel would be called that uses the byte for the proper
> register/instance of register.
The main problem here will be that we already have 4 (maybe 3) complete
2L kernels (~130 bytes/each), each including two (one for the tombstone
rows and one for the space between) complete kernels. That makes eight 2L
kernel codes already [~1000 bytes). Your idea would raise that number up
to 20(!) kernels (~2600 bytes).
And I also don't think this will gain that many CPU cycles.
I'm thinking about four 32 byte tables (which would overlap in memory).
Then the code could look like this:
ldy rowIdx,x ; from RAM
lda PF1Tbl_L,y
sta PF1
lda PF2Tbl_L,y
sta PF2
lda PF1Tbl_R,y
sta PF1
lda PF2Tbl_R,y
sta PF2
PF1Tbl_L:
.byte %10000000
.byte %01000000
...
.byte %00000001
ds 24, 0
PF2Tbl_L:
ds 8, 0
.byte %00000001
...
.byte %10000000
ds 16, 0
PF2_Tbl_R:
ds 16,0
.byte %10000000
...
.byte %00000001
ds 8, 0
PF2_Tbl_R:
ds 24, 0
.byte %00000001
...
.byte %10000000
And the 3 high bits might be used for storing the color.
This code could also be split into a left and a right PF part. That
might gain some cycles.
> With some positioning limitations in kernel variation 1 or 4 it should be
> possible to change the playfield color register for the grenade, don't you
> think?
Before trying, I'm not sure here. But it *looks* easier than a
repositioned ball.
> If we use playfield, I can think of at least one creative use for the ball.
> We could just draw a simple straight line down the screen. Setup for the
> ball would occur during the border zones so that should be plenty of time.
> This could be a kind of barrier powerup or something that can be used to
> trap zombies, keeping them from reaching the other half of the screen.
> Imagine if that barrier could be "nudged" by the cars when you bounce
> against it. Lots of things you can do with that.
> How does that sound?
If you don't care for the color gradients, that's very easy to code.
The biggest problem for me now is to avoid those nasty tearing effects
that happen when you change a register while the object is drawn. With
four object writes within two lines that have to happen nearly
completely outside the visible screen this is not an easy task.
And those effects are even more visible when the tearing happens at
different horizontal positions due to the many different kernels.
Therefore it's IMO a MUST to avoid them (even if we have to give up the
single pixel Y-positioning of the zombies).
What do you think?
BTW: This conversation is open to *all* [stella] members. ;-)
Have fun!
Thomas
_______________________________________________________
Thomas Jentzsch | *** Every bit is sacred ! ***
tjentzsch at web dot de |
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
