I can explain alittle about the technical part of the game engine.
At first I planned to do a 8 way scroller with the technic discussed in this topic:http://www.atari-forum.com/viewtopic.php?f=16&t=12961
I got it almost finished (had a few glitches here and there) and it didn't take to much processor power (around 10-15 % if I remember), but since I scrolled with one pixel/vbi it was abit slow. I wanted atleast 2 pixels / vbi (which is what I have in the game today) and maybe I wanted to add the ability to make the player run. 2 pixels / vbi would mean the scroll routine will be slower and maybe take up to 30 or more % of the processor power. That might had been ok, but I decided to change the scroller to a much simpler/faster one.
Since a Metroid game doesn't have a big singel area (like in Turrican) but instead smaller rooms I thought it would be easier to reserve memory for the entire room (one big screen) and then draw the room then it's loaded and then scroll around with the STE hardware registers and don't do anything else. That will take almost no processor power but will take some memory, but I don't memory is such a problem anymore. I can atleast expect anyone with an STE to have 4Mb today.
One problem I noticed then I started with this technic was that the LINEWID register is just 8 bits so the maximum horizontal screen that can be scrolled is 4*320 * Y pixels big, so one room could be just 4 screens wide. It might had been ok, but I wanted to be able to have bigger rooms so then I load a room that is bigger than 4*320 I reserve two memory areas and then I change the screen address between them dependin on were in the room I am. To make this work I need to draw last screen of the first buffer to the first screen in the second buffer so I can have a seamless transition between the areas. The two memory areas must be of the same size (I could then ignore stuff like differen screen widths depending on there I am and so on), so now a room can be 1,2,3,4,5 or 7 screens wide, which is ok for one room. The vertical resolution can be anything ofcourse.
I don't use a double buffer so everything has to be drawn in sync with the electron beam. All sprites are drawn with the blitter in the border area except the main sprite that is drawn with a software routine and that starts to draw at the begining of a new screen. I had to draw the main sprite in software since it's more interrupt friendly and I needs that since I change half the palette every 16 line.
Since I only have the border area to draw sprites in I can't have to many on screen at once. For every sprite I need to restore the old background, save the new and then draw the sprite so there are alot of work, but I created a multiplex system so if there are to many sprites at once it will multiplex so they atleast get's draw. This causes flicker ofcourse (like a NES game) but I plan to design the game so that it normally shouldn't multiplex but if there are at some point to many sprites at screen (like heavy weapn fire for a few seconds and many enemies) it can handle it. if the sprite drawing takes to much time and goes into the visible part of the screen it CRASH. I couldn't figure out a good way to calculate the time the sprites take, atleast not so that the Atari can tell me that BEFORE it crash, so I made a table there I calculated the sprite time based on statistics. I saw how many sprites of a different size I could have on the screen and then got the average value from that. Since the speed difference is rather big between one or two sprites (16x16 big) it seems to work even if the calculated time isn't so precise.
I use the blitter to change the palette to. I wanted to be able to change 8 colors and with software I could only change 4 or 5 since I had to load registers with color data at the beginning of every 16 line, OR I had to do it in the line before and then just WAIT for that line to end and the next to start, which I didn't like.
With the blitter I load the blitter registers with color data and then it's time to change palette I do the blit at the beginning of the line and then after that I reload the blitter registers with data for next palette change. Since I don't use the blitter in the visible part of the screen the blitter registers will not change so then it's time for the next palette change the registers are ready and I just do the blit.
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe