Conversion Capers: Rygar

[sandruzzo]

Originally Posted by Amiten

@Sandruzzo & @all people help in here.

CONGRATULATIONS! I try the Rygar.adf in your dropBox and Looks Rock!

continue with the good Work!

all the best
Johnny

Thanks mate. I hope we can do better!

[Trachu]

Originally Posted by nobody

As i see you stalled the project even though i gave all sprites, here are the original colors sprites that i ripped from mame before to work again. Feel free to change them to something better than dawnbringers palette

In the zone
http://download.abime.net/zone/rygar...%20sprites.zip

P.S: its only 573 colors there :P

Thanx man

I have joined my first attempt 572colours reduced to 15+transparent black using 4 bitplanes.
This is exactly what Sandruzzo want.

We have 32 colours shared between hardware sprites and foreground. Ryggar character is using 10colours, while additional sprites are using 5 more.

What we can do:
1. Ryggar is hardware sprite using 0,1,2,3 and we use 6 and 7 for background, BEcause all bobs must fit into 4 bitplanes, we have to allocate at least 3 colours for that, which leave only 12 colours to be used by BOBs.
Foreground is using 29colours.
Result: poor quality of BOBs, but the best looking Foreground. Background is only 32 pixel wide.

2. Ryggar is hardware sprite using 0,1,2,3 and we use 4,5,6 and 7 for background, BEcause all bobs must fit into 4 bitplanes, we have to allocate at least 6 colours for that, which leave only 9 colours to be used by BOBs.
Foreground is using 26colours
Result: VERY poor quality of BOBs, background is 64pixel wide

3. Ryggar is BOB, hardware sprites 0,1,2,3,4,5,6 and 7 are for background, 15 colours to be used by BOBs, while background uses 16,17,18 and duplicated 19,23,27 (thanx to setting attach bit-16colour, but do not allign the pair of sprites together).
Foreground is using 26colours
Result: GOOD quality of BOBs, backround can be 128pixel wide, but ryggar character would cost more resources

In everytime i assumed we would use 3+1 copperised colours for background.

Considering the Amiga 500 architecture limitations, I say we must use Ryggar as BOB also.

Scrolling backround sprite playfield is quite easy. We must use technique similar to the one used in Risky Woods.
http://www.codetapper.com/amiga/spri...s/risky-woods/

"By storing 8 copies of the sprite graphics, the game only has to update 8 words in memory to shift the graphics by a pixel, and when the game scrolls the background by 2 pixels it only has to alter the sprite pointer addresses in the copperlist, 8 sprites x 2 words = 32 bytes of data!"

I belive this is the ultimate and most optimal way to create multidiemensional paralax effect on OCS, while keeping 26 colours in the battlefield.
Standard dualplayfield method is giving the graphician too less colours to be used efficiently.

[sandruzzo]

Originally Posted by Trachu

Thanx man

I have joined my first attempt 572colours reduced to 15+transparent black using 4 bitplanes.
This is exactly what Sandruzzo want.

We have 32 colours shared between hardware sprites and foreground. Ryggar character is using 10colours, while additional sprites are using 5 more.

What we can do:
1. Ryggar is hardware sprite using 0,1,2,3 and we use 6 and 7 for background, BEcause all bobs must fit into 4 bitplanes, we have to allocate at least 3 colours for that, which leave only 12 colours to be used by BOBs.
Foreground is using 29colours.
Result: poor quality of BOBs, but the best looking Foreground. Background is only 32 pixel wide.

2. Ryggar is hardware sprite using 0,1,2,3 and we use 4,5,6 and 7 for background, BEcause all bobs must fit into 4 bitplanes, we have to allocate at least 6 colours for that, which leave only 9 colours to be used by BOBs.
Foreground is using 26colours
Result: VERY poor quality of BOBs, background is 64pixel wide

3. Ryggar is BOB, hardware sprites 0,1,2,3,4,5,6 and 7 are for background, 15 colours to be used by BOBs, while background uses 16,17,18 and duplicated 19,23,27 (thanx to setting attach bit-16colour, but do not allign the pair of sprites together).
Foreground is using 26colours
Result: GOOD quality of BOBs, backround can be 128pixel wide, but ryggar character would cost more resources

In everytime i assumed we would use 3+1 copperised colours for background.

