Conversion Capers: Rygar

[sandruzzo]

Originally Posted by Tsak

You mean in a different single sheet (all frames together) or each frame alone?

yes

[ovale]

A or b and you answer yes?

[saimon69]

@ovale
he means to use my method, so that he can use a script to extract the graphics; you could even remove the borders(i left it for visual reference) as soon as you keep the exact size of each area for any sprite

[jeff b00toNic]

Check the Zone. I hope that will work for you this time ;-)

[Tsak]

Originally Posted by jeff b00toNic

Check the Zone. I hope that will work for you this time ;-)

Nice try
But frames are still not correctly alligned.

Anyway, I've done the job too. I have also split each enemy and tileset and I corrected in addition the palette and allingment. Rygar frames can be found as individual pics as well as one long frames strip.

Here's the pack: RygarPack.lha

Originally Posted by saimon69

@Tsak
For enemies and the player assets let me suggest this approach that i had to use for the graphics of the game Powder.

Thanks, but I prefer straight forward placement on the grid without visible helping lines. This is also easier to grab without the need for any script or removing white lines. Coder can just convert those to RAW and use them immediately. Only thing he needs to know is the cell size which in our case is:

16x16: Items, Weapon, Tileset
32x16: Enemy1
64x64: Enemy7
32x32: Everything else

Next question: do you need extra 16pxs wide word for enemy bobs at the enemy pics?

[jeff b00toNic]

And I was so proud about it

Correct me if I'm wrong but I guess Tsaks work needs
to be converted from 8bpp to 4bpp since this is an OCS/ECS game.

I would do that if it needs to be done.

[Tsak]

Have you checked my last pack? All pics are already 5bpp (32 colors) which is all it needs for OCS.

[jeff b00toNic]

Well, I checked with IrfanView. And that's the result.
Don't want to argue about it I'm sure there must be something
wrong with IrfanView then.

Edit:
I had a look with DP4.5 on an emulated ECS config.
You're absolutely right indeed. It is a 5bpp 32 colors pic!
Just to clear the whole thing up. I've downloaded an ADF of Sandruzzos Google Drive,
the pics on that ADF were 4bpp 16 colors (at least in IrfanView) and the size of each
(rygar_sprite) was just a few bytes. So I figured it has to be like that.
I guess my picture viewer is not reliable at all.

[Tsak]

Originally Posted by jeff b00toNic

Well, I checked with IrfanView. And that's the result.
Don't want to argue about it I'm sure there must be something
wrong with IrfanView then.

Edit:
I had a look with DP4.5 on an emulated ECS config.
You're absolutely right indeed. It is a 5bpp 32 colors pic!
Just to clear the whole thing up. I've downloaded an ADF of Sandruzzos Google Drive,
the pics on that ADF were 4bpp 16 colors (at least in IrfanView) and the size of each
(rygar_sprite) was just a few bytes. So I figured it has to be like that.
I guess my picture viewer is not reliable at all.

Well, you're not entirely wrong at least
As I see, IfranView reports that the pic is 320x256 which seems to be the case. Apparently the cropping I did got lost in the gif-iff conversion. This makes my "cropped" single frames singnifficantly larger than yours (even though the actual frame is the same size) which also results to bigger RAW output. Thanks!

[jeff b00toNic]

Originally Posted by Tsak

Apparently the cropping I did got lost in the gif-iff conversion.

I had the same problem until I used Grafx2 for conversion.

[Trachu]

Originally Posted by Tsak

Which is?

Thanx Tsak for helping Sandruzzo, coz i am busy right now with real life and have limited time left. I did not find so far anything worth showing

Generally we need to have something like this

Playfield graphics needs to use colour register 0-25 and 28
Background needs to use colour registers 25-27 and 29-31
BOBs needs to use colour register 0-25 and 28
Rygar sprite needs to use colour register 16-25 and 28 (where 16 is transparent colour)

The understanding of basic Amiga architecture implications should be a start for anyone who wants to help here.

BOBs and Rygar shares many colours together, and they need to be mapped correctly into the proper register, that means every BOBs must use 5 bitplanes (sorry Sandruzzo),but Ryggar only 4.
BOBs can use more colours than Rygar but they need to share the palette with playground. I already shrinked without quantisation playground to 26 colours but the problemm remains that THEY ARE NOT THE SAME COLOURS LIKE BOBS or ryggar.
Someone might ask why not to share playground palette also with background sprites? Well if you could notice few pages before i have shown how the background can look very similar to original if some colours will be completelly replaced by copper at certain lines. The disadvantage of this technique is that you can not use them in playground unless you can accept unwanted colour change...
If we would accept poorer background and use copper for example to colour 0 only, we could have another 3 colours (not 6) which can be used by playground, but not by Rygar or BOBs, because playgroung and background colours change every level, while rygar and bobs stays the same all the time.

