Conversion Capers: Rygar

[Codetapper]

Originally Posted by Mrs Beanbag

The only bit of parallax I'd be keen to keep is the bit with the giant sun in the background, because that has a lot of character and is quite distinctive. One could do that with two sprites to define the edges of the sun (changing the X-position of the sprites on each line), with the copper changing the background colour to fill in between them.

The only problem with that technique is if you are using colour 0 as black, setting sprites to appear behind the bitplanes and changing colour 0 to the yellow of the sun when required, it means you cannot include colour 0 in any objects that may overlay the sun. You can get around it by having a second black (or near black) palette entry, or refrain from using black.

Other techniques like having the sprites appear above certain bitplanes cause further problems with objects being obscured by the sun or having to do a lot of extra blitting.

[Mrs Beanbag]

Originally Posted by Michael Parent

That is indeed an awesome solution for the big sun back layer Lonewolf10!

Yeah, thanks Lonewolf10, that's some good thinking there.

Originally Posted by Codetapper

The only problem with that technique is if you are using colour 0 as black, setting sprites to appear behind the bitplanes and changing colour 0 to the yellow of the sun when required, it means you cannot include colour 0 in any objects that may overlay the sun. You can get around it by having a second black (or near black) palette entry, or refrain from using black.

The background behind the sun is a dark red anyway, so you'd need another palette entry for black in any case.

[tarr]

After all these years, after lionheart, kid chaos, mr nutz, jim power and other great games experenced amiga coders still think that the amiga c
ould not run a 50 fps rygar?

[Hewitson]

Of course it could, even the 64 does. The issue is doing a perfectly accurate reproduction of the arcade game. It's likely that some compromises would have to be made on the graphics.

[sandruzzo]

The only way to answer to all questions is to do it!

[saimon69]

ok am not a coder but this is how i would treat things in paper, then don't know about how feasible it is.

Plus am tihnking at OCS/ECS machines

First to gain time i would treat things at 25fps so to have a full 16 color for backgrounds, then other 16 for enemies.
Background parallax layer is pretty generic so can even be a rolling bitmap pushed in the holes of foreground
sunset you could use a sprite 4 well chosen colors sohuld be enough
sky we use a opperlist same for lower ground part with lava.

Player could be two 16c sprites plus shield as some 4c sprites (shield rotates so not too much definition)

If someone is willing to expand/debate on this let me know.

[Galahad/FLT]

I think the best effort would be to pick an arcade machine thats doable, and hey.... do it.

[saimon69]

in my opinion rygar is doable as number of colors, music and stuff on screen; was 1986 hardware so not that powerful: will need some tricks but can be done

[sandruzzo]

I think is could be dono with a lot of good. We could use a tecnique like Lionheart to have a lots of color on screen. With a little flicker we could easly have 16 color for each playfield on OCS/ECS. But all must go on 50fps

[sandruzzo]

someone would like to see it for real on amiga? With Gfx I could try to do it..

[dlfrsilver]

you mean if someone can rip the tiles in IFF format, you try ?

[sandruzzo]

Originally Posted by dlfrsilver

you mean if someone can rip the tiles in IFF format, you try ?

Yes I could do it. We need just to plan it. What would ne the target platform
? Ocs/Ecs or Aga?

[Nekoniaow]

Originally Posted by Codetapper

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!

1. Screen mode:
   I would not forego DMA bandwidth and colours on the altar of parallax scrolling.
   Even if one could manage to faithfully reproduce the original colours using only a palette of seven you would barely have enough DMA time available to cookie cut blit all the monsters. This said, what counts is the number of colours per scanline and Rygar can have way more than seven just on the foreground: uglies and scenery reach way higher than that.
   I would start prototyping with five bitplanes then scale that down if the blitter load becomes too much to handle even with double buffering.
   In order to save DMA bandwidth for blitter use I would reduce bitplane depth on the bottom part of the screen, clearly the lava does not require more than three bitplanes (even maybe just two) and the part just above might just need one more. One could possibly reuse the same palette entries for both during the parts where no monsters roam in that place but I'm not sure it's worth the hassle.
2. Memory:
   If you stream everything from disk as the game progresses (which frankly all games written today ought to do) then 512k should be enough. Out of kindness for A1000 users maybe we should try a 256k version.
3. Sprite usage:
   Main character and its weapon of course.
   I would reserve the rest for parallax scrolling assistance: when vertical walls scroll in/out or when a vertical section of tree is in the foreground.
4. Parallax:
   It does not seem that hard to reproduce in many situations. There are many parts of the game where the foreground overlaps the background only over a relatively thin horizontal slice which means that all parts of the background which lie above can simply be hardware scrolled. For these parts you don't even need to use repeating sprites as you suggested. The third image of your initial post (cf http://eab.abime.net/showpost.php?p=908453&postcount=1) is a good example of it and this kind of situation is quite frequent.
   It could be troublesome to handle transitions to places with walls but they don't seem to contain a lot of baddies moving so maybe that can be blit (these are full copies except for the last word so they are DMA efficient). Also the texture of the walls is very repetitive so repeating sprites could possibly be used there.
   
   Even the places with trees in the foreground do not seem above reach: sprites could be used for the portion of the trees which are purely vertical and they could be repeated horizontally by sacrificing accuracy to the original. It's not that all obvious though but it's worth trying.
   
   The second to last level seems the hardest as the foreground playfield extends vertically and has quite a few holes. This said blitting parallax scrolling is usually efficient if you deal with large holes: only the first and last word of the blit need to be cookie cut, the middle portions can just use A and D, also you don't need to copy all bitplanes unless you are clearing objects from the previous frames.
