Rolling Thunder - Amiga Port

[mcgeezer]

Originally Posted by Galahad/FLT

I think there are more 512kchip/512kslow machines than there are 1meg chip.

1Meg chip came with the later 1.3 Kickstart about 6 months before the A500+ came out I think.

To be honest, it doesn't matter - the goal is to beat Tiertex with a stock Amiga ... no ram expansion.

[Tigerskunk]

I'd try to get rid of every second animation frame.

Most of these seem superflous. Looks good while animating, but not really needed.

[roondar]

Originally Posted by Steril707

I'd try to get rid of every second animation frame.

Most of these seem superflous. Looks good while animating, but not really needed.

Seems like a good start to me. Compromises need to be made for most ports and this sounds like a good idea!

Alternatively, you could create a more complicated animation system where you only keep the changes between frames in memory or some such solution. Or perhaps use a more console style "tile based" animation system. Not saying it'll definitely fit, or even that it's easy to do so. But I think you might not actually need to keep all that animation data in memory at all times in the form of full frames.

Obviously such systems will add CPU/Blitter overhead. Swings and roundabouts.

For a more extreme solution, you could even look into a single buffered game. This will obviously be quite hard to do (may even be impossible), but if you can somehow guarantee you won't overrun a frame it may just be doable. Would save a ton of memory.

[Tigerskunk]

Originally Posted by Asman

@saimon69
blit 1 - block0,
blit 2 - block1,
blit 3 - block2,
blit 4 - block3

If you change order of blocks then you will have enemy with differ colors
blit 1 - block1,
blit 2 - block0,
blit 3 - block2,
blit 4 - block3

I didn't know that one.. Thanks, Asman!

[Master484]

Here is one palette trick that might work. This is how it's done in Blitz Basic, but surely ASM can do it also.

Use a 32 color palette and split it in two parts: enemy colors and background colors.

And then split the 16 enemy colors into Even and Odd colors, which contain two 8 color palettes for two different enemies. The first enemy uses Even colors and the second enemy uses Odd colors.

And then make two objects: one 4 bitplane enemy, that uses the Even colors only, and another "enemy" that is a solid color 1 bitplane BOB.

And after this, blitting the 4 bitplane enemy alone will make it appear in Even colors, and when you blit the 1 bitplane bob on top of it, the Even colors will change to Odd colors.

And at any time during the gameplay, you can change either the Odd or Even colors, or both, to activate more color schemes. And because the rest of the graphics will be in the other palette part, they won't be affected by this.

Although only two enemy color schemes can be active at the same time, but it shouldn't matter that much; enemies die and re-appear at a fast pace, and at those spots you can change either the Even or Odd colors.

Here is an image that shows how it works:




In that image I used the Tiertex graphics, because they were easy to convert into two sets of 8 colors. But this system should also work for the arcade assets, although then you might need to expand the "enemy palette" part into the other palette half to get more colors, which makes the enemy BOB to have 5 bitplanes. But the trick will still work in the same way.

Also this 1 bitplane bob trick will only alter Even colors, Odd colors won't change. So it's easy to take some Odd colors from the background palette part, such as some general purpose grays, and use them in the enemies.

So you only need one set of 4 or 5 bitplane enemy frames + one set of solid color 1 bitplane enemy frames to do every possible enemy color scheme, which should save a ton of chip RAM.

[mcgeezer]

@Master484

So yes this is similar to what I'm thinking and I keep coming back to it.

I'll have a 5 bitplane display. I'll use 16 colours of the available 32, different enemy colour will correspond to the bitmap selection as I choose below.

Bit	1	2	3	4	5
Val	1	2	4	8	16
Colours	0-1	2-3	4-7	8-15	16-31
					
Enemy 1	0	1	1	1	1
Enemy 2	1	0	1	1	1
Enemy 3	1	1	0	1	1
Enemy 4	1	1	1	0	1
Enemy 5	1	1	1	1	0

This should yield the following available palettes in the colours registers.

Register	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
Enemy 1=	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y
Enemy 2=	Y	Y	N	N	Y	Y	N	N	Y	Y	N	N	Y	Y	N	N	Y	Y	N	N	Y	Y	N	N	Y	Y	N	N	Y	Y	N	N
Enemy 3=	Y	Y	Y	Y	N	N	N	N	Y	Y	Y	Y	N	N	N	N	Y	Y	Y	Y	N	N	N	N	Y	Y	Y	Y	N	N	N	N
Enemy 4=	Y	Y	Y	Y	Y	Y	Y	Y	N	N	N	N	N	N	N	N	Y	Y	Y	Y	Y	Y	Y	Y	N	N	N	N	N	N	N	N
Enemy 5=	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N

Each enemy type I'll just blit the required 4 bitplanes, it won't be the fastest method as I prefer to do one shot blits with full interleaved masks but this is a compromise.

The other compromises I will do are to hold the death frames of the main guy in fast ram and use a CPU sprite based copy when needed which is only when the guy dies. The other compromise is to hold the tiles in slow ram and cpu copy those too.

