Conversion Capers: Rygar
 

I've never seen a thread like this before so thought it might be an interesting idea for some of the programmers on here.

Let's imagine back in the late 80s or early 90s you were employed to convert a game to the Amiga. The boss has just given you the arcade machine and you've got to tell the other people helping you the approach you'll take.

And the developer isn't Tiertex so you didn't have to produce a shitty 16-colour, no-hardware-sprites, rip-off-the-fans-with-an-st-port version. How would you approach converting the game? (I'm thinking OCS/ECS machines here but no harm considering AGA if you prefer).

I've attached a bunch of screenshots and will explain some of the important points:

1. Original screen size is a modest 256x224
2. The scrolling gameplay area is only 248x184
3. The foreground layer is regularly the entire height of the screen (trees on pic 2)
4. There is a rather large parallax layer, but it does contain a lot of repeated graphics in some cases (pic 3 and 4)
5. There is tile animation, particularly on the water levels (pic 4). A rather large chunk of the screen can be animating (only 2-3 frames by the looks of it)
6. Some levels have a static background layer (the sun in the 5th pic)
7. There appears to be about 5 screens worth of background graphics (16x16 tiles) and then the moving objects are another 5 screens worth of 16x8 pixel graphics
8. For the majority of the game, it's horizontally scrolling only. In a few caves near the end there's a little vertical only scrolling when you're climbing a rope

To see it in action, watch the Rygar arcade longplay.

I'm really curious to know what approach you personally would take if you had to convert this game to the Amiga! eg:

1. Would you go for 32 colours/half-brite/dual playfield mode?
2. What memory requirements do you think you could achieve?
3. What would you use the 8 sprites for?
4. Would you drop the parallax layer or make it smaller?
5. Do you think you could make a version of the game running at 50 frames per second or you'd go for 25 (or perhaps 25 for updating everything but smooth scrolling the screen at 50fps to fake it)
6. How would you handle the water animation? Would you use colour cycling?
7. Would you double, triple or even single buffer the screen?

Coders, step up to the plate and scribble down your initial thoughts!

PS: I could have picked any old unconverted game, I just picked this one as it has things like a large palette and parallax which can challenge the Amiga.

PPS: Sandruzzo's google drive link

Speaking as someone who worked at Tiertex.... ;p

I'd use 4 bitplanes for the main screen using a horizontal barrel scroll, just feeding 1 edge.

I've have the gfx redone and do it overscan.

The panel can be superimposed using hardware sprites. You can also get some parallax using the hardware sprites and change the hpos across the screen.

The sprites would be done in a bgnd save, draw sprite, restore bgnd loop. I'd change the water differently, maybe a so many blocks per frame have the animation. All the blocks within 4 frames.

I'd expect it to work at 60hz.

The ST version would be a screen at a time scroller - you move to the edge and it scrolls in. Anything else would be overkill for the ST and that what ST owners expect anyhow. lol. :)

That's a very nice thread! I am eager to read about any good approaches as well. :)

I think that Rygar is a nightmare, because of the colourful double playfield scrolling.

When thinking about OCS/ECS hardware you only have the possibility to use 3 planes for each playfield, which gives you as little as 7 colours for each scrolling plane and allocates all available DMA slots in the display region. I never considered double playfield mode for any of my projects because of that. It usually looks ugly, when you don't have a very talented graphician.

The other possibility would be to scroll the background plane normally, and redraw all foreground tiles over it, in each frame. But there will be a lot of them, so it is impossible to achieve 50fps.

Other tricks, like using sprites, seem also impossible for such a big and colourful plane.

I would either drop the background plane completely, and replace it by copper bars and some sprite tricks, or accept to run the game at 25fps (or lower).

Maybe copper and sprites wouldn't be too bad, as there are often repeating bands of water, trees and mountains in the background. You probably wouldn't notice too much, when repeating the same sprite there.

I would try to go for an OCS system with 512K Chip + 512K Other memory and I usually prefer double buffering.

Sprites can be used for the background plane. Otherwise for the main character or the shots and explosions.

The small screen width of 256 could be another problem. It looks stupid to have it the same width on an Amiga (although I have seen that in the past). Maybe I would extend the scrolling area a bit (but not so much that I would lose any Sprite DMA).

I would try and aim for a 512k chip + 512k other memory configuration. I'd go with 32 colour mode and extend the game area to 320 pixels wide (if it ran fast enough!)

