Rolling Thunder - Amiga Port

[mcgeezer]

I cant port something that will run at 25fps.

[Tigerskunk]

I'd say A500 512k/512k, but I am biased...

[Solo Kazuki]

Originally Posted by d4rk3lf

Not sure how this relevant is, but Amiga game Deliverance had a very large sprites.
I was very impressed when I discovered it recently.
Works perfectly on A500

[ Show youtube player ]

Yeah, the sprites are probably 25fps... oh well... that's why I said I don't know how relevant is.

No, it's not working perfectly. When more bigger enemies are on screen game tends to slowdown (e.g. alien-like ones at 3:00~3:30). I had once five of them, game was like slideshow in this moment.

[Asman]

Originally Posted by mcgeezer

And this is what worries me, some of the enemy animations are huge.
I'll take the first step and extract all the graphics and see where things stand.
I'll report back here but it isn't clear cut - however I am keen on a "what could have been scenario for the A500".

Indeed, i just checked albatros https://www.spriters-resource.com/ar...r/sheet/32986/ and there are about 90 frames (89 if I count correct). So even if we assume 48x64x4 then it takes 136704 bytes (89 frames). Also I tried to count maskers frames in MAME and I failed, too many heads, other bodies and so on.. but I assume that there is also about 70 or more frames for one type of maskers. There are for sure 3 differ types so finally 210 frames (one frame 32x64x4) takes 215040 bytes. What about tiles, masks for enemies, balcony, mesh.

Now I see three options:
1. crunch gfx data and decrunch in fly.
2. store some gfx data in SLOW and use processor to paste it on screen
3. increase requirments to 2mb CHIP - best option for me.

Finally I think that I was pretty naive when I started thinking about version for A500 with 0.5 MB CHIP only

[mcgeezer]

I have a couple of ideas also and would like some input, however before that please could a mod move the thread to a technical section - or steer me to make a new thread?

Cheers, Geezer

[DamienD]

Originally Posted by mcgeezer

I have a couple of ideas also and would like some input, however before that please could a mod move the thread to a technical section - or steer me to make a new thread?

Cheers, Geezer

Tell me exactly which posts out of this two pronged discussion you want moved to a new "coders" thread and it will be done my friend

[mcgeezer]

Originally Posted by DamienD

Tell me exactly which posts out of this two pronged discussion you want moved to a new "coders" thread and it will be done my friend

I think everything from and including post #31 would be ideal buddy.

Nice one!

[BippyM]

Originally Posted by DamienD

Tell me exactly which posts out of this two pronged discussion you want moved to a new "coders" thread and it will be done my friend

I've just logged in to sort this.. Thanks pal

[saimon69]

If i remember clearly most RT enemies could be easily split in two - from waist and up; you can do game internals at 25 and enemies update at 50 in Team 17 style and you can use 16 colors for sprites and enemies (plus a subpalette system like powder to save RAM) since RT has no parallax; main hero can have its own 16 colors palette (would even say 8 since the bottom is black pants)

OK i went to check a longplay and i might be wrong in the splitting in two; however some splitting of parts could help since most enemies are identical; the arcade game goes around this because of its 16 color palette per sprite system, an amiga game could take this on a different take and split like two sprites for body, two for head, two for feet, two for gloves or a mix between sprites and bitmap (is getting complex to describe so maybe not a good idea) - Metro siege does split body parts and assembles together but has less enemies and a slower game dynamic.

[mcgeezer]

The masked enemies can be deceptively large (64x58 pixels)... and they are 16 colours.

I'm tinkering with trying to get different colours out of the same bitmap using a 5 bitplane screen but using only 16 colours... like blitting 5 bitplanes then going back and removing one of the bitplanes using the masked bits.

It's not going well and this is deceptively tough on the constraints of a an A500.

The game will have to run at 50 frames otherwise it will fail.

The main sprite I can probably handle with attached hardware sprites and the blitter. The fence as well can be managed with hardware sprites and the priorties changed in the playfield when the guy jumps over... the problems is, the enemies can jump over them too.

This isn't easy by any stretch.

[DamienD]

Originally Posted by mcgeezer

I think everything from and including post #31 would be ideal buddy.

Nice one!

Done

[JudasEZT]

For A500, instead of a port, would be much better a Conversion adjusting elements for convenience.

Best option could be by reducing the numbers of frames of some anims, and even its size. Also repaint graphics and change whatever be needed.
All the colours of RollingThunder could fit in a simply 16 colours palette with no problem. But I see the fences a problem.