5. frame rate: 50 fps or nothing, it makes a huge difference in the feel of the game. Sacrifice everything else.
6. Water animation.
   I would try to stay closer to the original and thus not use colour cycling.
   For the early level part I would simply be heavy handed and double/triple buffer the slices of the screen where water flows since the water animation seems at most three frames long.
   Since it concerns only a limited fraction of the screen and it's already likely that double buffer should be used anyway then this would be a very cheap way to animate without actually copying anything.
7. buffer depth: I would likely double buffer in order to smooth out the complexities of blitting multiple monsters and possibly parts of the parallax scrolling. But I would double buffer only the parts of the screen which require it: no point in double buffering the top of the screen where very few things happen. Only the middle bottom part usually needs it.

Also a few notes in response to the kittens who said "hey easy for an Amiga" :

Rygar has a lot more than 32 colours on screen and more importantly per scanline: something the copper cannot help you cope with. With dual playfield, one is limited to 15 colours per scanline, and for this particular game it means that foreground scenery and monsters must share 7 colours together: this cannot possibly be good looking.
Edit: Note that Lionheart's monsters are designed with this limitation in mind: they share the same colours as the foreground layers, however Rygar's monsters contain many colours which are not part of the foreground layer.

Also in dual playfield mode you have zerovery little DMA bandwidth available for the blitter and CPU while the screen is being displayed: everything must be done during the off-screen moments and that is not much given how many creatures move onscreen at times.

Doing parallax scrolling in four or five bitplanes without the help of dual playfield is usually very hard if the structure of the playfields does not lend itself to it. Thankfully Rygar level design lends itself to it nicely in many places (but not all!).

Finally note that the C64 has it very easy contrary to the Amiga because it does have a tiled screen mode: by just updating 40x20+ characters the whole screen can be redrawn. And a tiled mode makes parallax scrolling very easy as well since you can encode the parallax effect in the tiles.
The Amiga is not powerful enough to redraw the whole screen each frame so it cannot do full screen parallax scrolling in five bitplanes unless the layout of the screen is very accommodating.

Originally Posted by Codetapper

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.

Why do you say "hide" the colour change?
The copper can wait anywhere on screen so you can change the background color at any pixel you want. Unless you want to have colourful edges you don't need sprites at all except for the top and bottom lines, and then you need only one since you can reuse it vertically.

Then you'd only have to blit the thin black strip.

You don't even have to blit it.

If the sun is pure background colour then there is nothing to blit. Just set another colour of the background to black and you're done, hardware scroll that layer at a different speed than the bottom part and that's it.

Originally Posted by phx

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?

The copper can only work on odd cycles so at most it will steal 4 DMA words per 16 pixels which is the equivalent of 4 bitplanes. With 6 bitplanes, in EHB or HAM and one copper move instructions per 16 pixels you consume as much DMA as 8 bitplanes total and have zero blitter or CPU DMA available while displaying.

If you are using a 4 bitplanes mode, moving two sprites so they fill the screen will consume one move per 16 bit, that is the equivalent of two bitplanes. It can give very nice results but it's actually quite costly. Hence my remarks about "sprite repeat counters" in this thread: http://eab.abime.net/showpost.php?p=...&postcount=177.

When you think about it it's wasted DMA because the time spent to update one sprite position every 16 pixels could be used to draw a two bitplanes playfield in full parallax (if the hardware had eight planes registers) while this technique only allows to draw a repeating background of width 64128 pixels at most.

[sandruzzo]

Why don't do it for Both Ecs/ocs and Aga? I would allow us to have a good conversion for ecs/ocs and perfect one for Aga..

Maybe we can use sprite even for enemies, at least the ones that fly up to the screen.

If Someone can provide my some gfx, I can try to put something on the screen and see how it works.

with dual-playfield mode we can use the second layer to hold some enemies and have them with differt colors from the ones on the foreground layer

[sandruzzo]

A great amiga game: Ruff 'n' Tumble.


http://www.lemonamiga.com/games/details.php?id=920

We could use +512 k of real fast ram, in order to speed up a little this game. And again in order to aid blitter to go full gas we can try to use triple buffer, so we can have a better cookie-cut stuff.

Any fellow amiga graphics that have the good will to do it? I can program this conversion.

[dlfrsilver]

I can do my best to allow you to get a perfect rip of Rygar Graphics

[Hewitson]

I feel the need to argue with many of the posts in this thread. Is an accurate conversion of Rygar not possible with most coders? Possibly. Is it possible with someone who has a C64 level of dedication? Absolutely.

[Rebel-CD32]

If somone can provide all of the graphics assets I'd love to help by coming up with the optimal palette, colour-reducing and remapping the graphics. It may not sound like much, but by doing this process manually I can produce superior results to any automatic colour-reduction feature in graphics software.

[sandruzzo]

Wow we have a team Here! I'm on it. We do the best. We just have to do some tecnicall choices. We go for 32 colors or 16 color, and play aroud with copper?

About screen size I'll keep the original, so we can spare some cicles to use for blitting and stuff like that

[sandruzzo]

For the main player we have zero issue: we are going to use 4 hw sprite with 16 color.