I would reserve the last 3 colours of the palette (sprite 6 and 7 colours) for repeating those 2 sprites completely across the screen and use the copper to load the graphics for the 2 sprites at the far left of the screen, then a tonne of horizontal position moves to repeat the sprite. That'd give a 32 pixel wide repeating background layer made up of 3 colours.

That would be good enough for the animated lava at the bottom of the screen, the water in the 4th pic and because I'm manually loading the sprite data, you don't worry about losing one sprite's DMA when smooth scrolling.

For the first level with the tall parallax section, I think I'd make it smaller and just blit it with a mask every frame.

The tall cliffs I'd probably simplify the graphics so you would have a cliff pattern repeating every 32 pixels with the sprites rather than lose the graphics.

The 5th pic with the sun could possibly be done with a copperlist changing the background colour to yellow near the middle of the screen and use sprites 6 and 7 to hide the colour change. Then you'd only have to blit the thin black strip.

I'd then have 12 colours left (colours 16-27) for the main character which could also be drawn with 3 sixteen colour sprites. I think Rygar is 32 pixels wide and so one could be his weapon. A decent artist would then have 28 colours for everything else, and probably you could use a few copper changes in certain parts of the screen if the majority of objects can't move across them.

Since I read the setup of 'shadow of the beast" days ago:
I would go for a dual-playfield setup. Yep, this reduces the number of colors but gives you more freedom with the parallax scrolling. I think the parallax scrolling is an immense part of the game experience.Together with the gfx artists I would try to make as much 'copper magic' as possible regarding change of color registers.
The 'status' bars at the top and bottom of the display would be just plain bitmaps (maybe with a reduced depth of 4 instead of 5 bitplanes). The in-game graphics (the scrolling gameplay you mentioned) would be created by 16x16 or 32x32 tiles with the possibility of 'animated' tiles (=> 'redrawing' a certain tile). But: the size of the scrolling gameplay isn't dividable by 16 or 32, I wonder which size the tiles have on the arcade hardware. This is not a problem, of course. I thought that one would go for an width which is a multiple of the tile-size.
All other objects would be blitted with the exception of the player and his weapon which could be hardware sprites.

But yes, dual-playfield could be a problem if you want to have a 'colorful' game.

And yes, I believe it could be done in full framespeed. And yes, the oldschool 512KB Chip + 512KB Fast setup should be enough for this.

It's a 1986 Arcade game with technically nothing special imo. I'm no expert but it should run in full 50fps easily on a A500. With a proper coder team of course. :)

yes i think the same as retro-nerd, it's a 1986 game, and it should be ported quite easily on an Amiga with 1mb of ram. Other than, if you want to go A1200, then the arcade game should be almost a perfect port.

Best home version is probably the late Sharp X68000 port by Dempa. Looks like arcade emulation though.

http://www.youtube.com/watch?v=e9eriWx6ojU

Although I know about this technique, and suggested it myself, I never used it.

Did you collect any experience about the impact it has on the game's performance? For example when I'm repositioning 2 sprites on the whole 320x240 display area, will the CPU and Blitter lose a lot of cycles to access the Chip RAM bus? Is it noticeable in a way, that you can for example only blit 20 16x16 BOBs instead of 50?

That's the point of this thread though - although it doesn't look technically anything special to you, certain things would have to be dropped, changed or tricks used to make it a close copy of the arcade. This isn't the easiest game to make a perfect port of due to the 2 layers and quite a bit of stuff moving so it's interesting to hear what other programmers would do.

Ported easily yes, after all the 8 bit machines have a version. But to make it really close to the arcade isn't quite so easy.

That indeed looks like the arcade game.

There's still a lot of other technical people on here that haven't posted yet, so maybe they would come up with a different approach. I'm thinking Stingray, Galahad, Girv, Mrs Beanbag, MethodGit etc :)

This time you made my day Ian :D

Having watched this video (last 3 levels plus final boss) of the arcade game, I would do the following.

1. Would you go for 32 colours/half-brite/dual playfield mode?

Dual playfield - background plane for background only, foreground for foreground graphics, scoreboard and all enemies.

2. What memory requirements do you think you could achieve?