Considering the Amiga 500 architecture limitations, I say we must use Ryggar as BOB also.

Scrolling backround sprite playfield is quite easy. We must use technique similar to the one used in Risky Woods.
http://www.codetapper.com/amiga/spri...s/risky-woods/

"By storing 8 copies of the sprite graphics, the game only has to update 8 words in memory to shift the graphics by a pixel, and when the game scrolls the background by 2 pixels it only has to alter the sprite pointer addresses in the copperlist, 8 sprites x 2 words = 32 bytes of data!"

I belive this is the ultimate and most optimal way to create multidiemensional paralax effect on OCS, while keeping 26 colours in the battlefield.
Standard dualplayfield method is giving the graphician too less colours to be used efficiently.

Good!

[Trachu]

Originally Posted by sandruzzo

Good!

Have you read this article? Do you understand how it works?

I Wonder, do we really have to store 8 different bitmaps in memory?

Can we just put one single bitmap 144 pixel wide in memory, where the last 16 pixels will be the repeated first and point sprite dma feed register to read the memory 2 pixels further to the right or the left.
I am not sure how those registers work.

I have included proposed background for the level 1.
It has total 9 colours changed by copper (4 colours every line)

[sandruzzo]

Originally Posted by Trachu

Have you read this article? Do you understand how it works?

I Wonder, do we really have to store 8 different bitmaps in memory?

Can we just put one single bitmap 144 pixel wide in memory, where the last 16 pixels will be the repeated first and point sprite dma feed register to read the memory 2 pixels further to the right or the left.
I am not sure how those registers work.

I have included proposed background for the level 1.
It has total 9 colours changed by copper (4 colours every line)

ready it. In order to have a fast moving background, we have to "move" bitmap inside sprites.

[Trachu]

Originally Posted by sandruzzo

ready it. In order to have a fast moving background, we have to "move" bitmap inside sprites.

Well you do not understand me. I am thinking about pointing to the different memory address each time we want to move the background, we do not "move" anything in memory. We just want to tell the chipset it needs to read different data.
Anyway, in case regsiers can point only to full word addresses, i have prepared for you all variants.

To explain how it works in Riskywoods we move the background to the right pixel by pixel.
First we load all 8 variants of background into the memory. This is what we have to change each Vertical blank (new frame)

1. Offset +1 (the background moves 1 pixel to the right)
We change bit 0 in SPRxCTL for all sprites (8 MOVE operations)

2. Offset +2
We change SPRxPTL and SPRxPTH to the new shifted by 2 bitmap address. (16 MOVE operations)

3. Offset +3
We change bit 0 in SPRxCTL for all sprites

4. Offset +4
We change SPRxPTL and SPRxPTH to the new shifted by 4 bitmap address.

5. Offset +5
We change bit 0 in SPRxCTL for all sprites

6. Offset +6
We change SPRxPTL and SPRxPTH to the new shifted by 6 bitmap address.

7. Offset +7
We change bit 0 in SPRxCTL for all sprites

8. Offset +8
We change SPRxPTL and SPRxPTH to the new shifted by 8 bitmap address.

9. Offset +9
We change bit 0 in SPRxCTL for all sprites

10. Offset +10
We change SPRxPTL and SPRxPTH to the new shifted by 10 bitmap address.

11. Offset +11
We change bit 0 in SPRxCTL for all sprites

12. Offset +12
We change SPRxPTL and SPRxPTH to the new shifted by 12 bitmap address.

13. Offset +13
We change bit 0 in SPRxCTL for all sprites

14. Offset +14
We change SPRxPTL and SPRxPTH to the new shifted by 14 bitmap address.

15. Offset +15
We change bit 0 in SPRxCTL for all sprites

16. Offset +16
We change SPRxPTL and SPRxPTH to the standard (offset0) bitmap address, but this time we point
sprite 0 to sprite 1 data (+16pixels=1word)
sprite 1 to sprite 2 data (+32pixels=2words)
sprite 2 to sprite 3 data (+48pixels=3words)
sprite 3 to sprite 4 data (+64pixels=4words)
sprite 4 to sprite 5 data (+80pixels=5words)
sprite 5 to sprite 6 data (+96pixels=6words)
sprite 6 to sprite 7 data (+112pixels=7words)
sprite 7 to sprite 0 data (+0pixels=0words)