My calcs are roughly like this...
Chip ram
135Kb CHIP Triple Screen buffer (45kb * 3)
60Kb CHIP Main Dude Bobs+Mask
140Kb CHIP Enemies Bobs+Mask
80Kb CHIP Mod
40Kb CHIP SFX
2Kb CHIP COPPER
30Kb CHIP Hardware Sprites for Fences/Mesh Bob/Mask
487Kb Total

120Kb FAST Game Tiles
40Kb FAST Main Dude Death Bobs+Masks
50Kb FAST Evil Due Bobs+Masks
80Kb FAST Game Code/Data
290Kb Fast

All guestimates but I think it will work.

[redblade]

Originally Posted by mcgeezer

I cant port something that will run at 25fps.

Is that your company motto?

[QUOTE=Master484;1374909]And about the enemy graphics, them I would handle this way: for most frames I would separate the boots from the main body. The reason is that the boots can be made with 3 colors, so they can be 2 bitplane BOBs. Every enemy will then use these same boots. This in a way "shortens" the enemy graphics height by some 10 pixels. And for the rest of the body I would try to make a unified 8 color palette for all enemy types, if possible.

Also when the enemies die, this I would simplify by using only 3 shades of gray for all those frames when the enemy "melts" into the ground, so that all enemies can then use this same death animation. And also the player's pants I would make with those same 3 shades of gray. This would make about half of the player a 2 bitplane BOB, saving a lot of chip RAM.

And sprites I would maybe use for the bullets, in combination of BOBs if all sprites are already in use. Or maybe sprites could be used to bring more color to the backgrounds if the game uses 16 color mode. The ceiling fans could be sprites, or maybe the sprites could be behind the playfield, and used for the opening doors, or stuff like that. And I think some enemy types never go behind the fences or come from doors...so they could be sprites.

Originally Posted by Asman

@saimon69
Great example to explain how save memory for enemy sprites.
as far as I remember all four enemies from your screenshots share the same frames but differ colours. Its very easy to do this on Amiga. One enemy frame has 32x64x4 stored as four 1 bpl frames/blocks (as sequence), frame = 4 blocks (block0, block1, block2, block3), more technically there are four memory blocks 32x64 pixels ( 4 * 64 = 256 bytes). So enemy frame takes 1024 bytes. Of course you need mask which takes 256 bytes. To blit enemy you need 4 blits.
blit 1 - block0,
blit 2 - block1,
blit 3 - block2,
blit 4 - block3

If you change order of blocks then you will have enemy with differ colors
blit 1 - block1,
blit 2 - block0,
blit 3 - block2,
blit 4 - block3

But I am pretty sure that trick is well known for programmers But the problem is to organize colors in proper way, I think.

Even with this idea I am think that 512KB CHIP is not enough. Too many objects with many frames, especially I mean about later levels when objects with differ levels are mixed.

Originally Posted by Master484

Here is one palette trick that might work. This is how it's done in Blitz Basic, but surely ASM can do it also.

Use a 32 color palette and split it in two parts: enemy colors and background colors.

And then split the 16 enemy colors into Even and Odd colors, which contain two 8 color palettes for two different enemies. The first enemy uses Even colors and the second enemy uses Odd colors.

And then make two objects: one 4 bitplane enemy, that uses the Even colors only, and another "enemy" that is a solid color 1 bitplane BOB.

And after this, blitting the 4 bitplane enemy alone will make it appear in Even colors, and when you blit the 1 bitplane bob on top of it, the Even colors will change to Odd colors.

And at any time during the gameplay, you can change either the Odd or Even colors, or both, to activate more color schemes. And because the rest of the graphics will be in the other palette part, they won't be affected by this.

Although only two enemy color schemes can be active at the same time, but it shouldn't matter that much; enemies die and re-appear at a fast pace, and at those spots you can change either the Even or Odd colors.

Here is an image that shows how it works:




In that image I used the Tiertex graphics, because they were easy to convert into two sets of 8 colors. But this system should also work for the arcade assets, although then you might need to expand the "enemy palette" part into the other palette half to get more colors, which makes the enemy BOB to have 5 bitplanes. But the trick will still work in the same way.

Also this 1 bitplane bob trick will only alter Even colors, Odd colors won't change. So it's easy to take some Odd colors from the background palette part, such as some general purpose grays, and use them in the enemies.

So you only need one set of 4 or 5 bitplane enemy frames + one set of solid color 1 bitplane enemy frames to do every possible enemy color scheme, which should save a ton of chip RAM.

Thanks for that guys, interesting tutorial on palette selection there.

[saimon69]

Originally Posted by Master484

Here is one palette trick that might work. This is how it's done in Blitz Basic, but surely ASM can do it also.

Use a 32 color palette and split it in two parts: enemy colors and background colors.

And then split the 16 enemy colors into Even and Odd colors, which contain two 8 color palettes for two different enemies. The first enemy uses Even colors and the second enemy uses Odd colors.