I think this game would need a real 8-way scroll, because there are parts which scrolls intensively in diagonal. Anyway it would be a reasonable sacrifice if its substituted for a wise fake 8 way scroller.

The bigger problem I see is to make fences with sprites. I think fences are too wide to be able to reproduce with sprites. Maybe a layout with DualPlayfield would work for that.. just it will make that paint graphics will be more difficult due to palette limitations. ( as grafician I love that challenge )

So a good layout for having fences would be:
Layer 1 - Background 7 colours - Tiles with main stage graphics
Layer 2 - Foreground 8 colours - with enemies, enemies projectyles, fences and some obstacles
Layer 3 - 1P Sprites and Player Bullets ( maybe flickering the bullets to allow more bullets aligned in same Y-coordinates )

The priority of 1P Sprites channels could be switched respect fences.. I think

[mcgeezer]

Originally Posted by JudasEZT

For A500, instead of a port, would be much better a Conversion adjusting elements for convenience.

Best option could be by reducing the numbers of frames of some anims, and even its size. Also repaint graphics and change whatever be needed.

I’m beginning to see why Tiertex did what they did with the display.

The arcade sprites are 56 pixels in height and the display is 224 pixels high.
They chose to reduce the sprites to 32 pixels and thr display to 128 pixels thus keeping the aspect ratio.

I dont want any gfx artists doing any work on this, any work done will be from the arcade board so no repainting of anything.

[Tigerskunk]

Originally Posted by mcgeezer

I’m beginning to see why Tiertex did what they did with the display.

I never thought I'd read that sentence on this forum...

(btw, what happened with your new AGA game, Geezer? )

[Minuous]

Maybe it should be a multiload when running on a 512K machine; that way not all graphics data needs to kept in RAM at all times.

[Solo Kazuki]

Originally Posted by JudasEZT

For A500, instead of a port, would be much better a Conversion adjusting elements for convenience.

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.

I'm with Graeme about "as close as possible" conversion. Nowadays is AGA chipset and OCS/ECS users can use SAGA driver with Vampire cards. Even RTG (8bit modes are possible on AGA) if it's needed. So today is much less reason than in past to forcing reductions.

Originally Posted by Steril707

I never thought I'd read that sentence on this forum...

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

[mcgeezer]

Originally Posted by Steril707

I never thought I'd read that sentence on this forum...

(btw, what happened with your new AGA game, Geezer? )

No graphics guy mate.

Might still keep it on the back burner though.

[chb]

Originally Posted by mcgeezer

The main sprite I can probably handle with attached hardware sprites and the blitter. The fence as well can be managed with hardware sprites and the priorties changed in the playfield when the guy jumps over... the problems is, the enemies can jump over them too.

The problem here, if I'm not mistaken, are the priorities in single playfield mode. Sprites can only go in front of or behind everything that is bitmap (well, apart from color 0 of course), so you cannot have your player sprite in front of the background but behind some other bitmap object. And the player goes behind a lot things (fences, meshes, stairs, enemies..) while being still in front of some background graphics. Most consoles have priorities per tile, something the Amiga is sorely missing.

You can change priorities between sprites by assigning them to different channels, but I doubt you can do everything that goes in front of the player with sprites, even when multiplexing them.

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

I'd guess in the end you'd need to foreground-mask everything moving, maybe keeping a per-tile flag table in ram so you can quickly determine if a bob in some position may need masking or not. If tiles are bigger than every bob, checking four tiles is enough. May give a lot of false positives, though.

This isn't easy by any stretch.

Yep. And if you go AGA people will still complain because the game graphics look very simple (and quite awful IMHO), so they assume it should be easy on OCS.

To be fair, the problem of priorities remains on AGA, but it's probably much easier to work around it with 15 +16 color dual playfield and bigger sprites. And more bandwidth left for the blitter.

[roondar]

Originally Posted by chb

The problem here, if I'm not mistaken, are the priorities in single playfield mode. Sprites can only go in front of or behind everything that is bitmap (well, apart from color 0 of course), so you cannot have your player sprite in front of the background but behind some other bitmap object. And the player goes behind a lot things (fences, meshes, stairs, enemies..) while being still in front of some background graphics. Most consoles have priorities per tile, something the Amiga is sorely missing.

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.


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.

Masking out the sprite data, however, will definitely work.

Yep. And if you go AGA people will still complain because the game graphics look very simple (and quite awful IMHO), so they assume it should be easy on OCS.

This is oh so true. I guess it's just hard to see at a glance whether or not a system can do stuff.

[malko]

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