I already shrinked without quantisation playground to 26 colours but the problemm remains that THEY ARE NOT THE SAME COLOURS like BOBS or Ryggar.
What you did was reducing the numer of playground colours to 23 and BOBS to 10 with only one colour shared background. This gives total colour of 32, but the quantisation reduced the complexity of the ground in visible manner. I did not wanted to do that, hence i stuck, you assumed you had 32 colours and you did it easy way, but this has not moved us by inch.

UPDATE:
Ok, I had some luck today - colours shrinked to 26. (10 for Ryggar, 14 for BOBs), without destroying details PLUS 9COLOUR copperised background

There is also 29 colour version, for situation where we copperise only colour 0 and we share the palette with background sprites. I have included 2 versions of such background.

Which one is better?

[Tsak]

Does palette color sequence really needs this specific arrangement? I mean what's wrong with mapping transparency to color#0 and then have Rygar sprite and Bob colors follow?

Of course if copper backgrounds are planned it makes sense to further reduce the total color count (which I didn't obviously).

This gives total colour of 32, but the quantisation reduced the complexity of the ground in visible manner.

Well, that's not true. In fact only 2 playfield(tileset) colors were altered: the dark shade from the flower tiles (which was replaced with a lighter hue) and the red hue (used in lava/candle). So ground and the rest of the tileset is completely intact in my version, making the red hue (lava) the only visible difference.
But this was a very targeted decision. What you did in your latest version was to use the original lava color on bobs and sprites alike which has dire concequences on their quality. This new color disrupts the fine color balance and in result the sprite/bob frames look now oversaturated. So I STRONGLY suggest you use the light red color instead. Lava tiles can be easilly remodelled (with more colors - see rock monster) and mask any visible difference from the original (even make this look better than what it currently does).

Other than that I like how the green shades are reduced in the new tileset. Also many monsters look more accurate and seem to be using more colors compared to my version. If you exclude the red color I'd say you are on a fine path.

One final detail I'd like to mention regarding the whole project this time: If Sandruzzo and you or anyone else wanting to participate are serious about this (well, half serious is ok too -in fact) I'd recommend you to team up and take development discussion somewhere private. What seems to be missing here is proper (and frequent) members communication and a clear plan. It's difficult to do any serious work in this roller coaster where everyone can pop up and disrupt the development flow.

Just saying

[Trachu]

Tsak: Let my saying do not discourage you, because we have 26 levels to convert and any contribution is welcome ;-)
This colour distribution was explained by me before and its a direct consequence of how Amiga was designed and that we want to allocate 4 fourcolour sprites for background.
2 pairs of sprites uses different set of colour registers, but their colours needs to be the same, which means we can choose either 26 or 29 colours for our disposal.
The first level background is so rich in colour its really hard to paint it correctly without copper.
The human vision is concentrated more on Luma than on Chroma, which means the proper colour reduction requies replace one colour with the other while keeping similar luma distances. In your first approach you have destroyed many fine details and sounded very cocky, how easy it is to even reduce them to 16 colours. In your second approach you have done better.
As for the red colour we both share it with Lava, I choose the shade from Lava, because it is more vivid, you from the monsters. Easy to change.

[jeff b00toNic]

Originally Posted by Tsak

One final detail I'd like to mention regarding the whole project this time: If Sandruzzo and you or anyone else wanting to participate are serious about this (well, half serious is ok too -in fact) I'd recommend you to team up and take development discussion somewhere private. What seems to be missing here is proper (and frequent) members communication and a clear plan. It's difficult to do any serious work in this roller coaster where everyone can pop up and disrupt the development flow.

Just saying

I agree 100%. This is going nowhere especially when gfx creation is that complicated.

[roondar]

Originally Posted by Tsak

Does palette color sequence really needs this specific arrangement? I mean what's wrong with mapping transparency to color#0 and then have Rygar sprite and Bob colors follow?

Well, Amiga sprites use colours 16-31 (well actually 17-31 as colour 16 is treated as transparant and can be freely used by other graphics) when in 15 colour mode.

In 3 colour mode they use 3 colours per pair of sprites, starting with colours 17-19 for sprites 0&1 and ending with colours 29-31 for sprites 6&7. The transparant colours used by sprites in three colour mode (16, 20, 24 and 28) can be freely used by other graphics.

Note however that colour 0 can be used as transparant in sprites just fine - a sprite treats no pixel set as transparant.

[Tsak]

@roodnar
Thanx, interesting info. Truth is I've never worked with amiga sprites before, only bobs...

In your first approach you have destroyed many fine details and sounded very cocky, how easy it is to even reduce them to 16 colours.

He, he, fair enough
But this first approach was meant more like a statement than a real contribution.
My point was that it's much preferred to compromise some detail in favor of more colors used (and of a different hue) per frame compared to your -near- discolored take (even if this was meant as an example as well - which is understandable).

Let my saying do not discourage you, because we have 26 levels to convert and any contribution is welcome ;-)

