Hi there!
Manuel wrote:
Timed overwrites of PF0/1 where required. The whole screen is devided
in 5 separate kernels, with the two variable sections being specialized
to this.
Sounds like a kernel puzzle. :-)
I guess the real fun starts with adding sprites and missiles... ;-)
Two make the structure blue and the ladders yellow, I'd need to double
the data and split it into structure/ladders only, alternately
displaying those and adjust the colors accordingly. That's what Paul
suggested I think. Something like flickering sprites at 30Hz.
I see, maybe you could also mix yellow and blue. But why would that
double the RAM usage? Are the levels that much changeable during play?
I'm buffering the changable playfield parts in RAM. So using the above
described technique, I'd also need to split those parts, thus doubling the
RAM.
There might be empty areas for this as well, or partially mirrored
areas (like in Venture). Also, not all screens require multiplexed
enemies.
I see. So you develop specialized kernels, vertically separate the
screens and use those kernels there. Right?
Yup. They're all hardcoded. Wastes tons of ROM, but I don't want to waste
any cycles on conditional logic or JSR/RTS combos at the moment.
What are the major problems which would stop you from doing them?
Too many structure changes, too many enemies or too many ropes or
combinations of this.
I must admit I never played the game long enough to get very far.
Shame on you! ;-)
I know. But I played Thrust instead. :-)
Well, it's never too late... ;-)
Greetings,
Manuel
