Conversion Capers: Rygar

[sandruzzo]

Originally Posted by kamelito

Pretty nice good work.
@Sandruzzo why not just test Trachu ideas in the code and see if it work or not instead of thinking it's not gonna work.

Kamelito

I said so some post ago..

[kamelito]

Very good !
Thanks
Kamelito

[Trachu]

There are some 64colour games like Battle Squadron where they manage to get 50fps.

As for me since I am doing graphics department, waiting for the decision which colour mode we will use, I am doing what I can.
As I said before sprites can use only 15 colour registers, and since we will use 4 for background we are left with 9 free colours for sprites (plus background).
We should not use 6 colour registers dedicated for background, because while sprites are constant throught the game, background colours change from level to level.
Having that in mind I have reduced the sprites into 10 colours only. I did it in order to preserve all details. Take a look.

I would do something nice with the background also, but I do not know what program user NOBODY used for his excellent work.
I am using Grafx2, irfanview and some others for colour quantisations

[sandruzzo]

If we use 64 colors we have to have better gfx that the 32 version, otherwise it's a waste of time.

You've done a great work Trachu

[kamelito]

IIRC Battle Squadron. http://www.codetapper.com/amiga/inte...rtin-pedersen/
Kamelito

[sandruzzo]

battle squadron was designed for amiga, Rygar no

[ReadOnlyCat]

Originally Posted by Trachu

There are some 64colour games like Battle Squadron where they manage to get 50fps.

Battle Squadron uses only 5 bitplanes.

I am not saying this is is impossible but before deciding to draw 6 bitplanes you should verify if the blitter bandwidth exists at all for it.
There is little pint in designing assets for EHB if you find out that the game cannot run at 50 FPS (or even 25 actually given how limited DMA bandwidth remain with EHB + copper partial background).
I would recommend to prototype first with coder drawn bobs and actual level data before making decisions about the rendering.

[Codetapper]

Originally Posted by Trachu

There are some 64colour games like Battle Squadron where they manage to get 50fps.

Once again, don't let inconvenient facts get in the way of your guesses. Battle Squadron updates the bobs 25fps not 50fps, only the sprites move every frame.

And as ReadOnlyCat has said, it's always 5 bitplanes not 6. And as for DMA being "wasted" when sprites are enabled in 5 bitplane mode, I guess you don't count the copper wait command that frees up all those cycles when you don't need to multiplex the sprites on a line, correct?

Elfmania can only switch to 4 bitplane mode at the very bottom of the screen because it's impossible for any bobs to exist down there. Coins and the characters never go below a certain Y co-ordinate, only sprites can which are displayed on top anyway. This is a completely different kettle of fish from Rygar where many objects pass through the lowest screen pixel. It's not a good example to backup your idea for this case.

The EHB idea also wastes even more DMA time because presumably at the end of each scanline you're having to reset the 6th bitplane pointer to a blank area or waste a lot of chip memory.

[sandruzzo]

My Guess is that Elfmania switch to 4 plane we it can. I mean, if bobs are in the bottom of the screen, they can switch to 4 in the up portions of it, just with a little dynamic copper list. Not a huge tasks to do.

[Codetapper]

There's no guessing about it. It's 5 bitplanes for the entire screen except the tiny height under the players. When one of the players is jumping, the entire screen is 5 bitplanes as part where it would switch to 4 bitplanes is already off the bottom of the viewable screen.

Check the copperlist yourself, there's never any need to guess anything.

[Trachu]

Originally Posted by Codetapper

Once again, don't let inconvenient facts get in the way of your guesses. Battle Squadron updates the bobs 25fps not 50fps, only the sprites move every frame.

And as ReadOnlyCat has said, it's always 5 bitplanes not 6. And as for DMA being "wasted" when sprites are enabled in 5 bitplane mode, I guess you don't count the copper wait command that frees up all those cycles when you don't need to multiplex the sprites on a line, correct?

Elfmania can only switch to 4 bitplane mode at the very bottom of the screen because it's impossible for any bobs to exist down there. Coins and the characters never go below a certain Y co-ordinate, only sprites can which are displayed on top anyway. This is a completely different kettle of fish from Rygar where many objects pass through the lowest screen pixel. It's not a good example to backup your idea for this case.

