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