Conversion Capers: Rygar

[Trachu]

Sandruzzo: I noticed 8 versions of background in graphics folder hence i wrongly assumed you used them all. Sorry.

As for the bitplane interleaving, could you explain bit further how this works? Is it related somehow with amiga hardware specific characterstics of how the bitplanes are accessed???

Generally i suspect what you expect from me so i have assigned certain registers for doing the job.

5 bitplane foreground, 4 bitplane BOBs, Ryggar as BOB, 128px wide background made using hardware sprites 0-7

Bitplanes - colour register
00000 - 00 copperised sprite colour 0
00001 - 01 Foreground, 4colour BOBs
00010 - 02 Foreground
00011 - 03 Foreground, 4colour BOBs
00100 - 04 Foreground
00101 - 05 Foreground
00110 - 06 Foreground
00111 - 07 Foreground
01000 - 08 Foreground, 6colour BOBs
01001 - 09 Foreground, 6colour BOBs, 4colour BOBs
01010 - 10 Foreground, 8colour BOBs
01011 - 11 Foreground, 8colour BOBs, 4colour BOBs
01100 - 12 Foreground, 6colour BOBs
01101 - 13 Foreground, 6colour BOBs
01110 - 14 Foreground, 8colour BOBs
01111 - 15 Foreground, 8colour BOBs
10000 - 16 Foreground
10001 - 17 background sprite colour 1
10010 - 18 background sprite colour 2
10011 - 19 background sprite colour 3
10100 - 20 background sprite colour 1
10101 - 21 Foreground
10110 - 22 Foreground
10111 - 23 Foreground
11000 - 24 background sprite colour 2
11001 - 25 Foreground, 6colour BOBs
11010 - 26 Foreground, 8colour BOBs
11011 - 27 Foreground, 8colour BOBs
11100 - 28 background sprite colour 3
11101 - 29 Foreground, 6colour BOBs
11110 - 30 Foreground, 8colour BOBs
11111 - 31 Foreground, 8colour BOBs

Could you check did i assigned them right?
As you could see sprite background is intereferring with interleaving, but still something can be done.
Also i was thinking. In case of BOBs it is the mask which actually decides which pixel will be put over which, so does it mean we can use all 8 colous+transparent (9 total) for BOBs???

[sandruzzo]

Originally Posted by Trachu

Sandruzzo: I noticed 8 versions of background in graphics folder hence i wrongly assumed you used them all. Sorry.

As for the bitplane interleaving, could you explain bit further how this works? Is it related somehow with amiga hardware specific characterstics of how the bitplanes are accessed???

Generally i suspect what you expect from me so i have assigned certain registers for doing the job.

5 bitplane foreground, 4 bitplane BOBs, Ryggar as BOB, 128px wide background made using hardware sprites 0-7

Bitplanes - colour register
00000 - 00 copperised sprite colour 0
00001 - 01 Foreground, 4colour BOBs
00010 - 02 Foreground
00011 - 03 Foreground, 4colour BOBs
00100 - 04 Foreground
00101 - 05 Foreground
00110 - 06 Foreground
00111 - 07 Foreground
01000 - 08 Foreground, 6colour BOBs
01001 - 09 Foreground, 6colour BOBs, 4colour BOBs
01010 - 10 Foreground, 8colour BOBs
01011 - 11 Foreground, 8colour BOBs, 4colour BOBs
01100 - 12 Foreground, 6colour BOBs
01101 - 13 Foreground, 6colour BOBs
01110 - 14 Foreground, 8colour BOBs
01111 - 15 Foreground, 8colour BOBs
10000 - 16 Foreground
10001 - 17 background sprite colour 1
10010 - 18 background sprite colour 2
10011 - 19 background sprite colour 3
10100 - 20 background sprite colour 1
10101 - 21 Foreground
10110 - 22 Foreground
10111 - 23 Foreground
11000 - 24 background sprite colour 2
11001 - 25 Foreground, 6colour BOBs
11010 - 26 Foreground, 8colour BOBs
11011 - 27 Foreground, 8colour BOBs
11100 - 28 background sprite colour 3
11101 - 29 Foreground, 6colour BOBs
11110 - 30 Foreground, 8colour BOBs
11111 - 31 Foreground, 8colour BOBs

Could you check did i assigned them right?
As you could see sprite background is intereferring with interleaving, but still something can be done.
Also i was thinking. In case of BOBs it is the mask which actually decides which pixel will be put over which, so does it mean we can use all 8 colous+transparent (9 total) for BOBs???

with interleaving, Hardware will access to bitplane a little bit different. Instead of having 1 bitmap for each bitplane pointer, we habe one or two in our case huge bitmaps that are interleaving like this:

bitmap interleaved:
word1 bitplane1, word2 bitplane 2, word3 bitplane 3, word4 bitplane4, word5 bitplane5

this kind of sequence will be repetead for each word until the end.

With 2 huge bitmap, we'll have this:

Bitmap 1 for odd planes: word 1 bitplane 1, word 2 bitplane 3, word 3 bitplane 5, end on to the end.

Bitmap2 for even planes: word1 bitplane 2, word 2 bitplane 4, word 3 bitplane 6(if we use it)

with this layout we have different options, and less cpu works.

having even planes (1-3-5) used for rygar and bobs
having odd planes (2-4-6[if we use it]) for bobs'

we have to sacrifice color for bobs, but squeezing them into 8 colors +8 rygar colors, it's a lot of work, and I don't think we can have a good gfx quality.

If we can do that we'll have only 2 blit for rygar and bob. One blit we'll be classic coockie-cut, and the onther only to make and hole into screen.

We should do some calculation to see if this king of layout, with 6 planes will be really fast.

[Trachu]

Originally Posted by sandruzzo

with interleaving, Hardware will access to bitplane a little bit different. Instead of having 1 bitmap for each bitplane pointer, we habe one or two in our case huge bitmaps that are interleaving like this:

bitmap interleaved:
word1 bitplane1, word2 bitplane 2, word3 bitplane 3, word4 bitplane4, word5 bitplane5

this kind of sequence will be repetead for each word until the end.

With 2 huge bitmap, we'll have this:

Bitmap 1 for odd planes: word 1 bitplane 1, word 2 bitplane 3, word 3 bitplane 5, end on to the end.

Bitmap2 for even planes: word1 bitplane 2, word 2 bitplane 4, word 3 bitplane 6(if we use it)

with this layout we have different options, and less cpu works.

having even planes (1-3-5) used for rygar and bobs
having odd planes (2-4-6[if we use it]) for bobs'

we have to sacrifice color for bobs, but squeezing them into 8 colors +8 rygar colors, it's a lot of work, and I don't think we can have a good gfx quality.

If we can do that we'll have only 2 blit for rygar and bob. One blit we'll be classic coockie-cut, and the onther only to make and hole into screen.

We should do some calculation to see if this king of layout, with 6 planes will be really fast.

I need to know exactly which registers to use, that is why i have shown you my calculations. Can i use full 8 colours + transparent?
With 5 bitplanes we would have 8+4

[sandruzzo]

Originally Posted by Trachu

I need to know exactly which registers to use, that is why i have shown you my calculations. Can i use full 8 colours + transparent?
With 5 bitplanes we would have 8+4

I can even do one huge interleaved bitmap and have the whole 32 color available. My Idea was to try to use 6 planes, but maybe is too much

[sandruzzo]

@Trachu

Can you send me some pics about parallax sprite with the right color to change with copper? So i'll convert all that palettes and put them into rygar. We have some rygars' frames not well aligned. You can see it when it run, and when you fire its weapons when it's down right

Rygar Exe updated. Now weapons' out its' better. It work only when rygar is stan still and down, working when it fly.

[sandruzzo]

Should I implement 2 fire button as Rygar Arcade?

[DamienD]

Originally Posted by sandruzzo

Should I implement 2 fire button as Rygar Arcade?

If you can or to cover all bases set jump to either up or the second fire button

[sandruzzo]

Originally Posted by DamienD

If you can or to cover all bases set jump to either up or the second fire button

I'll try to go for 2 buttons

[sandruzzo]

Working on a new joy routine, it'll take some time, after that i'll add bobs' on screen

[Trachu]

Sandruzzo:

I need to fix background a little to make it look better and then i will give you all copper details.

You need to fix gameplay resolution.

I have a question, If we use all 8 sprites for background, I was thinking we would need 16 repositioning copper commands, yet you seem to be using only 8, saving a lot of cycles, hows that possible?
What would it change if we would use only 4 sprites for that?

[Codetapper]

Originally Posted by Trachu

I have a question, If we use all 8 sprites for background, I was thinking we would need 16 repositioning copper commands, yet you seem to be using only 8, saving a lot of cycles, hows that possible?
What would it change if we would use only 4 sprites for that?

Have a look at the Risky Woods sprite tricks page on my site for how this works. Using 4 sprites wouldn't make any difference, you would still need 8 sets to offset the sprites correctly.

[Trachu]

Originally Posted by Codetapper

Have a look at the Risky Woods sprite tricks page on my site for how this works. Using 4 sprites wouldn't make any difference, you would still need 8 sets to offset the sprites correctly.

yes i know, but this is not what i was asking for. I was asking for memory cycles, not memory usage. As far as i can see Sandruzzo uses copper far more efficient than programmer in Risky woods, however what i have in mind is purelly Amiga platform game, worthy 31 years of programming experience. Something at better level than Jim Power.
That is why i am asking for different techniques to find which one is the best.

[sandruzzo]

Originally Posted by Trachu

Sandruzzo:

I need to fix background a little to make it look better and then i will give you all copper details.

You need to fix gameplay resolution.