The EHB idea also wastes even more DMA time because presumably at the end of each scanline you're having to reset the 6th bitplane pointer to a blank area or waste a lot of chip memory.

Just for your information, I get the idea of EHB in Battle Squadron from your page when I checked the numer of colours of PNG you posted there. When they counted 59 i assumed it must be EHB. Now i checked and indeed it works on 5 bitplanes, so once again I made a mistake and I propobably will make a 1000 more in my life, so if your intention is to wait for my mistake to enter the conversation, you will get a lot of chances.

I am really dissapointed about you. For a guy I who made such a great page about amiga tricks I expected MORE. Instead you come here only to tell us you cant do that, you cant do this etc.
Would you be so kind to tell us what actually we can do?
When I make an argument I made a reasons behind it and when problemms comes about it I look for solutions.

So far I have shrinked 88 colours of level 1 into 40 without only minor changes in quality, going lower costs noticeable difference. Also do you realise if we want to use 4 sprites for background the actual numer of colours we can use in every level are 29 in 5bitplane scenario or 58 in EHB.

Stop being counterproductive and help us for a change?

[roondar]

Originally Posted by Codetapper

Once again, don't let inconvenient facts get in the way of your guesses. Battle Squadron updates the bobs 25fps not 50fps, only the sprites move every frame.

And as ReadOnlyCat has said, it's always 5 bitplanes not 6. And as for DMA being "wasted" when sprites are enabled in 5 bitplane mode, I guess you don't count the copper wait command that frees up all those cycles when you don't need to multiplex the sprites on a line, correct?

Elfmania can only switch to 4 bitplane mode at the very bottom of the screen because it's impossible for any bobs to exist down there. Coins and the characters never go below a certain Y co-ordinate, only sprites can which are displayed on top anyway. This is a completely different kettle of fish from Rygar where many objects pass through the lowest screen pixel. It's not a good example to backup your idea for this case.

The EHB idea also wastes even more DMA time because presumably at the end of each scanline you're having to reset the 6th bitplane pointer to a blank area or waste a lot of chip memory.

I always thought the way Battle Squadron (and many others, including old games like Menace) deal with blitting was an ingenious way to compromise for the lack of blitter oomph.

Updating player sprites at 50Hz (and sometimes scrolling at 50Hz) gives a lot of the plus points of a 50Hz update, which more or less hides the lower update speeds of the enemies.

Personally, I'd definitelty consider it for the Rygar port, when I look at that game it seems to do far too much in a frame for a 50Hz port with all the stuff going on (the later levels get very hectic).

[saimon69]

I realized however that sadruzzo version does not have the score bar at the top; putting back that would reduce a bit the play area and gain some raster time imo; plus total screen area in the arcade is 224 px high and 264 px long; 40 px vertical are used by score, rank and map/ power ups so that total play area is 184 Px high.

[roondar]

Originally Posted by Trachu

Just for your information, I get the idea of EHB in Battle Squadron from your page when I checked the numer of colours of PNG you posted there. When they counted 59 i assumed it must be EHB. Now i checked and indeed it works on 5 bitplanes, so once again I made a mistake and I propobably will make a 1000 more in my life, so if your intention is to wait for my mistake to enter the conversation, you will get a lot of chances.

I am really dissapointed about you. For a guy I who made such a great page about amiga tricks I expected MORE. Instead you come here only to tell us you cant do that, you cant do this etc.
Would you be so kind to tell us what actually we can do?
When I make an argument I made a reasons behind it and when problemms comes about it I look for solutions.

So far I have shrinked 88 colours of level 1 into 40 without only minor changes in quality, going lower costs noticeable difference. Also do you realise if we want to use 4 sprites for background the actual numer of colours we can use in every level are 29 in 5bitplane scenario or 58 in EHB.

Stop being counterproductive and help us for a change?