Thanks.
I wouldn't want to discourage you also but unless you're in direct contact with Sandruzzo and you're sure that this is the case, I'd recommend to hold on to your horses. It takes real commitment, much work and a team working closely to even get the basics done and rolling (let alone complete the game).
And as for contributions from others, I'm sure that more people will be willing to jump on the boat and help once there is a team in place, a clear goal and a bit of progress.

The work that is done so far (both Sandruzzo and yours) is fine and respected plus the thread has proven quite educational so far. But to get the game development to the next level, taking any of the above steps is absolutely necessary imho.

[Trachu]

Tsak: The progres goes slow because we are doing it for fun not for the money and each of us has real life, but you should also know we have spent tens of posts disscussing parallax effect.
The general problemm with amiga 500 is a large portion of the knowledge was lost throught of time and we have to recreate it as best as we could.
After the disscussion we have decided to leave with 4 sprites as background, which of course has its impact on how the colours needs to be used.
You are absolutelly right we need to have better channels to communicate with each other and i have proposed IRC but got no response from Sandruzzo or others.

Ok, after this prologue, here is where we stand at the moment.
I have presented two sets of fioreground and background which can be used after PROPER conversion to IFF.
1. 26 colour version has some fine detail lost (oh god give me one colour more ;-), but allows to use multicoloured copperised background very similar to original. At some lines we replace all 4 colours.

2. 29 colour version looks very similar to original but sprite background colours are incorporated into the background, and we can use copper for replacing only one colour 00. I did something myself and there were also nice work of mr.nobody before.

I am not saying that my conversion is the best that can be, but it fits the requied parimeter and it works. If someone can make something better or improve the colours you are all welcome.
Now Sandruzzo needs to decide which version to use and how he wants it to be prepared.
If Sandruzzo says 29 colours we need contribution in creating better background using the same 3 colours out of those 29 and copperised colour 00.
Or maybe we just use mr nobody work???

[sandruzzo]

Originally Posted by Trachu

Tsak: The progres goes slow because we are doing it for fun not for the money and each of us has real life, but you should also know we have spent tens of posts disscussing parallax effect.
The general problemm with amiga 500 is a large portion of the knowledge was lost throught of time and we have to recreate it as best as we could.
After the disscussion we have decided to leave with 4 sprites as background, which of course has its impact on how the colours needs to be used.
You are absolutelly right we need to have better channels to communicate with each other and i have proposed IRC but got no response from Sandruzzo or others.

Ok, after this prologue, here is where we stand at the moment.
I have presented two sets of fioreground and background which can be used after PROPER conversion to IFF.
1. 26 colour version has some fine detail lost (oh god give me one colour more ;-), but allows to use multicoloured copperised background very similar to original. At some lines we replace all 4 colours.

2. 29 colour version looks very similar to original but sprite background colours are incorporated into the background, and we can use copper for replacing only one colour 00. I did something myself and there were also nice work of mr.nobody before.

I am not saying that my conversion is the best that can be, but it fits the requied parimeter and it works. If someone can make something better or improve the colours you are all welcome.
Now Sandruzzo needs to decide which version to use and how he wants it to be prepared.
If Sandruzzo says 29 colours we need contribution in creating better background using the same 3 colours out of those 29 and copperised colour 00.
Or maybe we just use mr nobody work???

I like 26 and 29 colors too. I just would like to have enemies mappend into first 4 planes if we can, otherwise fine too.

[Trachu]

Originally Posted by sandruzzo

I like 26 and 29 colors too. I just would like to have enemies mappend into first 4 planes if we can, otherwise fine too.

Question out of curiosity of Amiga architecture -why do you insist for that? What will you gain by that?

I will try to explain the main problemm here.
BOBs and Ryggar are universal objects throught the whole game, which mean the colours those objects finally will use CAN NOT CHANGE from level to level.
Ryggar will be the sprite which means it MUST use colours 17-24 and 28 and it shares 10 colours with BOBs!!!!
This sharing requies from me to map the bobs on all 5 bitplanes and maximum what I can do is to make Ryggar and BOBS use exactly the same colours 16-31. This will limit quality of the BOBs of course but its possible.

If for some reason someone would like to have BOBs to use colours 0-15 then it can be done only by making Ryggar also BOB (not a sprite).

This is how Amiga works sorry.

[sandruzzo]

Originally Posted by Trachu

Question out of curiosity of Amiga architecture -why do you insist for that? What will you gain by that?

I will try to explain the main problemm here.
BOBs and Ryggar are universal objects throught the whole game, which mean the colours those objects finally will use CAN NOT CHANGE from level to level.
Ryggar will be the sprite which means it MUST use colours 17-24 and 28 and it shares 10 colours with BOBs!!!!
This sharing requies from me to map the bobs on all 5 bitplanes and maximum what I can do is to make Ryggar and BOBS use exactly the same colours 16-31. This will limit quality of the BOBs of course but its possible.

If for some reason someone would like to have BOBs to use colours 0-15 then it can be done only by making Ryggar also BOB (not a sprite).

This is how Amiga works sorry.

If rygar will be bob, how can you handle the other colors and sprites? Can be better choice forr both game quality and speed?