Donkey Kong - Loadsa Sprites Edition
CardboardGuru
Posts: 443
What can I say? More stuff. All the sprites for Level 2 and some for level 3.
1) The Lifts (Elevators). Pretty simple animation. Mario gets to ride them by the simple expedient of updating the PlatformHeight function to recognise lift sprites as platforms too as well as the usual tiles. The only problem was that Mario would instantly think he'd landed as soon as he'd taken off for a jump when on the up elevator. So for the first few ticks of a jump I now don't test for landings. Needs to be set to a happy medium. Too early and he can't jump at all. Too late and he falls through if you jump on the spot on one of the lifts. This wouldn't be a problem if Mario obeyed the laws of physics and added the velocity of the lift to his upward jump. But this is Nintendo world.
2) Springs. Simple animation. 4 bounces and a drop. Has X randomised by 16 pixels just to keep Mario on his toes.
3) Pauline's brolly, hat and handbag. They just sit there for now.
4) Fireballs. Exactly the same as level one. Just place them in the right starting position and watch 'em go.
5) Moving ladders. The sprite is just for show. The way Mario is allowed or prevented from climbing is by adding or removing a couple of invisible ladder tiles behind the sprite.
6) Conveyors. Kong is the metronome again. He moves backwards and forwards 128 pixels on the top conveyor. Every time he hits the far left position he changes the direction of the bottom conveyor. When he passes the middle of the screen, he changes the direction of one or other of the middle conveyors depending if he passes going right or left.
7) Pies. A new pie appears every 125 ticks, provided there are not 5 already out. It appears randomly on an end of one of the conveyors that's heading on screen.
8) Tweaked the position of Kong and Pauline on the 4th level. Kong now dead centre, and Pauline off to one side.
At some point during all this I noticed why JT Cook was worried about having a cog left over for the sound. There wasn't a spare one in my last release. I must have upped the number of rendering cogs and then forgot. And sure enough going back down to 5 rendering cogs broke up the screen. I toyed with the idea of changing those fixed barrels to tiles. But it will not work. The platform that they are stood on looks like it's aligned with the tile map, but it isn't. The barrels would end up 4 pixels above the platform if I made them into tiles. And there's no opportunity of cheating with part barrel part platform tiles because of the different palettes. Same problem with changing Kong to tiles.
So I needed to make the renderer code faster. Quite hard because I was out of cog memory. But I noticed that when processing the tiles, if the tile Is the same as the last one drawn, then the renderer could reuse the data and do less work. And that happens more often than not. I only needed 4 longs to do that optimisation. That was enough to go back down to 5 rendering cogs without any problems. Which gives us that spare one for sound again.
I'm now down to 1/2 KB Hub memory, and I'm not sure how much of that is needed for the stack. So the next job is to replace those level maps with something rather smaller.
Post Edited (CardboardGuru) : 5/17/2007 1:40:11 AM GMT
1) The Lifts (Elevators). Pretty simple animation. Mario gets to ride them by the simple expedient of updating the PlatformHeight function to recognise lift sprites as platforms too as well as the usual tiles. The only problem was that Mario would instantly think he'd landed as soon as he'd taken off for a jump when on the up elevator. So for the first few ticks of a jump I now don't test for landings. Needs to be set to a happy medium. Too early and he can't jump at all. Too late and he falls through if you jump on the spot on one of the lifts. This wouldn't be a problem if Mario obeyed the laws of physics and added the velocity of the lift to his upward jump. But this is Nintendo world.
2) Springs. Simple animation. 4 bounces and a drop. Has X randomised by 16 pixels just to keep Mario on his toes.
3) Pauline's brolly, hat and handbag. They just sit there for now.
4) Fireballs. Exactly the same as level one. Just place them in the right starting position and watch 'em go.
5) Moving ladders. The sprite is just for show. The way Mario is allowed or prevented from climbing is by adding or removing a couple of invisible ladder tiles behind the sprite.
6) Conveyors. Kong is the metronome again. He moves backwards and forwards 128 pixels on the top conveyor. Every time he hits the far left position he changes the direction of the bottom conveyor. When he passes the middle of the screen, he changes the direction of one or other of the middle conveyors depending if he passes going right or left.
7) Pies. A new pie appears every 125 ticks, provided there are not 5 already out. It appears randomly on an end of one of the conveyors that's heading on screen.
8) Tweaked the position of Kong and Pauline on the 4th level. Kong now dead centre, and Pauline off to one side.
At some point during all this I noticed why JT Cook was worried about having a cog left over for the sound. There wasn't a spare one in my last release. I must have upped the number of rendering cogs and then forgot. And sure enough going back down to 5 rendering cogs broke up the screen. I toyed with the idea of changing those fixed barrels to tiles. But it will not work. The platform that they are stood on looks like it's aligned with the tile map, but it isn't. The barrels would end up 4 pixels above the platform if I made them into tiles. And there's no opportunity of cheating with part barrel part platform tiles because of the different palettes. Same problem with changing Kong to tiles.
So I needed to make the renderer code faster. Quite hard because I was out of cog memory. But I noticed that when processing the tiles, if the tile Is the same as the last one drawn, then the renderer could reuse the data and do less work. And that happens more often than not. I only needed 4 longs to do that optimisation. That was enough to go back down to 5 rendering cogs without any problems. Which gives us that spare one for sound again.
I'm now down to 1/2 KB Hub memory, and I'm not sure how much of that is needed for the stack. So the next job is to replace those level maps with something rather smaller.
Post Edited (CardboardGuru) : 5/17/2007 1:40:11 AM GMT
Comments
Andre'
Whilst I've been suggesting RLE for Bagger's Manic Miner screens, it seems overkill for 4 screens in DK. I'm just drawing the screens with code instead. The first screen needs on 37% of the space now for the drawing code than it did for the map. The other screens will be a bigger win because they are less complicated and the drawing functions are already there.
Karl,
I'm not going to use upper-EEPROM for this project. Things aren't that desperate!
keep it up [noparse]:)[/noparse]
I finished off freeing up space by drawing the screens rather than store them as maps. And that freed up about 6KB I think. So I went mad then using up all that lovely free RAM. First I added the sound driver, and put some excruciatingly nausiating sounds in there, just to see that I could.
Then I had a bit of fun doing an animation.
So I'm back down to 2KB now. Could be worse.
I really should have finished off levels 3 and 4 first.
Post Edited (CardboardGuru) : 5/25/2007 2:31:35 AM GMT
good job