Not to get too involved in this argument, but a 6BPL + sprite background (or 5 BPL with full copper use) leaves very little time for the blitter. Supposing you only use 6BPL for half the screen and 5BPL elsewhere you're still looking at using up ~48% of the total available DMA time just displaying the screen (excluding the cost of either manually setting up sprite data or using sprite DMA for it).

I understand this is a consequence of wanting to use a sprite background, but it's a lot to lose. A standard 5BPL screen without sprite background only uses ~36% of the DMA time available.

If we're to use all this time to blit (adding in the time for sprites/audio/memory refresh, redrawing using tripple buffer @50Hz updates) and leave zero time for the CPU to do anything at all, we have time to blit only 8 bobs @32x32 pixels* per frame.

Using 5 bitplanes for drawing but keeping the screen setup as is (6BPL with sprite background) ups this to just about ~11.

Which is one of the reason why many Amiga games didn't use 50Hz updates for bobs or used a dual playfield mode for parallax effects (only three planes to update then).

*) Including sprites, audio, memory refresh and the display we'd have about 39900 colour clocks in use and about 30600 left, assuming a PAL Amiga. A 32x32 bob with redraw costs 6 colour clocks * 3 words wide * 32 lines tall * 6 bitplanes = 3456 colour clocks.

[ReadOnlyCat]

Originally Posted by roondar

If we're to use all this time to blit (adding in the time for sprites/audio/memory refresh, redrawing using tripple buffer @50Hz updates) and leave zero time for the CPU to do anything at all, we have time to blit only 8 bobs @32x32 pixels* per frame.

Using 5 bitplanes for drawing but keeping the screen setup as is (6BPL with sprite background) ups this to just about ~11.
[...]
*) Including sprites, audio, memory refresh and the display we'd have about 39900 colour clocks in use and about 30600 left, assuming a PAL Amiga. A 32x32 bob with redraw costs 6 colour clocks * 3 words wide * 32 lines tall * 6 bitplanes = 3456 colour clocks.

I guess you are assuming all bobs are using cookie cuts?

Also, I am a bit puzzled by your figure of 6 color clocks per word, isn't it 4 clocks per word when using all four channels? I might be misunderstanding how the blitter consumes DMA cycles but it seems to me that it uses all available bandwidth when the four channels are used. I recall reading from Toni that there were a few idle cycles here and there but I am under the impression these were infrequent. I could be wrong though.

[Vot]

Wow .. It sounds like someone needs to write some kind of engine planner to calculate how much can be blit using the different methods, screen sizes and how much dma time it takes.

When people ask why people don't write more p.d stuff in the amiga. I would imagine this is why, it takes a lot more planning to make sure what your doing is possible.

[Shatterhand]

Ok guys, I am only recently learning about how the amiga works, so pardon me if I say anything stupid here.

I am checking arcade Rygar right now, and I don't think using sprites for background will work at all for every level.

Trachu made a wonderful work with the bobs using just 10 colors (though there are a lot of enemies missing there). Would it be possible to make Rygar out of sprites? The arcade version of Rygar is more than 16px wide, but I guess we could use all sprites channels for him and his weapon (more colors and more width). I'll explain why below.

If we *really* want to go with the parallax scroll, using a dual playfield seems to be the best option here. From what I am seeing on the arcade version, the backdrop on almost all levels could be reproduced very well with just 4 colors removing certain details and some good use of a copper list (honestly, it almost looks like the background really uses just a few colors and changes its palette on scanlines, since there are clear horizontal sections with different colors) - we would have just to change the palette on each level.
We wouldn't be able to have the waterfall on the background on that mountain level (but I guess we wouldn't have animated backgrounds at all anyway), but it would be nice enough, the backdrops can really work with just 4 colors.

The biggest problem here would be the big sun on the backdrop.. it *can* be done with just 4 colors (use 2 for the sun, 1 for the mountains just like the arcade, and 1 for transparent.. I made a test here and it does look good enough IMO), but I don't know how easy would be to do that sun static on background with a black mountain scrolling on the back playfield (or if its possible at all).

Also, there are levels that have vertical scroll. I think its only one, but its there. when the game does scroll vertically, the back playfield is not visible, so you don't have to worry about it here.