And then make two objects: one 4 bitplane enemy, that uses the Even colors only, and another "enemy" that is a solid color 1 bitplane BOB.

And after this, blitting the 4 bitplane enemy alone will make it appear in Even colors, and when you blit the 1 bitplane bob on top of it, the Even colors will change to Odd colors.

And at any time during the gameplay, you can change either the Odd or Even colors, or both, to activate more color schemes. And because the rest of the graphics will be in the other palette part, they won't be affected by this.

Although only two enemy color schemes can be active at the same time, but it shouldn't matter that much; enemies die and re-appear at a fast pace, and at those spots you can change either the Even or Odd colors.

[snip]

Also this 1 bitplane bob trick will only alter Even colors, Odd colors won't change. So it's easy to take some Odd colors from the background palette part, such as some general purpose grays, and use them in the enemies.

So you only need one set of 4 or 5 bitplane enemy frames + one set of solid color 1 bitplane enemy frames to do every possible enemy color scheme, which should save a ton of chip RAM.

Once again, one of the tricks appeared in Powder, but there we were using just four bitplanes

[roondar]

Out of interest (and because I still think it can apply here as well): did Amiga games actually use "partial*" animations?
Or did everyone just store full frames of animation?

It seems such a logical way to save space, yet I never seem to hear much about it.

*) meaning, keeping only the part that actually changes in memory and then updating the bob using just those small parts? Or building a bob out of smaller chunks instead of having full images? Or perhaps go full-on-tile based and blit bobs based on 16x16 chunks? Or some other way to build bobs up in several stages to save memory?

Stuff like that.

[lmimmfn]

Originally Posted by Galahad/FLT

I think there are more 512kchip/512kslow machines than there are 1meg chip.

1Meg chip came with the later 1.3 Kickstart about 6 months before the A500+ came out I think.

I can't remember the Release date of the a500+ but I got my A500 in October 1990( Screen Gems pack) and it had 1 Meg chip when I added a 2 MB expansion card.

My own experience in general coding is the more optimization required the more time consuming it is.

Would prefer if possible to target 1MB A500 with a view to scaling back for 512MB A500 with another 512MB slow ram, I. E. Simplest form half the framerate and only show half the sprite/Bob animations.
Only my opinion though and I know the difficulty and appreciate that this may finally happen

[Samurai_Crow]

Originally Posted by roondar

Out of interest (and because I still think it can apply here as well): did Amiga games actually use "partial*" animations?
Or did everyone just store full frames of animation?

It seems such a logical way to save space, yet I never seem to hear much about it.

*) meaning, keeping only the part that actually changes in memory and then updating the bob using just those small parts? Or building a bob out of smaller chunks instead of having full images? Or perhaps go full-on-tile based and blit bobs based on 16x16 chunks? Or some other way to build bobs up in several stages to save memory?

Stuff like that.

Metro Siege uses partial animation bobs using an old version of Spriter for the part alignment editing.

[Tigerskunk]

I second that, really insightful stuff here.
Always wondered how I'd do different colors for players in a fighting game with each selecting the same fighter without keeping two copies of the same player in RAM.

This is the solution..

[mcgeezer]

First off...

This what I post now is simply a technical demo, it is by no means any commitment that I am porting the full game... I'm not, it is simply an experiment.

So please - do not link to the video, if I find it linked anywhere (Social Media, IRN, VITNO etc...) I will pull it as it is meant for a technical discussion.

With that said...

[ Show youtube player ]

This is running AGA, but it might be able to run OCS... not sure yet.

Answer via reply how I get the hero to go in front of and behind the fence when he jumps, it shouldn't be to difficult to work out.

I repeat though - THIS IS ONLY A TECH DEMO USING ARCADE SPRITES.

Geezer

[DanyPPC]

Looks great !

[malko]

Nice tech. demo

[Tigerskunk]

WOOOAH, GEEZER IS PORTING ROLLING THUNDER!
(just joking... )

Looks awesome, mate!

[malko]

Originally Posted by Steril707

WOOOAH, GEEZER IS PORTING ROLLING THUNDER!
(just joking... ) [...]

I bet he is creating the engine to port Shinobi, but to cover the tracks, he shows us Rolling Thunder sprites

[mcgeezer]

Originally Posted by malko

I bet he is creating the engine to port Shinobi, but to cover the tracks, he shows us Rolling Thunder sprites

Ohhh if only you knew.

Tough competition for 2020 on amiga.

[Tigerskunk]

Originally Posted by mcgeezer

Ohhh if only you knew.
Tough competition for 2020 on amiga.

That's why I will move to the Spectrum Next..

(just joking..

Or am I ?



)

[roondar]

Great work, looking really nice so far

Originally Posted by mcgeezer

Answer via reply how I get the hero to go in front of and behind the fence when he jumps, it shouldn't be to difficult to work out.

Hmm, I wonder how it could be done