17. Offset +17
We change bit 0 in SPRxCTL for all sprites

18. Offset +18
We change SPRxPTL and SPRxPTH to the offset2 bitmap address, but this time we point
sprite 0 to sprite 1 data (+16pixels=1word)
sprite 1 to sprite 2 data (+32pixels=2words)
sprite 2 to sprite 3 data (+48pixels=3words)
sprite 3 to sprite 4 data (+64pixels=4words)
sprite 4 to sprite 5 data (+80pixels=5words)
sprite 5 to sprite 6 data (+96pixels=6words)
sprite 6 to sprite 7 data (+112pixels=7words)
sprite 7 to sprite 0 data (+0pixels=0words)



and go on and go on

Risky woods used 64pixel wide 15 colour sprites, but it requies to use only 4 bitplanes for main screen. If we use 128px 4colour sprites, we can have even 52colours (EHB) for main area!!!

[saimon69]

Every time i see new posts in this thread my heart has a bounce ^^

[Trachu]

Ok, here goes version 2 of the sprites.

This time i have also alligned them and compressed them into 320x192x4 bitmap.

They are all placed together in blitter friendly 16x16 blocks.

I still have to work on their quality but there is a progres
UPDATE:

I have just replaced graphics with ver 3 which i think is close to what can be done here
Now we need to unify the palette with the rest of tiles

[idrougge]

Nice one, Trachu!

[sandruzzo]

@Trachu!

What a job!

[sandruzzo]

Originally Posted by Trachu

Ok, here goes version 2 of the sprites.

This time i have also alligned them and compressed them into 320x192x4 bitmap.

They are all placed together in blitter friendly 16x16 blocks.

I still have to work on their quality but there is a progres
UPDATE:

I have just replaced graphics with ver 3 which i think is close to what can be done here
Now we need to unify the palette with the rest of tiles

Breat Job! We need new gfx tiles too, because palette is new!

[DamienD]

Nice work indeed Trachu, looks very cool

[dlfrsilver]

Those graphics are superb !

[roondar]

Originally Posted by Trachu

Well you do not understand me. I am thinking about pointing to the different memory address each time we want to move the background, we do not "move" anything in memory. We just want to tell the chipset it needs to read different data.
Anyway, in case regsiers can point only to full word addresses, i have prepared for you all variants.

To explain how it works in Riskywoods we move the background to the right pixel by pixel.
First we load all 8 variants of background into the memory. This is what we have to change each Vertical blank (new frame)

1. Offset +1 (the background moves 1 pixel to the right)
We change bit 0 in SPRxCTL for all sprites (8 MOVE operations)

2. Offset +2
We change SPRxPTL and SPRxPTH to the new shifted by 2 bitmap address. (16 MOVE operations)

3. Offset +3
We change bit 0 in SPRxCTL for all sprites

4. Offset +4
We change SPRxPTL and SPRxPTH to the new shifted by 4 bitmap address.

5. Offset +5
We change bit 0 in SPRxCTL for all sprites

6. Offset +6
We change SPRxPTL and SPRxPTH to the new shifted by 6 bitmap address.

7. Offset +7
We change bit 0 in SPRxCTL for all sprites

8. Offset +8
We change SPRxPTL and SPRxPTH to the new shifted by 8 bitmap address.

9. Offset +9
We change bit 0 in SPRxCTL for all sprites

10. Offset +10
We change SPRxPTL and SPRxPTH to the new shifted by 10 bitmap address.

11. Offset +11
We change bit 0 in SPRxCTL for all sprites

12. Offset +12
We change SPRxPTL and SPRxPTH to the new shifted by 12 bitmap address.

13. Offset +13
We change bit 0 in SPRxCTL for all sprites

14. Offset +14
We change SPRxPTL and SPRxPTH to the new shifted by 14 bitmap address.

15. Offset +15
We change bit 0 in SPRxCTL for all sprites

16. Offset +16
We change SPRxPTL and SPRxPTH to the standard (offset0) bitmap address, but this time we point
sprite 0 to sprite 7 data (+112pixels=7words)
sprite 1 to sprite 2 data (+16pixels=1word)
sprite 2 to sprite 3 data (+32pixels=2words)
sprite 3 to sprite 4 data (+48pixels=3words)
sprite 4 to sprite 5 data (+64pixels=4words)
sprite 5 to sprite 6 data (+80pixels=5words)
sprite 6 to sprite 7 data (+96pixels=6words)

