I was sure that I had already posted this, but maybe it was in another thread ![:)]( "Smile")
I seem to remember shrinking the screen to try to fit the game into the basic model B.
I have since moved to B+ or 16K SWRAM but don't think I put the screen back.
I will describe the screen and techniques as they were in the picture, as they haven't really changed.
I use vertical rupture with a 6845 frame per character row, this allows me to hide 16 pixels between the end of one line and the start of the next so that any sprites can go off one side, jump up/down unseen and come on the other and still maintain the arcade resolution.
The sky is one with 10 character rows using black for the sky, magenta for the bullets and bombs and two other colours for the aliens. The two other colours were to allow each alien to be a different colour, but as they can be on screen at the same time, they don't need to be configurable.
The next three char rows (now two) are the parallax mountains and they use magenta for bullets, black for the sky, cyan and blue for the mountains.
The next three char rows (now two) are the parallax hills and they use magenta for bullets, cyan for the mountains, yellow and green for the hills.
Then comes the four rows that have your jumping vehicle (plus tanks and the rocket car when I add it) with, yellow for hills, magenta for bullets and bombs, cyan for the windows and black for tyres and details.
Below this is the red bumpy ground, black for tyres, magenta for bombs and car and yellow for hills.
The are a couple of final rows with a few more palette changes to add a bit more colour.
At each check point, the hills swap for building.
The palettes change after you have completed the first course, alternating every completed master and beginner course.
There are several layers of parallax scrolling and the hills and mountains work in the same way:
The pattern repeats every 127 pixels, so by starting the character row 128 pixels in, the whole thing appears to have moved 1 pixel to the left. The character row is actually 768x8 (well, the last few pixels are never displayed). It has to be so wide as when the landscape has move 3 pixel, we are starting the screen at the beginning of the fourth 127/8 pixel chunk and there have to be two displayed to fill the screen. So when the screen starts with the last byte of the fourth screen after scrolling 127 pixels, it needs to have nearly a whole screen or 2x127 still to display. This means that for a 12 screen width pattern, we need three screens wide of data to do the scrolling in HW!
The same technique is used for the hills, but the scroll more often than the mountains. When they get swapped for the buildings, I didn't have room for two copies of the data, not even the 128 wide one so one is displayed and the other is in memory and at the end of a stage, the first 128x8 pixels are swapped between the two and then code copies the first 127 pixels to 128+ and that is copied again... to generate the 6 wide rows. :O There is a bug that if any bullets or bombs are showing in the first 127 pixels of the hills or mountains areas then they will be copied into the other buffer and then copied 5 times and be visible for the rest of the game - I should probably fix that!
This adds another level of complexity to drawing bombs and shots (and aliens if I allowed them to crash, which I don.t yet). I have to calculate the screen address to draw the bomb based on where that char row has scrolled to, store the background (as I don't have room for another copy). The address that the bomb or bullet was at needs to be kept so that when the background is restored it can go to the correct place. This also means that all bombs and bullets must be cleared together and either drawn in the same order or copy the backgrounds together and then draw together.
The bumpy ground uses a different method as the rough bit is only 0 to 4 pixels high and this time 128 pixels wide. I think I have an unrolled loop where the gfx are copied from a double copy of the gfx indexed by X, read once and written twice. This gives a bit of a problem for holes and plants as the tops get covered in dirt every frame. The get around this, the rocks and top of plants and holes are fully drawn every frame with enough overlap to clear themselves (IIRC). The holes below the soil only draw the edges with the left having hill colour on the right most pixels and the right edges having soil after the edge so that they self erase themselves and leave the correct colour. The plants, mines and rocks just draw on top (with a mask iirc).
The buggy is drawn as five separate sprites (iirc) the body, the gun sticking up at the back and the three tyres. Each tyre looks at the ground to see how high it is so that they are drawn on it and follow the contours unless they are retracted in a jump. The average distance off the ground of the three tyres is used (one wheel * 2 plus the other 2 shifted right by 2) to draw the vehicle as it bounces on the lunar surface![:)]( "Smile")
As usual, the sprites are updated groups based on the vertical position of the screen that they are visible in with some overlap due to bullets and bombs as well as things on the ground. But basically when the beam gets below the aliens, they are cleared and so are any bombs and bullets in that part of the screen then the aliens are drawn along with any bombs and bullets there. Next any old bombs and bullets in the mountains restore their backgrounds and any new ones copy the background and then draw themselves. When the beam gets to ground level iirc, the vehicle and its parts are cleared as are any bombs, bullets, tanks and rocks. The ground is just redrawn which wipes the mines as are the holes and things in them along with the vehicle and rocks. Bombs and bullets are usually drawn with ORA as magenta is kept as colour three so that they don't need to be masked.
As is usual with porting games of this era and having them run at 50fps without flicker eats a lot of cycles to draw the sprites as well as a lot of memory to keep copies for different offsets within the bytes. The tune isn't particularly small and the maps quite large with many sections and many things that can appear in them. The map lists what can come on in a small section of the level and then that is used to put them in a queue which spawns something when the object at the front of the queue's timer (pixel count) runs out. If you look at the colours chosen for each section, you will notice that only two change at each intersection, this is because you can change two palette entries during one offscreen line period![:)]( "Smile")
If you leave the game running, you will see a whole get corrupt, I think I have overflowed something but haven't debugged it!
NuLA is also supported:
I seem to remember shrinking the screen to try to fit the game into the basic model B.
I have since moved to B+ or 16K SWRAM but don't think I put the screen back.
I will describe the screen and techniques as they were in the picture, as they haven't really changed.
I use vertical rupture with a 6845 frame per character row, this allows me to hide 16 pixels between the end of one line and the start of the next so that any sprites can go off one side, jump up/down unseen and come on the other and still maintain the arcade resolution.
The sky is one with 10 character rows using black for the sky, magenta for the bullets and bombs and two other colours for the aliens. The two other colours were to allow each alien to be a different colour, but as they can be on screen at the same time, they don't need to be configurable.
The next three char rows (now two) are the parallax mountains and they use magenta for bullets, black for the sky, cyan and blue for the mountains.
The next three char rows (now two) are the parallax hills and they use magenta for bullets, cyan for the mountains, yellow and green for the hills.
Then comes the four rows that have your jumping vehicle (plus tanks and the rocket car when I add it) with, yellow for hills, magenta for bullets and bombs, cyan for the windows and black for tyres and details.
Below this is the red bumpy ground, black for tyres, magenta for bombs and car and yellow for hills.
The are a couple of final rows with a few more palette changes to add a bit more colour.
At each check point, the hills swap for building.
The palettes change after you have completed the first course, alternating every completed master and beginner course.
There are several layers of parallax scrolling and the hills and mountains work in the same way:
The pattern repeats every 127 pixels, so by starting the character row 128 pixels in, the whole thing appears to have moved 1 pixel to the left. The character row is actually 768x8 (well, the last few pixels are never displayed). It has to be so wide as when the landscape has move 3 pixel, we are starting the screen at the beginning of the fourth 127/8 pixel chunk and there have to be two displayed to fill the screen. So when the screen starts with the last byte of the fourth screen after scrolling 127 pixels, it needs to have nearly a whole screen or 2x127 still to display. This means that for a 12 screen width pattern, we need three screens wide of data to do the scrolling in HW!
The same technique is used for the hills, but the scroll more often than the mountains. When they get swapped for the buildings, I didn't have room for two copies of the data, not even the 128 wide one so one is displayed and the other is in memory and at the end of a stage, the first 128x8 pixels are swapped between the two and then code copies the first 127 pixels to 128+ and that is copied again... to generate the 6 wide rows. :O There is a bug that if any bullets or bombs are showing in the first 127 pixels of the hills or mountains areas then they will be copied into the other buffer and then copied 5 times and be visible for the rest of the game - I should probably fix that!
This adds another level of complexity to drawing bombs and shots (and aliens if I allowed them to crash, which I don.t yet). I have to calculate the screen address to draw the bomb based on where that char row has scrolled to, store the background (as I don't have room for another copy). The address that the bomb or bullet was at needs to be kept so that when the background is restored it can go to the correct place. This also means that all bombs and bullets must be cleared together and either drawn in the same order or copy the backgrounds together and then draw together.
The bumpy ground uses a different method as the rough bit is only 0 to 4 pixels high and this time 128 pixels wide. I think I have an unrolled loop where the gfx are copied from a double copy of the gfx indexed by X, read once and written twice. This gives a bit of a problem for holes and plants as the tops get covered in dirt every frame. The get around this, the rocks and top of plants and holes are fully drawn every frame with enough overlap to clear themselves (IIRC). The holes below the soil only draw the edges with the left having hill colour on the right most pixels and the right edges having soil after the edge so that they self erase themselves and leave the correct colour. The plants, mines and rocks just draw on top (with a mask iirc).
The buggy is drawn as five separate sprites (iirc) the body, the gun sticking up at the back and the three tyres. Each tyre looks at the ground to see how high it is so that they are drawn on it and follow the contours unless they are retracted in a jump. The average distance off the ground of the three tyres is used (one wheel * 2 plus the other 2 shifted right by 2) to draw the vehicle as it bounces on the lunar surface
As usual, the sprites are updated groups based on the vertical position of the screen that they are visible in with some overlap due to bullets and bombs as well as things on the ground. But basically when the beam gets below the aliens, they are cleared and so are any bombs and bullets in that part of the screen then the aliens are drawn along with any bombs and bullets there. Next any old bombs and bullets in the mountains restore their backgrounds and any new ones copy the background and then draw themselves. When the beam gets to ground level iirc, the vehicle and its parts are cleared as are any bombs, bullets, tanks and rocks. The ground is just redrawn which wipes the mines as are the holes and things in them along with the vehicle and rocks. Bombs and bullets are usually drawn with ORA as magenta is kept as colour three so that they don't need to be masked.
As is usual with porting games of this era and having them run at 50fps without flicker eats a lot of cycles to draw the sprites as well as a lot of memory to keep copies for different offsets within the bytes. The tune isn't particularly small and the maps quite large with many sections and many things that can appear in them. The map lists what can come on in a small section of the level and then that is used to put them in a queue which spawns something when the object at the front of the queue's timer (pixel count) runs out. If you look at the colours chosen for each section, you will notice that only two change at each intersection, this is because you can change two palette entries during one offscreen line period
If you leave the game running, you will see a whole get corrupt, I think I have overflowed something but haven't debugged it!
NuLA is also supported:
Statistics: Posted by tricky — Fri Jan 24, 2025 6:35 pm