Discussion: Rygar AGA Edition

[sandruzzo]

Originally Posted by mcgeezer

40 colours

Wow!

I think you're using dualplayfield... On Aga I would use pèure 64 colors, and 6 HW sprites for parallax and others 2 for rygar, since screen size is only 256 you won't byte any sprite for HW scrolling. This will give you 80 colors without copper!

Willing to help if you need

[mcgeezer]

Originally Posted by sandruzzo

Wow!

I think you're using dualplayfield... On Aga I would use pèure 64 colors, and 6 HW sprites for parallax and others 2 for rygar, since screen size is only 256 you won't byte any sprite for HW scrolling. This will give you 80 colors without copper!

Willing to help if you need

Dual Playfield is limited to 16 colours on AGA and if I used hardware sprites for the background I'd be limited to 4 colours so the graphics would suffer.

Edit - I used 8 bit plane mode, 32 colours for foreground and 8 colours for background (blitted).

[vulture]

Originally Posted by mcgeezer

20 32x32 sprites excluding Disk Armor and collision, 50hz, full scrolling.

I doubt a stock OCS could do this.

[ Show youtube player ]

Yeah, I've no clue, I'm no programmer, I just said that even if it's not arcade-perfect, sandruzzo's effort was looking very good and maybe it could be further improved if the screen height was reduced. Of course your AGA port looks stunning so far!

[sandruzzo]

Originally Posted by mcgeezer

Dual Playfield is limited to 16 colours on AGA and if I used hardware sprites for the background I'd be limited to 4 colours so the graphics would suffer.

Edit - I used 8 bit plane mode, 32 colours for foreground and 8 colours for background (blitted).

Since Aga sprites are 64 pixel wide, u can attach them and have 4 64pixel sprites with 16 colors!

[mcgeezer]

Originally Posted by sandruzzo

Since Aga sprites are 64 pixel wide, u can attach them and have 4 64pixel sprites with 16 colors!

So 4*64 pixel sprites gives you 256 pixels, how would you wrap the display? You'd need an extra two sprites to do it (by my calculations).

[sandruzzo]

Originally Posted by mcgeezer

So 4*64 pixel sprites gives you 256 pixels, how would you wrap the display? You'd need an extra two sprites to do it (by my calculations).

By animation, like we did for Rygar Ocs

[mcgeezer]

Originally Posted by sandruzzo

By animation, like we did for Rygar Ocs

Sorry you've lost me, I don't know what you mean? Could you elaborate?

[mcgeezer]

This is a great update as I've added most of the logic in the upper and lower panels.

Everything is implemented including the Ranks (notice how they increase which I have simply automated), the timer is working just about, Lives, Power-ups (although wrong order ) and round guide.

I also did a performance test and the game can still push roughly 20 * 32x32 sprites in one frame - but I'll need to be clever with how I use them as 12 of them need to work in specific screen regions.

Implementing the panels was a bit of a pain because the hardware sprites have priorities which dictate if a sprite is over or behind a playfield. Sprites need to go behind the upper and lower panels but must go infront of the main game area.

Getting there now....must work on that loader. What definitely works for my motivation when coding is working on something non-visual and then visual, I spent ages getting the internal game logic working for the stones and collision detection which was painful and then have really enjoyed doing these panels.

Once again - thanks to @Ross and @Roondar for their expert copper help - you guys are spot on!

Geezer

[ Show youtube player ]


Edit - here's the nice version of the video.

http://109.228.4.199/panels.mp4

[DamienD]

Looks absolutely amazing Graeme

[sandruzzo]

Originally Posted by mcgeezer

Sorry you've lost me, I don't know what you mean? Could you elaborate?

Sorry, We did 12 animations' frames for parallax that is cyclical! So sprites never moves, only frames

[ross]

Originally Posted by sandruzzo

Sorry, We did 12 animations' frames for parallax that is cyclical! So sprites never moves, only frames

I think you mean 16 frames. Anyway this can work because you have a 16bit aligned fetch.
With FMODE(SPR32/SPAGEM=1) you need a 64bit align, so 64 frames required and, more importantly, you have no more a free form display..
Much better, if you want to stick to a fixed 4x64x16c sprites background, a blitter induced scroll on sprites data.

[sandruzzo]

Originally Posted by ross

I think you mean 16 frames. Anyway this can work because you have a 16bit aligned fetch.
With FMODE(SPR32/SPAGEM=1) you need a 64bit align, so 64 frames required and, more importantly, you have no more a free form display..
Much better, if you want to stick to a fixed 4x64x16c sprites background, a blitter induced scroll on sprites data.

