English Amiga Board - View Single Post

DanielAllsopp · 07 December 2021, 17:58

Update #5

Trying to finish off the intro sequences so I can get into the actual game for the next update. This time that involved adding two more scenes from the arcade game and the main title screen itself, ready for the player to start the game.

The first scene involved some nice animations, which when extracted from the arcade sprites weighed in well over 512kb for one animation. There had to be a way to get that down, and part of my challenge when recreating this game is to figure out new ways to implement something that you just wouldn't care about when writing a game for a modern platform. At first, the animation included a number of frames which contained a gradually faded-in static frame before the animation starts, as well as frames featuring a gradually faded-out static frame when the animation ends. See the image in update #3.

That could easily be solved by removing those 40-odd frames, blitting the object with the palette set to black and using some code to fade the palette in up to the final values and then play the animation. Same applies when the animation finished; just fade the palette back to black. Once that's done we can clear the buffer, and move onto the next part of that scene.

Same challenge arose though: lots and lots of frames of animation. This time though, Robocop's gun slides in from the middle of the screen, gradually becoming more and more visible as the position changes. I only wanted to use one blitter object for this instead of having multiple frames with varying degrees of the gun being drawn. I finally figured out an easy way to do this would be to adjust the display window using the DIWSTOP register:

I could then blit the object below the display window, move the object up to the final position over a set number of frames, and at the same time not be bothered about any trails as they'd be off-screen. Once the scene has ended we can reset the display window back to the normal values for the next scene.

There's one more scene before the main title comes in, and that's some sort of explosion which occurs across the whole width of the screen. Fortunately, all of the assets from Robocop adhere to some nice safe widths, 64 pixels, which conveniently is the same width of the sprites I'm using for this port. So, instead of going down the route of using SSCAN2 to automatically double the sprites across a certain part of the screen, already done that elsewhere, I thought I'd have a go at manually repositioning the sprites across the whole screen by changing the SPRxPOS registers for the sprites 0 and 1 (they're attached 16 colour sprites).

One head-scratcher issue with this though, at least for me, is that after line $80 you have to change the way you WAIT with the copper. So in laymans terms, for anything above line $80 you WAIT with one copper command, and one and after line $80 you WAIT using another. I did have examples of code to get around this, in fact I did implement it for the highscore table, but I just couldn't be arsed to do that here, especially as it would only be needed for the first 8 lines of sprite data.

The solution? Just move the sprites down 8 pixels and draw them there instead, resulting in a much simpler copper loop. After-all, it's only an intro screen which is displayed on the screen for a matter of seconds!

There's a little bug in there which I need to address though, and a few missing items such as the the flashing text cursor and some sound effects but they can wait until the end when I tidy everything else up. I'm also aware that the music is playing every so slightly too fast compared to the arcade original. Easy fixes though.

The main title is a simple affair; moving all 8 sprites up the screen, changing the background colour at set points and using my 'typewriter' routines again to display the text.

So, it's all ready to restart on the game code, so that's the next thing... back to level 1 and adding some more meat to the engine, which will probably get a little refactor now I have gained some more knowledge from doing the intro scenes.

[ Show youtube player ]

Shout outs and big thanks for help during this little phase belong to:
- a/b: More 68k insights
- DanScott: Sprite positioning pointer
- Leffman: Actual sprite positioning code

07 December 2021, 17:58	#60
DanielAllsopp Registered User Join Date: Feb 2018 Location: Northumberland, UK Posts: 272	Update #5 Trying to finish off the intro sequences so I can get into the actual game for the next update. This time that involved adding two more scenes from the arcade game and the main title screen itself, ready for the player to start the game. The first scene involved some nice animations, which when extracted from the arcade sprites weighed in well over 512kb for one animation. There had to be a way to get that down, and part of my challenge when recreating this game is to figure out new ways to implement something that you just wouldn't care about when writing a game for a modern platform. At first, the animation included a number of frames which contained a gradually faded-in static frame before the animation starts, as well as frames featuring a gradually faded-out static frame when the animation ends. See the image in update #3. That could easily be solved by removing those 40-odd frames, blitting the object with the palette set to black and using some code to fade the palette in up to the final values and then play the animation. Same applies when the animation finished; just fade the palette back to black. Once that's done we can clear the buffer, and move onto the next part of that scene. Same challenge arose though: lots and lots of frames of animation. This time though, Robocop's gun slides in from the middle of the screen, gradually becoming more and more visible as the position changes. I only wanted to use one blitter object for this instead of having multiple frames with varying degrees of the gun being drawn. I finally figured out an easy way to do this would be to adjust the display window using the DIWSTOP register: I could then blit the object below the display window, move the object up to the final position over a set number of frames, and at the same time not be bothered about any trails as they'd be off-screen. Once the scene has ended we can reset the display window back to the normal values for the next scene. There's one more scene before the main title comes in, and that's some sort of explosion which occurs across the whole width of the screen. Fortunately, all of the assets from Robocop adhere to some nice safe widths, 64 pixels, which conveniently is the same width of the sprites I'm using for this port. So, instead of going down the route of using SSCAN2 to automatically double the sprites across a certain part of the screen, already done that elsewhere, I thought I'd have a go at manually repositioning the sprites across the whole screen by changing the SPRxPOS registers for the sprites 0 and 1 (they're attached 16 colour sprites). One head-scratcher issue with this though, at least for me, is that after line $80 you have to change the way you WAIT with the copper. So in laymans terms, for anything above line $80 you WAIT with one copper command, and one and after line $80 you WAIT using another. I did have examples of code to get around this, in fact I did implement it for the highscore table, but I just couldn't be arsed to do that here, especially as it would only be needed for the first 8 lines of sprite data. The solution? Just move the sprites down 8 pixels and draw them there instead, resulting in a much simpler copper loop. After-all, it's only an intro screen which is displayed on the screen for a matter of seconds! There's a little bug in there which I need to address though, and a few missing items such as the the flashing text cursor and some sound effects but they can wait until the end when I tidy everything else up. I'm also aware that the music is playing every so slightly too fast compared to the arcade original. Easy fixes though. The main title is a simple affair; moving all 8 sprites up the screen, changing the background colour at set points and using my 'typewriter' routines again to display the text. So, it's all ready to restart on the game code, so that's the next thing... back to level 1 and adding some more meat to the engine, which will probably get a little refactor now I have gained some more knowledge from doing the intro scenes. [ Show youtube player ] Shout outs and big thanks for help during this little phase belong to: - a/b: More 68k insights - DanScott: Sprite positioning pointer - Leffman: Actual sprite positioning code