With enemies taking 10 colors, and Rygar using sprite colors, we are left with 6 colors for the foreground (if we always keep the same 10 colors from enemies, we can reuse them here and there for the background, though it's not a good idea to abuse this). Again, if we remove some details from the foreground, it can be done. I don't know if a copper list would be helpful here... maybe just for the lava bits on the bottom, we use 2 background colors there and change them to lava red just for that bottom section - we would need to make the lava 'flat', but it would still look good enough IMO without messing up with other bobs colors. Or we could just use red and black-ish from enemies (the lava wouldn't be animated anyway)

I say to use sprites for Rygar and his weapon because roondar said we would have about 8 32x32 bobs in a frame. We could save bobs by making the main hero sprites. Examining the arcade version, there aren't many moments where there are more than 8 enemies moving on screen.. though sometimes they are bigger than 32x32.. and while there aren't many, *there are* moments with more than 8 enemies on screen (Usually when there a lot of fireballs or lots of those lava monsters or both together).

Maybe we could keep checking how many enemies are on screen and, if it gets beyond a certain number, drop the update on their movement to 2 frames instead of one (move half of them on even frames, the other half in odd frames). If we still get slowdowns doing this, I guess it would still be ok.

Also, not updating the top of the screen and just showing score, time etc on it would really help getting some extra speed, and still be faithful to the arcade game. (I guess you would still need at least 4 colors there to show rank properly, but maybe it could be done with just 2 colors, just don't know if the gain on speed there would be really that helpful). Same thing with the bottom screen showing lives, map, round, etc.


And then we could concentrate on what's important: making the gameplay work.

Sorry for the long post and all... from what I understand from the Amiga hardware and all the discussion, I just wanted to give my 2 cents on this (After all, that was the original intent of the thread before it became a really serious conversion work). I am still learning about Amiga programming, and using Blitz Basic instead of ASM, so I don't think I could help on coding at all (Yeah, it's very easy to make a lot of suggestions from my comfortable standing point ), but I'd glad helping colouring down, choosing palettes for different levels and cutting down details on the background - I am not much of an artist myself, but I think that's something I could do it.

Oh, and while porting the gamplay, I think this would be a very useful site:

http://strategywiki.org/wiki/Rygar/Getting_Started

[Shatterhand]

By the way, that's how the arcade sun would look with just 3 colors:



Like I said, IMO it's good enough. Then you could still use black for the mountains, I just don't know how easy it would be to scroll 1 color mountains in front of a still background using just one playfield. I think it's possible, but I am not sure about it. If you can't, just remove the mountains (you could then use all 4 colors for the sun).. I think on this section it's more important to keep the sun than to have the mountains...

EDIT (so I don't triple post)

I would took at least one liberty with the arcade game, when getting past a level, I wouldn't scroll the screen into the "temple" with the statues. I would just make Rygar leave the screen, fade out, fade in with the temple screen showing your bonus and all (maybe don't even show Rygar here, and use 5 bitplanes - 32 colors for this screen) - if possible, show bonus while loading the graphics etc for the next level (or load it after bonus is shown). fade out screen, fade in the next level.

This way you wouldn't have to worry about the palette on the temple screen conflicting with the palette on the main level. Even though those temples don't use a lot of color, if you keep chaning palette from level to level, they would look different from each level and that would be really weird.

*OR* you could draw the temple screens using the same colors as the enemies blobs. They would look a bit more drab, but at least it wouldn't break the flow of the game. Hmm... maybe I should take a look on how one of those screens would like with those colors.

EDIT 2 (Again, not wanting to triple post)

Hmmm.. the temple/bonus room using the 10 colors from Trachus image, doing a dirty colouring down



With some retouches, it could work. No need to show this separately. Better not look that good but not interrupt flow of the game. If we could load the next level while displaying the bonus for that level, it would be *really* awesome, as the game would really feel seamless.

[sandruzzo]

From game to temple we could switch palette with copper..

[saimon69]

Did anyone thought at how to do the descending/ climbing levels yet?
I propose to use bobs to simulate cimb/ descend on the side but if you know a better method lmk