I have a question, If we use all 8 sprites for background, I was thinking we would need 16 repositioning copper commands, yet you seem to be using only 8, saving a lot of cycles, hows that possible?
What would it change if we would use only 4 sprites for that?

I think because I place 8 sprites in the right place: first 128 pixel screen are actual sprites, the others positions replacement.

I was think an even bad idea: to have 8 sprites attached, and change sprites gfx instead sprites position. Maybe, with some precalculated copperlist, we can speed up all..

[Trachu]

Originally Posted by sandruzzo

I think because I place 8 sprites in the right place: first 128 pixel screen are actual sprites, the others positions replacement.

ok, but if you change teh sprite position to the right, in the next line you need to revert their position back to the left side of the screen, dont you????

[sandruzzo]

Originally Posted by Trachu

ok, but if you change teh sprite position to the right, in the next line you need to revert their position back to the left side of the screen, dont you????

Maybe is some kind of' unknown features. All that I know is working

After 31 years we're still learning about Amiga HW! Maybe we can even allow ourselves 6 planes...

[Codetapper]

Originally Posted by sandruzzo

I was think an even bad idea: to have 8 sprites attached, and change sprites gfx instead sprites position. Maybe, with some precalculated copperlist, we can speed up all..

It's certainly a bad idea if you're expecting it to be faster with this method. Currently you only have to change the addresses of 8 sprites to scroll the display (at the cost of 8 sets of sprites) for every 2 pixels of scrolling. Your new idea means you'll save having to do those few moves, but have to blit an enormous amount of data into the sprite definitions each time they move.

It cannot possibly be quicker than the current method. The only reason you'd do such a thing is if you're out of memory and can't spare chip memory for the 8 sets of sprites.

Just get the actual gameplay working and not worry about changing the parallax sprites every 5 minutes!

[sandruzzo]

Originally Posted by Codetapper

It's certainly a bad idea if you're expecting it to be faster with this method. Currently you only have to change the addresses of 8 sprites to scroll the display (at the cost of 8 sets of sprites) for every 2 pixels of scrolling. Your new idea means you'll save having to do those few moves, but have to blit an enormous amount of data into the sprite definitions each time they move.

It cannot possibly be quicker than the current method. The only reason you'd do such a thing is if you're out of memory and can't spare chip memory for the 8 sets of sprites.

Just get the actual gameplay working and not worry about changing the parallax sprites every 5 minutes!

I don't want to be faster, just to have a better looking parallax. Btw at least with copper list I did better than jim powers' programmers..

[Trachu]

Originally Posted by sandruzzo

I don't want to be faster, just to have a better looking parallax. Btw at least with copper list I did better than jim powers' programmers..

Hhehehe I see you are too impressed with Jim Power technical excellence ;-)
Jim Power is using Dual Playfield mode, which limits the usable colours in main area to 7. They compensate this with extensive using of copper in other playfields.

Here we have 5 bitplane game with large paralax - something which was never used before and you did it using less resources than i thought. If it prooves to be working it might be a good example how to make colourful platform games for A500 in XXI.
So far i fit into 5 bitplanes so if we would have enough dma for 6th bitplane i will redraw all, but so far lets concentrate what we have now.

Dual Playfield mode is very interesting one coz it allows to draw many depths of playfield, but maybe we can do better ;-)

Could you write here your copperlist so we could examine what voodoo you have used.

[sandruzzo]

Originally Posted by Trachu

Hhehehe I see you are too impressed with Jim Power technical excellence ;-)
Jim Power is using Dual Playfield mode, which limits the usable colours in main area to 7. They compensate this with extensive using of copper in other playfields.

Here we have 5 bitplane game with large paralax - something which was never used before and you did it using less resources than i thought. If it prooves to be working it might be a good example how to make colourful platform games for A500 in XXI.
So far i fit into 5 bitplanes so if we would have enough dma for 6th bitplane i will redraw all, but so far lets concentrate what we have now.

Dual Playfield mode is very interesting one coz it allows to draw many depths of playfield, but maybe we can do better ;-)

Could you write here your copperlist so we could examine what voodoo you have used.

copper list is dinamically generated, so I can't post it here, I can post here just a piece of it that I use to generate copper sprites...

[Trachu]

Originally Posted by sandruzzo

copper list is dinamically generated, so I can't post it here, I can post here just a piece of it that I use to generate copper sprites...

Do what you can. what I am thinking is the actual cost of different paralax techniques on Amiga.

In JIM power copper copied background sprites are using all available DMA in display area, something i find very ineffective.

In Agony, static black and white plane requies blitter copying of entire bitplane every few frames - something also resource hungry.

In Risky woods they have to use 4 bitplanes in order to use 4 bitplanes sprite paralax effect - also no DMA left in display area.

So far our Ryggar DMA usage is very low and we have the superb graphics also. It would be even better if you would FINALLY fix display resolution ;-)

As far as i can see we could also make from sprites front field on the down of the screen - something like they did in Jim Power.