Discussion: Rygar AGA Edition

[mcgeezer]

Over the last couple of days I've worked on some sprite mutliplexing, with the scrolling mixed in the best I could achieve with 32x32 bobs was around 10 sprites so some thinking needed to be done.

Rygar is a fairly simple game really, enemies attack in 3 zones on the display which makes a sprite multiplexer appealing. You have the flying dragons and griffins in the upper zone, the drones, rhinos and little village henchman, lava men in the mid zone and you have the lava snakes in the lower zone.

So over the last couple of days I've worked on (with help from @ross) on putting 4 hardware sprites in each zone and mixing in the bobs engine. Sprites are limited to 16 colours, you can select different palettes for odd and even sprite but it makes no difference when attached sprites are used (as far as I'm concerned anyway).

So with that in mind I've had to select which enemies are bobs and hardware sprites and look at how often they appear in the game.

The Blue drones for example only appear on round 1,2 and 13 so they're gonna be bobs as they use a deep Blue gradient palette and is one of the first things that stand out when you see the game. Some sprites I can have a mix but the upshot is that enemies that are Brown, Red or White can be used as hardware sprites.

As the little rhinos are only 16 pixels high I get 2 for 1 on those with Bobs so I have them as both hw sprites and bobs as they appear often in the game.

The Demon dude will be a bob because he can appear after I've dropped the background blitting, the Blue large demon is a Bob because well...he's Blue - no getting round that. The end of round metal things are bobs as they are well..metal and they only appear once each round.

The multiplexer I've got at the moment does have some weird limitation in that I can't seem to reuse the same sprite further down the screen, not sure why yet but with about 20 sprites available now I think the game should be doable.

I think this game will all be about compromises, but it's going to take a lot of effort.

[ Show youtube player ]

[ross]

Originally Posted by mcgeezer

The multiplexer I've got at the moment does have some weird limitation in that I can't seem to reuse the same sprite further down the screen