We have animation every 2 pixel, because we use sprites trick that move them by 1 pixel, so we have less frames with 64 pixel sprites, i think 32 frames would suffice

[ross]

Originally Posted by sandruzzo

We have animation every 2 pixel, because we use sprites trick that move them by 1 pixel, so we have less frames with 64 pixel sprites, i think 32 frames would suffice

Yes, for OCS and x-multiplex this works.
Agreed, also on AGA and 32 frame, but so boring the same repeating display

EDIT
Thinking better about it, on AGA the number of animation frames no longer depends on any trick:
you can have a simple repetition through FMODE[SSCAN2=1].
So in fact you can easily make a screen that repeats every 256 pixels without any frame animation

[mcgeezer]

Originally Posted by ross

Yes, for OCS and x-multiplex this works.
Agreed, also on AGA and 32 frame, but so boring the same repeating display

EDIT
Thinking better about it, on AGA the number of animation frames no longer depends on any trick:
you can have a simple repetition through FMODE[SSCAN2=1].
So in fact you can easily make a screen that repeats every 256 pixels without any frame animation

For the background i need more than 256 pixels worth of sprites when in 64 wide mode.

Granted a repeating background would work but that would be a compromise on the game.

Its worth pointing out too that the back grounds scroll at different speeds, round 1 scrolls at 25fps and rounds 2,3,4... scroll at 50 fps.

Geezer

[ross]

Originally Posted by mcgeezer

For the background i need more than 256 pixels worth of sprites when in 64 wide mode.
Granted a repeating background would work but that would be a compromise on the game.

I agree with you that it is totally unsuitable for Rygar (AGA).
Mine was only a remark on Sandruzzo speak.

[Tigerskunk]

I am always wondering what kind of pact you made with the devil that lets you develop stuff that fast..

Great update, Graeme...

[mcgeezer]

Originally Posted by Steril707

I am always wondering what kind of pact you made with the devil that lets you develop stuff that fast..

Great update, Graeme...

Hahahah

Reusable programming my friend and setting the assets up that make it easy.

[aros-sg]

Originally Posted by mcgeezer

Edit - I used 8 bit plane mode, 32 colours for foreground and 8 colours for background (blitted).

Optimizations for 8 color background blit:


- Don't blit areas (scanlines) which are static. Like big blue sky area.


- Don't blit areas (like at the bottom of most levels) which are always obscured by foreground


- If larger vertical areas (scanlines) only use 4 colors make sure palette is such (or reset palette with copper at those lines) that you can handle those parts of the background blit with a 2-bitplane-blit.


- If there are multiple identical scanlines in background gfx have them only once in background bitmap (and thus shrinking vertical size of it) and instead reshow them by modifying plane pointer at scanline in copper list (~ vertical copper compression of bitmap)


- maybe ~compress parts of some of the backgrounds to half vertical resoultion (~1x2 pixels) if it does not make a big visual difference. ~uncompress again in copperlist.

[mcgeezer]

Originally Posted by aros-sg

Optimizations for 8 color background blit:

Originally Posted by aros-sg

- Don't blit areas (scanlines) which are static. Like big blue sky area.

Yep - I don't, the round config enables me to fill upper and lower areas on the Y line.

Originally Posted by aros-sg

- Don't blit areas (like at the bottom of most levels) which are always obscured by foreground

Yep - The round config enables the switching off of bitplanes at a particular Y line.

Originally Posted by aros-sg

- If larger vertical areas (scanlines) only use 4 colors make sure palette is such (or reset palette with copper at those lines) that you can handle those parts of the background blit with a 2-bitplane-blit.

Ummm.... bit difficult but I know what you mean. Could be more trouble than it's worth.

Originally Posted by aros-sg

- If there are multiple identical scanlines in background gfx have them only once in background bitmap (and thus shrinking vertical size of it) and instead reshow them by modifying plane pointer at scanline in copper list (~ vertical copper compression of bitmap)

Yeah, I'm aware of this, it will work for a couple of rounds (round 5 for instance).

Originally Posted by aros-sg

- maybe ~compress parts of some of the backgrounds to half vertical resoultion (~1x2 pixels) if it does not make a big visual difference. ~uncompress again in copperlist.

More trouble than it's worth I think unless i can easily implement it.

@anymod Please could you move/copy these relevant posts to the Rygar AGA discussion thread for me?

[DamienD]

Originally Posted by mcgeezer

@anymod Please could you move/copy these relevant posts to the Rygar AGA discussion thread for me?

I can't be bothered to work out exactly which posts; some encompass both threads...

PM me exactly which posts you want moved and it will be done