Discussion: Rygar AGA Edition

[idrougge]

You should read the comments about AGA in the Blitz Basic documentation. They're not suitable for children…

[jotd]

problem with AGA vs ECS is that it's been added afterwards. So you don't have direct access to AGA features like you have for ECS/OCS. And which madman thought that 8-bit planar would be the best & only choice? seriously??? good luck with your project. My proposal for the music still holds (unless Saimon69 chips in)

[DanScott]

For arcade game collisions, you should just use bounding box to bounding box collision. I can bet that 99% of arcade games just did this.

For tile collision, you should give each 16x16 pixel tile, a collision value eg:

0 = No collision
1 = Totally Solid
2 = Can pass through but can stand on top of
3 = Deadly to touch

etc..

You will find that in most cases you only have to check a few points... for example only check left or right of the character if they are moving in that direction, only check below the player if they are falling etc..

I wish I still had my sources for Chuck Rock 2 and Wonderdog... the collision in there was quite functional, including sloped tiles.

[jotd]

And you can reduce the box to the minimum to give the player the impression of "shaving it very close" some shooters reduced bounding box collision when moving (Raiden).

I didn't know that Chuck Rock 2 & Wonderdog coder visited the forum! Excellent.

[mcgeezer]

Originally Posted by DanScott

For arcade game collisions, you should just use bounding box to bounding box collision. I can bet that 99% of arcade games just did this.

For tile collision, you should give each 16x16 pixel tile, a collision value eg:

0 = No collision
1 = Totally Solid
2 = Can pass through but can stand on top of
3 = Deadly to touch

etc..

You will find that in most cases you only have to check a few points... for example only check left or right of the character if they are moving in that direction, only check below the player if they are falling etc..

I wish I still had my sources for Chuck Rock 2 and Wonderdog... the collision in there was quite functional, including sloped tiles.

If i can get the accuracy right i’ll do it this way. I tried it with bomb jack though and i had a world of pain getting the enemies to collide properly with the 8x8 solid tiles.

Having thought about the player to enemy collisions i will use the boundary box method over the zero fill flag.

[buzzybee]

Two areas which I absolutely learned to hate when using AGA with RESHOOT R: the way the chipset handles scrolling and color registers.

* As for your scrolling troubles - AGA handles (the scrolling register) BPLCON1 differently to ECS. Make sure you set the PFxH6 & PFxH7 in sync to the bitplane pointers.
* Make sure you check your code on real hardware. Some emulators (FS-UAE) handle the bitplan DMA a bit differently than real hardware. This might lead to scrolling, that works on emulation but does not on real hardware. Make sure that you only poke addresses dividable by four into the bitplane pointer registers.
* Using the blitter to check collission is a nice approach and I wish you luck that it still fits in without slowdowns when the game comes together. Personally I´d go for collission boxes and / or manhattan distance method, as these are faster by far. Use the 68020s cmp2 command, it´s very useful for this.

[mcgeezer]

It's surprising what a night sleep and a swim does for you.

I managed to get the scrolling mostly working now after a couple of hours today, there's still a small bug with tiles that have a 0 pixel Y axis but I'm sure I'll sort that.

[ Show youtube player ]

This scrolling engine is taking up about 80 scanlines of a frame which is more than I would like- plenty of little tricks to be done though.

AGA programming definitely comes with complications. A side effect of AGA that I doubt I'll be able to get around is that the display will be slightly to the right, there's not much I can do unless I lose a load of hardware sprites.

The arcade display is 256x224, and a standard Amiga display is 320x192 pixels, this allows 32 pixels at either side of the main display to scroll in new tiles into the main display - handy.

Now this means I'm having to put the Amiga bit planes into 32 bits wide mode meaning the Amiga transfers long words (instead of words on an A500) from chip ram which gives a big speed improvement. To get an even bigger improvement you can set it to transfer double long words (64 bits), but then I would need 64 pixels at each side of the main display. It is possible to over scan the display to get those 64 pixels but as most ASM Amiga coders will know you then eat into the sprite DMA which knocks out the hardware sprites.

Given I'm planning on using the hardware sprites for the large vulture and rhino enemies as they are 64 pixels wide I'm sticking with this display configuration and hopefully keeping the hardware sprites.

It wasn't easy doing this scrolling, and I didn't particularly enjoy coding it. it was frustrating and I can understand why others give up on the damn thing and swallow the Red pill/Blitz/Amos - an absolute pain in the arse to be honest.

Better times ahead as I will be loading the maps and will building in the sprite engine soon, I'll then be able to see how many sprites I can get on screen.