17. Offset +17
We change bit 0 in SPRxCTL for all sprites

18. Offset +18
We change SPRxPTL and SPRxPTH to the offset2 bitmap address, but this time we point
sprite 0 to sprite 7 data (+112pixels=7words)
sprite 1 to sprite 2 data (+16pixels=1word)
sprite 2 to sprite 3 data (+32pixels=2words)
sprite 3 to sprite 4 data (+48pixels=3words)
sprite 4 to sprite 5 data (+64pixels=4words)
sprite 5 to sprite 6 data (+80pixels=5words)
sprite 6 to sprite 7 data (+96pixels=6words)


and go on and go on

Risky woods used 64pixel wide 15 colour sprites, but it requies to use only 4 bitplanes for main screen. If we use 128px 4colour sprites, we can have even 52colours (EHB) for main area!!!

Assuming I understood your posts on this correctly, it sadly can't be done like you suggested

Sprite pointers can only be changed by a minimum of one word at a time, meaning if you update them you can only 'move' in multiples of 16 pixels, not 2.

What could work is actually moving the sprites about by having a dynamic copperlist, in which you'd basically move the sprites about on the screen (alternatively you could have pre-created copperlists instead of dynamic ones).

However, creating big copperlists realtime takes up quite a bit of rastertime (alternatively - storing pre-created copperlists would take up a lot of memory), so this may not by worth it.

My guess (did not do the math) is that storing a bunch of copies in memory might be the most efficient way to do it. In fact, for a full screen underlay I'm pretty certain it is the fastest/most memory friendly way to do it efficiently.

[sandruzzo]

risky-woods

Use an animation and change sprite pointer when it's time to move.

[Trachu]

Originally Posted by roondar

Assuming I understood your posts on this correctly, it sadly can't be done like you suggested

Sprite pointers can only be changed by a minimum of one word at a time, meaning if you update them you can only 'move' in multiples of 16 pixels, not 2.

What could work is actually moving the sprites about by having a dynamic copperlist, in which you'd basically move the sprites about on the screen (alternatively you could have pre-created copperlists instead of dynamic ones).

However, creating big copperlists realtime takes up quite a bit of rastertime (alternatively - storing pre-created copperlists would take up a lot of memory), so this may not by worth it.

My guess (did not do the math) is that storing a bunch of copies in memory might be the most efficient way to do it. In fact, for a full screen underlay I'm pretty certain it is the fastest/most memory friendly way to do it efficiently.

You did not understand me for sure, because it was actually done in Risky woods. Codetapper explained it more throughtfully.

[sandruzzo]

Originally Posted by Trachu

You did not understand me for sure, because it was actually done in Risky woods. Codetapper explained it more throughtfully.

we will do our best. Just let me try

[sandruzzo]

Originally Posted by Trachu

You did not understand me for sure, because it was actually done in Risky woods. Codetapper explained it more throughtfully.

I'm doing some test, I think it's better to have more frames'. In order to speed up things, we should try the whole cycled animation.

Here My first test:

https://drive.google.com/file/d/0B03...ew?usp=sharing


You dont' see rygar because I use all sprite for parallax. Joy controll still in place so you can move forward and backward and see "parallax" animate.

[Trachu]

Originally Posted by sandruzzo

I'm doing some test, I think it's better to have more frames'. In order to speed up things, we should try the whole cycled animation.

Here My first test:

https://drive.google.com/file/d/0B03...ew?usp=sharing


You dont' see rygar because I use all sprite for parallax. Joy controll still in place so you can move forward and backward and see "parallax" animate.

THERE IS A WHOLE CYCLED ANIMATION IN PLACE.
more frames means duplicated data.

I made some small error in above post regarding where to point where for each sprite, but i guess you have figured this out yourself.

For unknown reason whenever i try to see ryggar myself and i put your adf in winuae i see bootblock error

[sandruzzo]

Originally Posted by Trachu

THERE IS A WHOLE CYCLED ANIMATION IN PLACE.
more frames means duplicated data.

I made some small error in above post regarding where to point where for each sprite, but i guess you have figured this out yourself.

For unknown reason whenever i try to see ryggar myself and i put your adf in winuae i see bootblock error

file is Rygar.adf, here work fine, just tested