Discussion: Rygar AGA Edition

[mcgeezer]

Originally Posted by AChristian

are you able to extract the data for the levels like enemy placement,platform placement, player stats, enemy stats?

I haven't tried to be honest, but doing that could be quite difficult if going by how the tile maps are stored and arranged.

I feel this will be a manual task really.

[jotd]

Those guys! and people playing in the arcades probably didn't give a damn of the background.

[mcgeezer]

You have to admire the Tecmo game engineers and designers really. I had made an assumption early on in the project that the background scroll layers were running at 0.5 pixels per second which meant that I could draw half the background in 1 frame and the remaining half in the 2nd frame for a screen update.

When I looked at the scrolling on the second round I thought, 'oh that's running every frame at 1px per second instead of 0.5' so I thought that was the correct background scroll speed.

As it turns out, both are right. The damn background runs slower on round 1 than it does on rounds 2 & 3, I guess it depends on the type of scenery that was drawn. The further away the scene the slower it moves, the closer it is the faster it moves.

Anyway... to test that I nailed this I went to a bit of an extreme.

In the video below the Amiga which is pre-recorded is on the bottom window and me playing the arcade version of Mame is on the upper window. One thing to note is that I think the arcade does actually run at 50 frames per second, I haven't checked the driver yet but the notes says it runs at 60 FPS.

[ Show youtube player ]

[Retro-Nerd]

According to MAME info:

VIDEO:
256 x 224 (H) 59.185606 Hz

[roondar]

Looking at your video, the arcade version doesn't appear to run at 50Hz. Compare it with the Amiga display below, which has the characteristic 'hiccups' during scrolling every few frames and then due to being a 50Hz update on a 60Hz display, while the Arcade version above doesn't have those.

[mcgeezer]

Originally Posted by roondar

Looking at your video, the arcade version doesn't appear to run at 50Hz. Compare it with the Amiga display below, which has the characteristic 'hiccups' during scrolling every few frames and then due to being a 50Hz update on a 60Hz display, while the Arcade version above doesn't have those.

Yeah, i’m not going to worry about this too much. I’ll probably do an option to run pal or ntsc if i can. Similar thing happened with bomb jack but i was forced to pal because of the overscan (256 lines).

[mcgeezer]

This is a quick update...

