Conversion Capers: Rygar

[jotd]

I could try, but that's not straightforward. OK

[buzzybee]

I´m curious regarding bobs on interleaved bitmaps: Is there a way to blit interleaved bitmaps without having to use "big" cookie cuts, did I understand this right? If yes, could someone explain how this is supposed to work and what is meant by "smart usage of modulus"?

[alpine9000]

Originally Posted by buzzybee

I´m curious regarding bobs on interleaved bitmaps: Is there a way to blit interleaved bitmaps without having to use "big" cookie cuts, did I understand this right? If yes, could someone explain how this is supposed to work and what is meant by "smart usage of modulus"?

You can blit one interleaved plane at a time using an interleaved modulo for the source/dest and non interleaved modulo for the mask.

I do this in a game I'm writing. The benefit it you can still do single multiplane blits when you don't need a mask, like tile rendering or backplane restores.

[sandruzzo]

Originally Posted by alpine9000

You can blit one interleaved plane at a time using an interleaved modulo for the source/dest and non interleaved modulo for the mask.

I do this in a game I'm writing. The benefit it you can still do single multiplane blits when you don't need a mask, like tile rendering or backplane restores.

For cookie cut, ther is no so much that you can do

[alpine9000]

Originally Posted by sandruzzo

For cookie cut, ther is no so much that you can do

It works with cookie cut

[buzzybee]

@alpine9000: So that´s a conventional "blit one bitplane per go" technique, applied to a interleaved bitplane setup right? I wonder if there is some kind of smart and fast technique to combine interleaved bitplane source and non-interleaved cookie cut when blitting to all bitplanes :-)

[alpine9000]

Originally Posted by buzzybee

@alpine9000: So that´s a conventional "blit one bitplane per go" technique, applied to a interleaved bitplane setup right? I wonder if there is some kind of smart and fast technique to combine interleaved bitplane source and non-interleaved cookie cut when blitting to all bitplanes :-)

That's right. I don't know of a smart way to do it.

[Trachu]

Here are my 2 cents regarding DMA optimisations to free more DMA slots. I have taken the current DMA activity screenshot and placed there 4 raster positions which could be further optimised.

a) At the very top you set via copper a lot of settings. Are they all necessary?There is even unnecessary sprite activation????

b) After you revert from top status screen to game area you again use a lot of copper. I think some of them are unnecessary (explanation below) and one of them changes resolution from 256 to 240px(maybe if you enable hardware scroll regioster you need to set resolution 16px higher, in our case 272???).
I would also look for BUG responsible for white sky here.

c) The display dma is too close to sprite DMA. In this way DMA is both consumed by display and copper. No Wonder you thought about limiting sprite resolution, however there is another way. If you could move dsiplay window to the right with this register you would have more free interleaved DMA slots between Pink sprite DMA and blue display DMA.
http://amigadev.elowar.com/read/ADCD.../node0071.html

d) Here again you use a lot of unnecessary DMA slot for copper. I guess you set the new palette for down status panel. Here what i would suggest to join this panel with the top. In this way you could resign from one copper raster line.
More saving can be done if youmove both joined status panel to the below, then you can remove the while cooper line at position b).
Cooper activity at Position d) can be removed if we will unify first 16 colour registers for both game and status.

Optimal solution would be to set the whole palette for the game at the very top and only use copper for sprites inside the game area and change to UNIFIED status screen below. Also use DIWSRT register.
If you still want smaller sprite background i can go to 82 lines removing the clouds and distant trees below the mountain.

[sandruzzo]

Originally Posted by alpine9000

That's right. I don't know of a smart way to do it.

Yes you can, but allways 6 blitting are needed: 1 coockie-cut, and 1 for make an hall in the others planes

[sandruzzo]

Originally Posted by Trachu

Here are my 2 cents regarding DMA optimisations to free more DMA slots. I have taken the current DMA activity screenshot and placed there 4 raster positions which could be further optimised.

a) At the very top you set via copper a lot of settings. Are they all necessary?There is even unnecessary sprite activation????

b) After you revert from top status screen to game area you again use a lot of copper. I think some of them are unnecessary (explanation below) and one of them changes resolution from 256 to 240px(maybe if you enable hardware scroll regioster you need to set resolution 16px higher, in our case 272???).
I would also look for BUG responsible for white sky here.

c) The display dma is too close to sprite DMA. In this way DMA is both consumed by display and copper. No Wonder you thought about limiting sprite resolution, however there is another way. If you could move dsiplay window to the right with this register you would have more free interleaved DMA slots between Pink sprite DMA and blue display DMA.
http://amigadev.elowar.com/read/ADCD.../node0071.html