Geezer

[mcgeezer]

Originally Posted by buzzybee

Two areas which I absolutely learned to hate when using AGA with RESHOOT R: the way the chipset handles scrolling and color registers.

The colour registers hasn't bothered me that much yet but the scrolling I have found frustrating.

Originally Posted by buzzybee

* Make sure you check your code on real hardware. Some emulators (FS-UAE) handle the bitplan DMA a bit differently than real hardware. This might lead to scrolling, that works on emulation but does not on real hardware. Make sure that you only poke addresses dividable by four into the bitplane pointer registers.

Could be a problem - I don't own an A1200. At least not yet anyway, and beleive me I've had a long lesson in bitplane alignment.

Originally Posted by buzzybee

* Using the blitter to check collission is a nice approach and I wish you luck that it still fits in without slowdowns when the game comes together. Personally I´d go for collission boxes and / or manhattan distance method, as these are faster by far. Use the 68020s cmp2 command, it´s very useful for this.

I used the same collision approach on Bomb Jack, I like it because it's easy to code and is extremely accurate, as mentioned though I will probably go for the overlapping rectangles approach for enemy collisions.

Thanks for the cmp2 tip - I haven't touched the 68020 yet, it's still native 68000 for now and just hoping vasm optimises stuff to 68020.

[Tsak]

How do you plan to use hardware sprites? Only for enemies like the rhino and vulture?

Have you considered multiplexing? Rygar's setup is ideal basically, as the game has 3 different lanes (lava, grounds and sky) where enemies appear. So you could have 4 attached sprites as enemies in a single lane and then multiplex those to the other 2 lanes which can give you up to 12 enemies on screen, just using sprites! On the down side it is a fairly complex work to do and 64x64 sprites do cost a good amount of ram, but the performance boost will be signifficant compared to using bobs for the same job.

[mcgeezer]

Originally Posted by Tsak

How do you plan to use hardware sprites? Only for enemies like the rhino and vulture?

Have you considered multiplexing? Rygar's setup is ideal basically, as the game has 3 different lanes (lava, grounds and sky) where enemies appear. So you could have 4 attached sprites as enemies in a single lane and then multiplex those to the other 2 lanes which can give you up to 12 enemies on screen, just using sprites! On the down side it is a fairly complex work to do and 64x64 sprites do cost a good amount of ram, but the performance boost will be signifficant compared to using bobs for the same job.

Yep, you read my mind.

[roondar]

I've always thought that AGA sprites where under appreciated, 64 pixels is a very respectable width. Looking forward to seeing this in action

[Tsak]

It's respectable but you can only that much with them with only 8 channels available (which means only 4 sprites in 16 colors) and multiplexing isn't always an option. On the plus side AGA sprites do have their own individual 16 color palette which helps to up the colors on sceen.

Note to Mcgeezer: another thing you could take advantage of, so these monsters could have their own palette

[mcgeezer]

Originally Posted by Tsak

Note to Mcgeezer: another thing you could take advantage of, so these monsters could have their own palette

Can't do this because of the display configuration, it is in 8 bit plane mode with 5 bit planes for fore ground and 3 bit planes for back ground - giving 39 colours to play with, 31 fore ground, 7 background and + 1 shared colour.