Sure can be worked out
You need to be sure that DMA system do not reload SPRxPOS/CTL after sprite's last data fetch so immediately point PTR to a void zone with copper
(or the new sprite's data, that logically can also be the same).

And be sure that y end pos, span whole screen.

Great progress here!

[mcgeezer]

I managed to work out what was wrong with the identical sprites in the multiplexer and fixed it.

Anyway, before I sign off for the long bank holiday weekend away with the family I decided to create some of the animations...

I should point out that only the Bobs are animated, I haven't plugged in the routines for the hardware sprites yet... pretty trivial to do though as I did it with Bomb Jack also.

There is definitely enough sprites to handle the game action now... very pleased. Coding it will still be hard though and it will require alot of thinking time.

Enjoy and have a great weekend everyone.

[ Show youtube player ]

[DamienD]

Looking good my friend

[vulture]

Great work so far!

[ReadOnlyCat]

Originally Posted by mcgeezer

PS. I've contacted Koei Tecmo Europe tonight and have the contact of their general manager to ask for permission to license/port the game to the Amiga. The answer can only be yes or no... or somewhere in between cost wise.

Originally Posted by Retro-Nerd

I don't think that was a clever move. This could killl the project before you really started it. I can't imagine that they license Rygar for a freeware port. But now they are aware of the project.

Originally Posted by jotd

I think I know the answer in advance... Those companies think they can still make money with those old games. See the 1:1 ports made on Nintendo DS of all arcade classics like Pacman, Green Beret, Scramble...

I actually think this is a good idea.
Assuming that the answer is going to be negative is not productive and I would say is a bad habit of the Amiga community. Sure this avoids potential deception but this also guarantees that no authorization is ever received even thought there are definitely studios who would agree to that, but to find them, we must ask them.

Whoever does not try, never wins.

Originally Posted by jotd

Now I'm wondering: did they rewrite emulators or just copied MAME source code, which would clearly be a case of GPL license violation Hard to tell without disassembling and comparing code structures...

Most of the studios who write arcade compilations (and there are actually a handful: Digital Eclipse, DotEmu, Hamster, and some others I do not recall at the moment) definitely use and write their own emulators. There is a definitive advantage to that: once you have written an emulator for a given arcade board, most of the games which run on it can be easily adapted.


Anyway, back on topic: great work!
Keep up the effort.

[Retro-Nerd]

I actually think this is a good idea. Assuming that the answer is going to be negative is not productive and I would say is a bad habit of the Amiga community. Sure this avoids potential deception but this also guarantees that no authorization is ever received even thought there are definitely studios who would agree to that, but to find them, we must ask them.

You do realize it's still a commercially active IP for them? Why should Koei Tecmo give you a licence for a dead platform? They would gain nothing from it. Well, they could decide to "allow" this port/conversion as freeware, nothing more. We'll see. Doesn't happen in 99,9% of all cases though.

[mcgeezer]

The game wont be offered commercially.

However it will be offered on a download for free or pay anything term, which will go toward future project developments.

Only fair given i will spend probbaly 500 hours building the game.

[invent]

Worse case scenario mcgeezer, we'll use the engine and re-skin it with a futuristic/robotic city or something else I'm sure your great efforts won't be wasted, I think your more likely to get some agreement with the company if your upfront and open about the project.

[Tigerskunk]

Super nice project! A shame I just discovered it now.
Was in kind of in an Amiga hiatus over the summer time, just coming back...

[Tigerskunk]

Originally Posted by chb

Just a little idea: As I understand it, you're using a 5 + 3 bitplane setup, with a palette chosen in a way that emulates dual play field mode. Then you're scrolling the 3 background planes with the blitter.
.

So, this is a variation of that "1 plane shown in the background"-technique used in James Pond or Agony with duplicated colour entries in the palette?

Where do you get the dma blitting the whole background "playfield" every frame then?
I guess I am missing some detail here...

Anyway, interesting technical setup at work here.

[roondar]

Originally Posted by Steril707

So, this is a variation of that "1 plane shown in the background"-technique used in James Pond or Agony with duplicated colour entries in the palette?

Where do you get the dma blitting the whole background "playfield" every frame then?
I guess I am missing some detail here...

Anyway, interesting technical setup at work here.

As far as I understand it, his dual layer technique currently works by using the horizontal scroll register as if the screen is in Dual Playfield mode (while it is not). With the proper palette set up, this would work exactly like standard Dual Playfield (Layer 1 with 15 and layer 2 with 16 colours), except for the more complicated palette setup.

However, he has set the palette up for a layer of 32 and a layer of 8 colours. Then, he blits 1 of the 'background' bitplanes with the content and offset matching the 'foreground' bitplanes.

This way he gets one 5 bitplane foreground and one 3 bitplane background, while only blitting one plane. Quite a nice technique

[Tigerskunk]

That's superclever and interesting to me as well, since my most missed feature on the OCS is a 4-2 bitplane split instead of 3-3, which feels so useless most of the time.

Currently I use a sprite backplane, but that's taking almost all of the DMA and leaves not much for blitting objects, even with triple buffering at work.

Wonder if this method leaves more time for that.

[ross]

Originally Posted by Steril707

Wonder if this method leaves more time for that.

I do not think so.
This works because of AGA, that leave much free DMA time than OCS (for the blitter screen shift).

Remember that you need to use a single scroll register in this mode, so you are forced to rewrite all 3 planes for every x scroll movements.

Dual playfield avoids all this!

Agony and some other use a single, lines limited, plane...

[mcgeezer]

Yes, there are two methods in AGA to get a 32 colour and 8 colour parallax as far as I can see, both with pros and cons.

Method 1 is to use normal hardware scrolling keeping both odd and even BPLCON1 hardware scroll registers the same and blitting the 3 background planes every frame or as required.

Method 2 is to put 4 front planes on odd registers and 3 on even registers and an additional front plane on the remaining odd register. You then use different BPLCON1 hardware scroll values and then compensate the display with the wrong even plane by blitting the plane from the pristine buffer.

Method 1 uses more time than 2. I have method 1 and 2 working, however...

In Rygar I will probably go with method 1 for a couple of reasons.

If you watch the arcade game you'll notice that busier parts do not have the background showing, this means I can disable the background blits at key points where I would not be able to do that with method 2. Some backgrounds are smaller than other too.

Method 2 requires a more difficult palette to be setup which does not help when it comes to using the hardware sprites.

If possible I might even use both methods.... but by God, method 2 was hard to implement.... it actually made me ill for a short while as my head hurt so much from it.

The palette in method 1 is simple. Each of the 8 palette banks has the same palette repeating except for each register except the first register after bank 5.

Registers 0,32,64,96,128,160,192 & 224 all make up the background colour registers.

The palette in method 2 isn't, but I documented how to do in a previous post, a real brain teaser.

Geezer

[Tigerskunk]

Originally Posted by mcgeezer

but by God, method 2 was hard to implement.... it actually made me ill for a short while as my head hurt so much from it.

Oh, I know that so well.

I call that "going the full Gollum", since in the end I feel like I have been living in a cave for weeks, having headache, being tired and my face is pale..

I was like that when I had finally finished my sprite multiplexer for Inviyya.

[ross]

Method 2 is

But good that you've written a reference implementation in your 'diary'

[roondar]

Originally Posted by ross

Remember that you need to use a single scroll register in this mode, so you are forced to rewrite all 3 planes for every x scroll movements.

This is not correct, the odd and even shifts can be set separately even when not in Dual Playfield mode. Therefore, you can use the same corkscrew method for the background as for the foreground (each pointing to a different area of memory).

All you need to do is update the background bitplane pointers every time the shift register overflows. Well, that and blit the one background bitplane you want to keep aligned with the foreground.
(And get a serious headache setting all this 'easy' stuff up so that it works )

Edit: the bit above might no longer be relevant. This post took some time and others have also replied in the mean time.

--

Originally Posted by Steril707

Wonder if this method leaves more time for that.

You can do something similar to what McGeezer calls method 2 on OCS, but before you run into performance problem, you'd first run into the numbers of planes being more limited. This effectively limits the layers to 15/2 colours (for 5 BPL) or 15/4 colours (for EHB - which further limits the background to 'dark' colours).


The question whether or not this is worthwhile for performance benefits does remain, so out with the back of the envelope and a calculator

Generally, a sprite layer will take one or two copper waits + 18-20 sprite reposition moves per scanline, plus sprite DMA for 8 sprites. This is equivalent to 39-43 (copper)+16 (sprites) = 55-59 DMA slots per scanline total.

Blitting one full bitplane means blitting in copy mode for 19-21 words (288-320px + 1 word for shifting) per scanline. A copy mode blit costs 2 DMA slots per words, or 38-42 DMA slots per scanline total.

This is faster, but do note that this is a somewhat simplified view on the algorithm and memory buffers needed to achieve this so the actual work needed might creep closer to the sprite layer cost.

[ross]

Originally Posted by roondar

This is not correct, the odd and even shifts can be set separately even when not in Dual Playfield mode. Therefore, you can use the same corkscrew method for the background as for the foreground (each pointing to a different area of memory).

Yes, you are right, I've oversimplified.
My intention was to specify that it is not as simple as in the dual playfield where even and odd bitplanes scroll registers can move fields freely without interactions between them.

Method 2 colors interaction are terrible..

[mcgeezer]

Originally Posted by Steril707

Oh, I know that so well.

I call that "going the full Gollum", since in the end I feel like I have been living in a cave for weeks, having headache, being tired and my face is pale..

I was like that when I had finally finished my sprite multiplexer for Inviyya.

I'm pleased it isn't just me who gets like this, really that took it out of me so you'll notice there hasn't been many updates as I've been having a rest.

I'd be interested to see details on your sprite multiplexer... Ross really helped me massively with the one I have for Rygar but I'm always looking for improvements.

re. method 2 - here is a link to post 175 earlier in the thread that hurt my brain. http://eab.abime.net/showpost.php?p=...&postcount=175