d) Here again you use a lot of unnecessary DMA slot for copper. I guess you set the new palette for down status panel. Here what i would suggest to join this panel with the top. In this way you could resign from one copper raster line.
More saving can be done if youmove both joined status panel to the below, then you can remove the while cooper line at position b).
Cooper activity at Position d) can be removed if we will unify first 16 colour registers for both game and status.

Optimal solution would be to set the whole palette for the game at the very top and only use copper for sprites inside the game area and change to UNIFIED status screen below. Also use DIWSRT register.
If you still want smaller sprite background i can go to 82 lines removing the clouds and distant trees below the mountain.

For scrolling you need 32 more pixel not 16. I Did a lot of test about turning on off upper and lower panel, even turning off the whole parallax. We have to few cicles anyway.

I can try to do standar coockie cut for enemies, but only 4 planes, and the others 2 we'll be small coockie cutt what will spare 2 cicles per word per bobs.

[Trachu]

Originally Posted by sandruzzo

For scrolling you need 32 more pixel not 16. I Did a lot of test about turning on off upper and lower panel, even turning off the whole parallax. We have to few cicles anyway.

I can try to do standar coockie cut for enemies, but only 4 planes, and the others 2 we'll be small coockie cutt what will spare 2 cicles per word per bobs.

Actually you still have 240px wide screen activated and from what i know you need only 16px more DMA fetches which you clearly have on DMA screen.

http://amigadev.elowar.com/read/ADCD.../node012B.html

"If you want to scroll a playfield , one extra data word per line must be fetched from the memory."

Maybe you are thinking about memory allocation, but i am talking about DMA only.
Generally your copperlist need to be optimised, but what we gain here will be used by 256px resolution. We need both your cookie cut and this.

[sandruzzo]

Originally Posted by Trachu

Actually you still have 240px wide screen activated and from what i know you need only 16px more DMA fetches which you clearly have on DMA screen.Maybe you are thinking about memory allocation, but i am talking about DMA only.
Generally your copperlist need to be optimised and we probaby need both.

Copper list is at the minimum. What bite a lot are sprites and DMA bitplanes..

[Trachu]

Originally Posted by sandruzzo

Copper list is at the minimum. What bite a lot are sprites and DMA bitplanes..

with your current screen setting I believe you, but by reallocating status screen we can save enough to set 256px wide.
You are right bobs are taking a lot, but what about shrinking dragon to 32x32?

[sandruzzo]

Originally Posted by Trachu

with your current screen setting I believe you, but by reallocating status screen we can save enough to set 256px wide.
You are right bobs are taking a lot, but what about shrinking dragon to 32x32?

Good Idea, but I was think about having one dragon made by sprites. Now I want to try to limit at 4 planes enemies and rygar, and see if it'll fly.

Each enemies can have its' own 4 planes as we need!

[NorthWay]

Are you changing all the colours down the screen? There is no need to use the copper to set the palette unless you keep modifying them.
About the only thing needed in a copperlist is setting bitplane pointers IIRC. Plus things that change ofc.

[Trachu]

Originally Posted by NorthWay

Are you changing all the colours down the screen? There is no need to use the copper to set the palette unless you keep modifying them.
About the only thing needed in a copperlist is setting bitplane pointers IIRC. Plus things that change ofc.

CURRENTLY both panels on above and down use their own palette thats why the copper operates here. Of course all panels and game area can use unified palette, so the colours can be set once. Of course we wont save too many cycles that way but we are fighting here for every free dma slot so we could stay at EHB 50Hz with paralax.

[sandruzzo]

Originally Posted by Trachu

CURRENTLY both panels on above and down use their own palette thats why the copper operates here. Of course all panels and game area can use unified palette, so the colours can be set once. Of course we wont save too many cycles that way but we are fighting here for every free dma slot so we could stay at EHB 50Hz with paralax.

Panels are now 3 planes only, not 4 like before. So I've freed a lot of dma slots.

[sandruzzo]

Added test version which use 4 planes for full coockie-cut and the others 2 will use less expensive ones. It's called Rygar2.adf


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

[Trachu]

Originally Posted by sandruzzo

Panels are now 3 planes only, not 4 like before. So I've freed a lot of dma slots.

Ok I have checked your current DMA activity.
It looks like you have freed slots which are not used because in the raster area of them only CPU is used so 4th bitplane slot is ALWAYS empty.
Sorry but You have degraded the quality without any gain. Yet you still have plenty of notused by anything DMA slots. I know it will be hard to utilise them all, but if you want extra speed search it here.

The best idea if you cant change your raster code execution is to move the top panel down. In this way the area of CPU activity will fit perfectly to 6 bitplane screen.

[Retro-Nerd]

Added test version which use 4 planes for full coockie-cut and the others 2 will use less expensive ones. It's called Rygar2.adf

Still huge slowdowns if 2 dragons are on the screen, A500+ config.