Rolling Thunder - Amiga Port

[Galahad/FLT]

Originally Posted by malko

Reading you makes me wonder how really "bad" were some OCS conversions from BitD. Maybe not that much after all...

Not really. People accept compromises have to be made, maybe less enemies onscreen, maybe smaller enemies, maybe remove some anim frames to keep ram requirements simple.

Some of those things or one or two, people would have been ok with back in the day.

But thats not what Tiertex did, they cut back on EVERYTHING in the conversion until very little remained.

I dont expect McGeezer to do a 1:1 conversion because no-one is paying him even Tiertex wages to do it, a couple of compromises here and there, and seeing his skill with Rygar, its plain to me that a much superior conversion is likely.

Some compromises dont equate a failed conversion, but Tiertex compromised everywhere, and thats the difference.

[Tigerskunk]

We are talking about a "conversion" that ran around 4 frames a second in a small part of the screen.
I'd like to know how it's even possible for that game to be that slow, even if you are redrawing everything every frame.
Add to that, that the Amiga version looks incredibly ugly.

This conversion is pure shite.

[blade002]

Given what the A500 was pushed to by the end of it's life I think from my personal opinion that a stock 1MB A500 could have EASILY handled Rolling Thunder as a near perfect port.

[Master484]

If I was making this game for the A500, then I think I would do it this way:

Both the enemies and the Player would be BOBs. The fences and wire meshes would be normal background tiles, but I would also have BOB versions of them, so that when someone goes behind them I can then draw that fence part in the front.

And in the beginning of the frame I would sort all moving objects into two groups: those who are behind a fence, and those that are in front of it. And then I just draw the "behind" group first, and then draw the fence pieces, and finally draw the "front" group objects.

A sorting system like this is needed to draw everything in the correct Z-order; because often you have stuff like: an enemy behind a fence, and another enemy in the front of the fence, at that same spot, which means 3 layers of objects that have to be drawn in the correct order. And in addition to this, in some levels there are opening doors that are behind those fences, creating a fourth layer of moving objects.

---

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.

And 25 FPS with occasional slowdowns would be an acceptable frame rate...still much better than the 4 FPS of the Tiertex version.

[chb]

Originally Posted by chb

You could mask your player sprite - slower, but still faster than a bob with two masks (shape and foreground), and additional colors.

Originally Posted by roondar

You could solve the solve the issue of hardware sprites moving between objects by masking out part of the sprite data with the Blitter as and when needed. This is clearly slower than just using a hardware sprite, but still much faster than using a bob.

Originally Posted by roondar

The point about sprite priorities reminds me of something I tested ages ago. Not 100% sure anymore... But I seem to recall you can use the sprite to PF1/PF2 priority settings even when running in single playfield mode. If I'm remembering that correctly, you could (with a lot of fiddling and limitations in colour use) have a sprite display between graphics. Of course, it's questionable whether or not this actually is all that useful in the real world but I thought I'd mention it.

Oh, that's very cool, thanks for the info! I guess this means priorities behave exactly like in dual playfield with regard to the bitplanes, but colors like in single playfield mode? That would mean that e.g. for 2 + 2 bpl mode colors 0,2,8,10 would go behind the sprites (because bits in plane 1 and 3 are 0, so transparent in dpf) and the rest in front of them, when sprites are setup to be between PF1 and PF2. Hmmm, that would even be quite usable for some scenarios. Don't know if it helps for Rolling Thunder, as the enemies can also go behind a lot of things and have to be drawn with bobs, but interesting anyway!

[roondar]

Originally Posted by chb

Whoops! Missed that bit

Oh, that's very cool, thanks for the info! I guess this means priorities behave exactly like in dual playfield with regard to the bitplanes, but colors like in single playfield mode? That would mean that e.g. for 2 + 2 bpl mode colors 0,2,8,10 would go behind the sprites (because bits in plane 1 and 3 are 0, so transparent in dpf) and the rest in front of them, when sprites are setup to be between PF1 and PF2. Hmmm, that would even be quite usable for some scenarios. Don't know if it helps for Rolling Thunder, as the enemies can also go behind a lot of things and have to be drawn with bobs, but interesting anyway!

That's how I remember it, yes. But: please be aware that although I'm relatively sure this works, I'm still talking about one of many random tests I did over three years ago. So it's also possible I'm mixing stuff up here. Hence my caveat

It's certainly something worth re-testing though. Especially as other playfield related registers work in single playfield mode just fine (f.ex. the playfield shift values). Hmmm, a pity I'm not at my PC right now.

[JudasEZT]

Originally Posted by Solo Kazuki

And in many cases that's the reason of bad ports. Cut here, cut there, reduce colors, drop some frames, lower memory requirements, etc. And the next "worse than..." game will appear.

Mind that (i suppose) it's about graphic reductions, not engine itself...

Nah.. its a matter of taste. It doesnt mean that make a conversion have to be a bad Tiertex game.

I think a Port of Karnov would be possible..

[malko]