[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.

Now, as you have two scroll values for odd and even planes, even if you are not using dual playfield, you could put your scroll value for the foreground into PF1H and for the background in PF2H. After that one foreground plane has the wrong scroll value - you need to compensate that with blitter. In total, you need to scroll only one plane with the blitter instead of 3.

There's a drawback: One foreground plane has a different scroll value than the others. If you blitt on all foreground planes, you'd need to compensate for that, which introduces overhead and is an additional source of nice little bugs. But if your game just uses 16 colors for the enemies, and 16 for the foreground colors, you can simply put all BOBs on even (or odd) planes and avoid that problem. It's then a nice and easy way to free some dma slots, esp. as the blitter isn't faster on AGA than on OCS.
Oh, and if you're not scrolling the background at 50 fps, you wouldn't win a lot of course.

[mcgeezer]

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.

Now, as you have two scroll values for odd and even planes, even if you are not using dual playfield, you could put your scroll value for the foreground into PF1H and for the background in PF2H. After that one foreground plane has the wrong scroll value - you need to compensate that with blitter. In total, you need to scroll only one plane with the blitter instead of 3.

There's a drawback: One foreground plane has a different scroll value than the others. If you blitt on all foreground planes, you'd need to compensate for that, which introduces overhead and is an additional source of nice little bugs. But if your game just uses 16 colors for the enemies, and 16 for the foreground colors, you can simply put all BOBs on even (or odd) planes and avoid that problem. It's then a nice and easy way to free some dma slots, esp. as the blitter isn't faster on AGA than on OCS.
Oh, and if you're not scrolling the background at 50 fps, you wouldn't win a lot of course.

That's a really interesting idea - I didn't think of it and it's probably worth a look.

Could be a bit tricky to implement though. While it's busy blitting the back ground I am using the CPU to copy in the tile blocks for the foreground scrolling, I can probably use the CPU to do other stuff as well during that time. Anyway my point is that at the moment I don't know if I have enough frame time to get around 16 32x32x32 bobs on screen at 50hz, I'll know soon enough though.

[roondar]

Originally Posted by mcgeezer

That's a really interesting idea - I didn't think of it and it's probably worth a look.

Could be a bit tricky to implement though. While it's busy blitting the back ground I am using the CPU to copy in the tile blocks for the foreground scrolling, I can probably use the CPU to do other stuff as well during that time. Anyway my point is that at the moment I don't know if I have enough frame time to get around 16 32x32x32 bobs on screen at 50hz, I'll know soon enough though.

It is indeed tricky, each of the bobs you draw after that will need to be drawn in two steps to compensate for the different offsets for each of the 'layers' you're drawing to.

I actually tried something similar to a few years back on my A500 but using a 5 bitplane screen, but didn't like the performance it gave me. Might be better on an A1200 though, as it will have a much lower overhead starting the blitter.

[chb]

Originally Posted by mcgeezer

That's a really interesting idea - I didn't think of it and it's probably worth a look.

Could be a bit tricky to implement though. While it's busy blitting the back ground I am using the CPU to copy in the tile blocks for the foreground scrolling, I can probably use the CPU to do other stuff as well during that time. Anyway my point is that at the moment I don't know if I have enough frame time to get around 16 32x32x32 bobs on screen at 50hz, I'll know soon enough though.

If you're using 32 color bobs, it gets really quite tricky, and you'd need to start the blitter twice as often (unless you are not using interleaved bitplanes, but I guess you do anyhow). So quite some overhead. It's definitely something I'd make sure that I really need it before implementing.

If you can live with 16 common colors for the bobs (e.g. if they share only a few colors with the foreground) it gets much easier. But probably too much of a limitation graphics wise for a game like Rygar.

Scrap that part . You'd need to blit a mask to the 5th bitplane anyway, so nothing simplified compared to five-plane bobs.

[mcgeezer]

Tonight I did a bit more work with the maps, they're pretty much there but I need to debug what is going on. I think some of the tiles in the map arn't correctly indexed so I need to make sure I take the correct one that invent supplied to me... no biggy.

[ Show youtube player ]

Blitting that large background layer takes up a fair amount of time, so while it's doing that I use the remaining CPU cycles to handle the foreground scrolling.

Still room for improvement though.

The test to see how many 32x32 sprites on screen will determine if this is a success though, we'll know soon enough.

Geezer

[roondar]

Originally Posted by mcgeezer

Tonight I did a bit more work with the maps, they're pretty much there but I need to debug what is going on. I think some of the tiles in the map arn't correctly indexed so I need to make sure I take the correct one that invent supplied to me... no biggy.

[ Show youtube player ]

Blitting that large background layer takes up a fair amount of time, so while it's doing that I use the remaining CPU cycles to handle the foreground scrolling.

Still room for improvement though.

The test to see how many 32x32 sprites on screen will determine if this is a success though, we'll know soon enough.

Geezer

The background layer is basically a shifted copy blit, right?

I'm not 100% sure, but that may actually be faster using the CPU. As I understand it, pure block copies are definitely faster using the 68020 - but I don't know how much faster or slower shifted copies are (the 68020 does have a barrel shifter so multi-bit shifts should not be slower than single-bit shifts).

Then again, Blitter/CPU running concurrently is said to be the best option on the A1200...

[mcgeezer]

Originally Posted by roondar

The background layer is basically a shifted copy blit, right?

I'm not 100% sure, but that may actually be faster using the CPU. As I understand it, pure block copies are definitely faster using the 68020 - but I don't know how much faster or slower shifted copies are (the 68020 does have a barrel shifter so multi-bit shifts should not be slower than single-bit shifts).

Then again, Blitter/CPU running concurrently is said to be the best option on the A1200...

I’d need 16 copies of the background in ram to do that. Cpu could not shift it as fast as the blitter can.