With some form of compression (I would say PNG but that wasn't created until 1996 and I'm not sure how legal, or how well known, Huffman compression would have been to use in the 1980's) hopefully 512K, with 1 Meg maximum.

3. What would you use the 8 sprites for?

2 sprites for the main character and some of the others for his weaponry.
Not sure what any spares could be used for.

4. Would you drop the parallax layer or make it smaller?

Shouldn't be a problem when using dual playfields.

5. Do you think you could make a version of the game running at 50 frames per second or you'd go for 25 (or perhaps 25 for updating everything but smooth scrolling the screen at 50fps to fake it)

25 fps would be the target, though few games had that as standard, with such lushous graphics, until the early 90's.

6. How would you handle the water animation? Would you use colour cycling?

It would be easy to implement and although it could be done with 2 colours, I think using 3 colours would give a much better and worthwhile effect.

7. Would you double, triple or even single buffer the screen?

The foreground screen would be double buffered, because there is no way to blit all the creatures onscreen without it - the last few levels have 7 or 8 bad guys onscreen at a time. I would be against removing enemies from the game. Some appear to be fixed (e.g ones on the trees) and one time only, whilst enemies on the ground appear to be random.


Now I await remarks from others and what the pro's would do.

I lol'd..... i'm still lol'ing! :laughing:laughing:laughing

Personally, on this game i'd go for Dual Playfield, and the reason for that is if it is mostly horizontal scrolling, you've no issues using colour reloading because theres no up or down movement to bugger it up.

Most of the colours in the first level is greens and browns, with judicious copper reloading, I think even with the colour limitations of Dual Playfield, it could be a very close approximation of the original.

They've also rather neatly helped with the scoreboard as well, extra time gained by not having to overlay on moving graphics, simply clear and plot, or if you're a lazy twat, simply plot over the old graphics depending on the block size you use for the score.

When it comes to any vertical sections, it wouldn't hurt to code it completely differently just for those conditions, does it have parallax when it goes vertical?

It doesn't look a particularly large game.

Personally, I see no reason why a Dual Playfield OCS game couldn't be a very close approximation of the arcade original, maybe use sprites for the main character as he's not exactly the most colourful chap i've ever seen, and hey, just for extra niceness, graduated sky using the copper (not fucking drawing it Tiertex, are you listening???) to give it a nice upgrade over the arcade.

the amstrad cpc version is very close to the version in arcade. The amiga can do even better.

Dual playfield lack of colour problem
 

For those of you that thought they'd go down the dual playfield route, I have grabbed a couple of screenshots. Even with the greatest artist of all time, I am not sure how you could have a game that didn't look completely naff with only 7 colours for the entire foreground layer including enemies. (I am assuming the player is a sprite so you can ignore him!)

The tree section alone uses 9 colours, which would be all the palette used in one foul swoop. Explosions would have to be shades of brown with this palette, the lava enemy would be brown, the grey baddies would be brown etc.

I've also zoomed the trees so you can see the colours a bit better.

Finally I've included a long strip of 4 images. The original with background, then 3 versions in 32, 16 and 8 colours respectively with the background removed.

Admittedly this is just going into Photoshop and reducing the colours (and personally I think Photoshop is pretty useless at picking a palette) so an artist could definitely do better. But I can't see how on earth you could make it look good in 8 colours when some entries would have to remain static for things like the trees, dirt and monsters!

It makes you realise how good some graphic artists are. The Ocean France guys were particularly good at using only 16 colours. And for the record, the beautiful dual playfield Amiga games like Beast tended to be Amiga originals where the gameplay could restrict enemies to strips so the copper could go to town and increase the colours. You don't tend to see many arcade conversions running in dual playfield mode.

Now here is a worthy thread!

Everything below the floor line can be copper reloaded, nothing interferes with that, colour cycling can be used for the fire/lava at the bottom.

Stuff like that will help to not make the trees so glaring.

There has to be some cutbacks.

Yes Ocean France were good with 16colours, but with Toki they had to compromise on screen size.

Just my extra 2 cents regarding using dual playfield:

Running 6 bitplanes takes a lot away from you time-wise. I'd say use 4 and use hardware sprites behind to do a different background to the original - but still parallax. Reuse the hardware sprites to do a score line, etc that's superimposed over the foreground. It will easily fit in 512k if you use paletted objects with each having custom blit routines for various object types. It will easy run at 60hz if you use a barrel scroll, anything else and I have doubts.

I'd say you can't do an exact clone, but an 'artistic impression' of the game could be pretty good, even better than the original.

I'm with Galahad. You can use the copper to change colours midscreen for the graphics. For example you could do this for the enemies, as the winged creatures appear to always be high up in the tree or flying high in the sky and the ones on the ground don't seem to be able to jump high up on the screen.