@Galahad : I know and you're right. Simply this is how I percieved the exchanges. Anyway, thanks for re-pointing the situation

[Frog]

Originally Posted by JudasEZT

I think a Port of Karnov would be possible..

Karnov is a wonderful game.
Wardner can be possible to be ported on amiga imo too.

[DamienD]

Originally Posted by Frog

Wardner can be possible to be ported on amiga imo too.

Wardner is friggin' awesome. Would be very cool to have an Amiga port

.Same as Legend of Hero Tonma or Blood Bros.

...but we are getting way off topic here.

[dlfrsilver]

Well very honestly, Rolling Thunder is not a game i would port on A500. Too many colors, and the sprites are really big.

Otherwise, if A500, the only way would be to use a dynamic loading system, like the one used on St dragon and ninja warriors, which would allow to gain memory permanently, and also keep the amount of colors highest possible.

[Tigerskunk]

Originally Posted by dlfrsilver

Well very honestly, Rolling Thunder is not a game i would port on A500. Too many colors, and the sprites are really big.

Otherwise, if A500, the only way would be to use a dynamic loading system, like the one used on St dragon and ninja warriors, which would allow to gain memory permanently, and also keep the amount of colors highest possible.

I'd object here.
First off, no parallax that eats into DMA time whatsoever.
Then, there are rarely more than 3 enemies on screen at the same time. Size around 48x50.

Which leaves the colours.

I would do a prototype that checks how many bitplanes are possible with 4 48x50 sized BOBs on screen with a triple buffer.

I feel this might be very doable on a plain A500 with at least 16 colours, but maybe even 32. in 50 fps off course.

[Galahad/FLT]

Originally Posted by dlfrsilver

Well very honestly, Rolling Thunder is not a game i would port on A500. Too many colors, and the sprites are really big.

Otherwise, if A500, the only way would be to use a dynamic loading system, like the one used on St dragon and ninja warriors, which would allow to gain memory permanently, and also keep the amount of colors highest possible.

The type of loading used in those games is not some kind of free no penalty resource, valuable DMA resources are lost for that loading process, and not suited to high action games.

It shouldnt really have been used on SWIV, it would have been far better to have the game copying from ram instead.

[mcgeezer]

I'm quite confident that the processing power behind the A500 is capable of getting all the required enemies on screen, it's roughly 6 * 48x64px x 4 bitplanes ... however that's not what the key problem is.

The key problem is getting all the sprites into chip ram.

One available option is to take the Tiertex graphics and re-program the game with them instead (I would fix the display size though to 192 height). Unless I can find a solution to have one enemy set from the arcade sprites but with different colours then only AGA will be able to do it simply because it has the required chip ram.

[dlfrsilver]

Originally Posted by Galahad/FLT

The type of loading used in those games is not some kind of free no penalty resource, valuable DMA resources are lost for that loading process, and not suited to high action games.

It shouldnt really have been used on SWIV, it would have been far better to have the game copying from ram instead.

Well indeed. However, NW and STD ran with 512k of chip only. Wonder what it would do with 2mb of ram.

And yes as Graeme pin pointed, the data size is a problem :/

many differents sprites/elements to crave in ram.....

[saimon69]

I did chose this image because is crowded; see how enemy uses two colors for body, three for hood, two for pants ,three for badge and gun, two for gloves. Ninjas use just two colors overall.
I wonder how feasible is to split an enemy in several parts to save space and then recombine him for display

[mcgeezer]

Originally Posted by saimon69

I did chose this image because is crowded; see how enemy uses two colors for body, three for hood, two for pants ,three for badge and gun, two for gloves. Ninjas use just two colors overall.
I wonder how feasible is to split an enemy in several parts to save space and then recombine him for display

It would mean I have to upgrade the shit out of my sprite driver.

(which might be necessary).

[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.

[mcgeezer]

Originally Posted by Asman

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

yep - this is what I've been looking at. With each block having a 2 bit/4 colour combination I can't get the colours to work properly.

Attached is the frames I have extracted for the main sprite.

To do this I used MAME and disabled the tiles, recorded the video and then used..

ffmpeg -i video.avi -r 60/1 frames%03d.png

which has produced alot of frames that I've then extracted.

The hero guy I can get into 412 lines at 4 bitplanes... (82Kb).

What is the feeling around a 1mb chip ram A500/OCS? I know back in the day I had an expansion that gave me 1mb chip and 1 mb fast total.

Geezer

[Galahad/FLT]

Originally Posted by mcgeezer

yep - this is what I've been looking at. With each block having a 2 bit/4 colour combination I can't get the colours to work properly.

Attached is the frames I have extracted for the main sprite.

To do this I used MAME and disabled the tiles, recorded the video and then used..

ffmpeg -i video.avi -r 60/1 frames%03d.png

which has produced alot of frames that I've then extracted.

The hero guy I can get into 412 lines at 4 bitplanes... (82Kb).

What is the feeling around a 1mb chip ram A500/OCS? I know back in the day I had an expansion that gave me 1mb chip and 1 mb fast total.

Geezer

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.