Over the last couple of nights I plugged in my sprite engine and I can manage around 10 32x32 32 colour sprites on screen at the same time with full scrolling (I'll post a video of this later).

For the game to really work I need about 16 if you were to look at the arcade anyway.

Given I haven't used any hardware sprites I can get 4 additional sprites there. leaving me short of 2.

Someone contacted me on Youtube providing an idea similar to what @chb mentioned which would gain me an extra 2 sprites making it perfect so it is wise I explore rewriting part of the scroll routine to try and achieve this.

Basically if I use the hardware scroll registers to scroll the playfields but fixup the foreground plane from my pristine buffer using the blitter it works out alot faster than blitting the background scenery - much faster infact.

So anyway, I'm off for a swim and will code it when I get back - wish me luck.

I don't think the game is achievable with just 10 sprites.

[chb]

If you have a lot of memory to waste, you could also go full brute force and store 16 shifted versions of your bg image, Atari-style. Then all you'd need to do is setting the bitplane pointers. Costs you probably about 1MB chipmem extra, so very expensive, unless you're able to shrink your image (I think not all 184 lines are needed for the bg?).
Would also not require you to care about different scroll register values for BOBs.

Have a nice swim!

EDIT: Argh, you're in 32bit fetch mode if I remember correctly, so that means probably 32 pre-shifted backgrouds - probably not enough mem for THAT.

[mcgeezer]

Originally Posted by chb

If you have a lot of memory to waste, you could also go full brute force and store 16 shifted versions of your bg image, Atari-style. Then all you'd need to do is setting the bitplane pointers. Costs you probably about 1MB chipmem extra, so very expensive, unless you're able to shrink your image (I think not all 184 lines are needed for the bg?).
Would also not require you to care about different scroll register values for BOBs.

Have a nice swim!

EDIT: Argh, you're in 32bit fetch mode if I remember correctly, so that means probably 32 pre-shifted backgrouds - probably not enough mem for THAT.

Yeah, i already thought about going steve bak style on it.

[turrican3]

Will you animate the river fall ??

[AmigaHope]

Originally Posted by mcgeezer

Yeah, i’m not going to worry about this too much. I’ll probably do an option to run pal or ntsc if i can. Similar thing happened with bomb jack but i was forced to pal because of the overscan (256 lines).

From the arcade database, Rygar is:

256x224@59.185606 Hz, CRT 15kHz

So the closest you're gonna get to arcade at "normal" Amiga rates is 60Hz (pseudo-NTSC monitor rate). Your display is gonna look squashed though thanks to the Amiga's default faster pixel clock.

If you wanted to make a *really* accurate conversion though, you could take advantage of the fact that AGA has programmable scan rates and create an arcade-perfect screenmode for it to run at. This would probably only work on CRTs though and fail to work if connected to any modern monitor.

[mcgeezer]

Originally Posted by turrican3

Will you animate the river fall ??

Yep.

[DamienD]

Originally Posted by turrican3

Will you animate the river fall ??

Originally Posted by mcgeezer

Yep.

...and the lava in the section below the ground?

[mcgeezer]

Originally Posted by DamienD

...and the lava in the section below the ground?

It wouldnt be Rygar without it!

[mcgeezer]

I mentioned on the discussion thread earlier that someone contacted me on Youtube to say that it was possible to get away with one foreground blit instead of the three background blits I have been doing with the scrolling.

Well it looks like they were right, but by God it is not without it's pain.

So the original scrolling routine used the first 5 bitplanes making up 32 colours for the foreground and used the 3 remaining bitplanes for the background, to update the background I simply shift blit the blocks from the source scene into the destination planes.

When I did this I could achieve about 10 animated bobs meaning I could realistically get around 14 or less 32x32 sprites on screen. If you play the arcade of Rygar and use the cheat you'll see there is just over 15 to 16 sprites on screen at any one time so the more I can get on screen the better. Some of the hardware sprites I can multiplex such as the flying dragons to the rhino to the lava.

However, there's a more efficient way to do the scrolling getting me more sprites. If I interleave the bitplanes like this...

BP1 Foreground, BP2 Foreground, BP3 Foreground, BP4 Background, BP5 Foreground, BP6 Background, BP7 Foreground, BPP8 Background

So my background is pointed to by bitplanes 4, 6 and 8.

Now if I move the scroll registers independently without dual playfield mode I can get move planes the foreground in planes 1,3,5 & 7 independently to 2,4,6 & 8 which make up the background.

However, this poses a problem because bitplane 2 is a foreground plane but it is moving at the background speed, so all that is required is that I blit bitplane 2 from my pristine buffer over the background buffer to compensate.

All pretty simple stuff? Wrong.

Working out the colour palette alone to interleave the bitplanes has blown my mind... and to give you an example of my efforts, a picture speaks a thousand words.





Now my calculations for working out the palettes were sound, implementing though took a whole lot longer. The lesson to be learned for me here is 'Always use the copper to do your palettes'. For some reason the AGA does not set let you poke registers 8-15... even after disabling the copper.

Absolutely blew my mind, I can now get on with doing the background scrolling. It still won't be easy but will be worth it if I can pull it off.

Wish me luck.

[dlfrsilver]

I wish you luck !

[mcgeezer]

This is the code from a couple of revisions back...

10 sprite bobs on screen on round 1 when we get 50FPS, round 2 does a bit more in the background then we get slow down.

[ Show youtube player ]

It will be better.

[alpine9000]

If you’re right on the limit performance wise make sure you test on real hardware as winuae is slightly less accurate at emulating a cycle exact a1200 compared to a cycle exact a500.

[buzzybee]

I can totally relate to your posting. Reshoot (and RESHOOT R) also use AGAs basic bitplane setup without dual playfield, and it took me a long time to figure out the correct color register settings. Using sprites makes it even more complicated, because of the 16 (or 32) color registers reserved for sprites, intermixing with your basic 256 colors palette setup for the bitplan. I wish you luck :-)

As for raster timing: Don´t forget that game logic, collision control, music driver etc. will eat up precious cpu time, so you will probably end up with 7 or 8 blitted objects instead of 10 using the current code technique.

[mcgeezer]

Originally Posted by alpine9000

If you’re right on the limit performance wise make sure you test on real hardware as winuae is slightly less accurate at emulating a cycle exact a1200 compared to a cycle exact a500.

Yeah, I'm actively looking for one for around £200... crazy how they cost that much these days. I've just looked on Gumtree and there is someone selling an A1200 in my town so have made enquires, he wants £230.

Originally Posted by buzzybee

I can totally relate to your posting. Reshoot (and RESHOOT R) also use AGAs basic bitplane setup without dual playfield, and it took me a long time to figure out the correct color register settings. Using sprites makes it even more complicated, because of the 16 (or 32) color registers reserved for sprites, intermixing with your basic 256 colors palette setup for the bitplan. I wish you luck :-)

As for raster timing: Don´t forget that game logic, collision control, music driver etc. will eat up precious cpu time, so you will probably end up with 7 or 8 blitted objects instead of 10 using the current code technique.

I'm not kidding it took me ages to wrap my head around as it was real brain teaser, eventually it sunk in. When I had the code down and it just didn't work I started to doubt myself that the maths/bits were right, went back to the drawing board and came back with the same answer! It was only when I wrote a test palette display and realised the Amiga wasn't changing the palette registers 8-15 for bank 0 without the copper that the problem and solution presented itself.

Good shout about the sprite palettes, I have moved all the hardware sprites palettes into the 16-31 colour range but had not considered the hardware sprites after having to re-arrange the palette. Having a quick look I don't have the colours in registers 16-31 in any palette bank.

I'm taking a short break before I start the background scrolling routines which again became more complicated because the odd and even modulos have to be the same. I need a fresh head as all that took it out of me a little.