Tips and tricks for a "modular" kernel?

[vitoco]

Hi!

 

After I finished my first pong-like game, I started my first shooter, and it will use a paddle as the controller. In the prototype, I could place a sprite in the screen and make it move horizontally both with the paddle and with AI (for enemies), using a sort of inertia in both cases. I also made the ball to move vertically at the same time as a fired missile.

 

Now, I want to display many of these in the screen, each with its own position, shape and colors (per scanline). To avoid them to be at the same time in the same scanline (I don't want flickering here), I decided to divide the arena in sections, so each section could have different types of enemies with its own rules, and there could be more than one section of the same enemy type.

 

These are the problems I'm visualizing for a kernel:

 

(1) The ball should travel through all the sections, and probably be in two sections at the same time (ball height should be of 4 or 5 scanlines).

(2) Handle the vertical movement of the enemies within their sections (relative or absolute?).

(3) I want the sections to have dynamic heights (dynamic does not means different, but changing on every frame).

(4) I need to read the pot on every scanline to handle the paddle.

 

I'm also thinking about a blank section between the other ones, in order to manage the dynamic heights, and to shrink each of the enemies section to the height of them, so no need to handle the vertical movement inside of it. The only relevant element in these blank sections would be the ball. So, if I shrink a blank section, all the enemies bellow it will move up. Of course, I'd need to enlarge another blank section bellow to make the arena of a constant height.

 

I think that I could waste one scanline moving some variables to set up the section from precalculated values during the vertical blank or overscan instead doing this calculations directly to the variables actually managed by each section, allowing type repetitions.

 

I'm sure that a fixed kernel with repeated sections does not apply... I'd need a lot of them for every combination of enemy types.

 

Instead, to quickly change from one section to another, I thought about chaining all the required types sections of a screen by pushing their addresses in the stack, and perform a RTS at the end of each section, which use a constant 6 cycles instead of a lot of them in a "case" structure to check for each type. The tradeoff is that it would require 2 extra bytes of RAM from the stack side for each section, for example, 14 bytes for 7 sections.

 

Do all of these sound too complex?

 

So, which should be the best approach to build such a kernel? What to prefer/avoid?

 

[StupidBunny]

Neat, I actually had a similar idea for the game I’m making (an invisible divide between an area for “flying” and “ground” enemies so neither had to share scanlines) but never got far into the implementation; it sounds like yours will have more than two sections though. At any rate given that I’m not terribly experienced at this I’d probably not be the person to ask but I will say based on my limited efforts that it should be doable and not overly complex if you can set the criteria for your enemy types such that they never “walk over” each other, maybe with one enemy type forcing constraints on the other’s movement as they move. The most annoying visual problem I had was that the player would smear while crossing the boundary, but if the only thing crossing your boundaries is the Ball then that ought to be much less of an issue.