>Wow, this is getting *really* nice!
Thanks!
>Did you reject the asymmetrical PF?
No, it does both symmetrical and copied PF. (asymetrical but not arbitrary)
FYI the top row of backgrounds is asymmetrical...
Currently the symmetrical/copy status of a row's background and platforms can be controlled independently (ie: symmetrical bacground behind copied platforms) however that will almost certainly be removed and they'll have to be the same (still controlled on a row by row basis) in order to add the pick-up item(s) - It'll quickly free up the needed RAM (1 byte per row) and I don't think it's a big deal as far as level design goes. It should should entail a minimal change to the kernal (ie: instead of tweaking CTRLPF just before the platforms, I'll tweak ENABL...)
Hrm, actually, now that I mention it, since it's bit 0 of CTRLPF and bit 1 of ENABL, maybe I can keep them both after all and share the variables. Sweet! (Long as I can keep from munging the other CTRLPF registers...)
Yep, looks like that's going to work!
>> Colour (changes colour but not text string)
>
>I would suggest different initial values here.
Yeah, that's very temporary (Though I really like the black/white contrast...). There's probably going to only be ten or a dozen different colours available since I want to be able to display corresponding text strings on the setup screen ("red", "blue", "green", etc..). Currently it's just adding/subbing 4 to the TIA colour values each left/right joystick so there's a lot of (garish) combinations...
>Some ideas:
>Have you thought about vertically color scrolling too? It might get
>quite "jumpy", but it would add some nice new possibilities. You could
>scroll by doubling the currently scrolling floor, so that the players
>could quite easily follow the movement without getting visible.
Hrm, I'm not sure how I could incorperate that into this kernal. Currently there are essentially two parts to the display kernal; the platforms and the backgrounds. Both these parts also handle drawing player sprites depending upon the sprites vertical positioning (the platform scanline and the scanlines just before/after the scanline can't draw bullets but I didn't think that would be a big deal. Even if you'll be able to shoot while jumping/falling [which may still not happen] it shouldn't be a problem to "cheat" a little bit and only have the shots appear just above/below the platforms). There's only a couple cycles per scanline available (at best) and the blank scanlines (for example) are very neccessary because of playfield registers being changed mid-scanline in preperation of the next row of background/platforms - The player sprites need to be handled every scanline (missiles are only every other scanline) and this needs to happen during the horizontal blank (actually just the writes to GRP0/GRP1/ENAM0/ENAM1 need to occur during HBLANK) to avoid shearing. So the changes to PF values happen midscanlines but are masked as blank (black) scanlines.
In order to deal with vertically scrolling portions of the playfield, those blank scanlines would somehow have to become movable while the rest of the row does not. Uhh, I don't think so.
>How about bonus items which e.g. could reverse the scrolling
>direction, invert the wall colors, enlarge the walls with the players
>color, flash a whole floor or make the opposite player visible for a
>few seconds?
Yeh, I have a list here somewhere of bonus items I was hoping to do, however, I'll be happy just manage to do Ammo - There's not a lot of time left in the kernal and I'm trying to avoid flickering P0, P1 or even the missiles... I'm planning to do an Ammo pickupable with the Ball, and it'll probably just be a flashing square, alternating between the two colours. I don't think there's any time available to play with the size/position to create more complex icons. At least not without going to a double line kernal and halving the vertical resolution. Which I really, really don't want to do given how nice the player sprites look...
Maybe for the GBA version...
Well, the scanlines in the middle of the "backgrounds" alternate between 63 and 70 cycles each (including sta WSYNC) so there may be enough time in there to do something more than just a square, but making it variable would be tough and kinda implies freeing up some RAM, either for the whole "bitmap" (actually CTRLPF/HMBL data) or a pointer to same. Maybe, maybe not...
>Or how about making the player visible when he shots?
That's a REALLY good idea. We'll call it a "muzzle flash"..
Might try and make that optional though (maybe turn it off in expert mode).
Chris...
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
