Entry: Rygar AGA Edition

[mcgeezer]

Here's my entry as I started work on this last night...

Title:
Rygar AGA Edition

Genre:
Arcade Action Platformer

Original concept:
No - This will be an arcade port of the original Tecmo game to the Amiga A1200.

Expected game size:
Game has 27 levels about 30 mins to play. I will develop as many as I can time allowing for the competition.

Team members (Real or forum names):
At the moment.
mcgeezer: (coding/gfx formatting & extraction),
dflrsilver: (gfx extraction)
invent: (level map construction)
music/sound: DJ Metune, Dan Terminus (CD Audio)

Targeted spec:
A1200 stock Amiga with 2MB Chip Ram (memory requirement may change).

Tools to be used:

• Devpac 3
• VASM
• Notepad++
• WINUAE
• Paint.net
• Personal Paint
• Windows 10
• VGMAPS.com
• XConvert
• MAME 0.180

Description of game:
Well known classic arcade action platformer

Other notes:
Like I did with Bomb Jack I will start full development in October 2018, between now and then I will be arranging tiles/sprites into correct order/sizes. I will provide development updates as I go in the form of YT videos.

[Ian]

Hi Guys, please try and keep the entry threads clear just for posting by the entrant.

I have copied this here:

http://eab.abime.net/showthread.php?t=93545

Feel free to discuss as you were in that thread and keep the entry thread just for mcgeezer to post any updates that he wants to divulge.

[mcgeezer]

As actual proper coding won't fully start until around 15th October I wanted to show some of what I'll be doing up and around until that point with preparing the graphics for the game.

The sprites that dflrsilver provided were not in any sort of structured format so they all need to be accurately aligned so that the blitter can pick them up and display them, most of the sprites are 32x32 in size so they all need to be put in a 32x32 grid. In the lower part of the screen shot that follows you can see this process... which... is very time consuming as there are alot of sprites in the game. The other thing to note about this is that some sprites need to be mirrored so I need to have flipped copies.

On top of that the sprites need to be ordered in a specific way depending on if they are enemies/collectables etc so that when I come to coding the game I can do efficient collision detection.




In the upper part of the screen you can see how I'm extracting the background on the Rygar levels. For doing this we need MAME and the internal debugger with some cheats. What I've done is disabled the front tile map and sprites which allows just the background showing through. I then move across the level with infinite lives and time set and screen shot the backgrounds, stitch them together to make up the whole scene.

This whole process will probably take me all of August, I will try to keep things updated but rest assured I'm working on it unless you hear otherwise (here).

Exciting times.

Geezer

PS. As requested by Ian if you want to discuss then please post in the discussion thread and reference this post number.

[dlfrsilver]

Hi Mcgeezer, what i did is that i have extracted each frame per order in the sprite tile bank, going top left to down right.

[mcgeezer]

I took a little break from the sprite extraction stuff and decided to test my theory on the scrolling with 8 bit planes.

The video below is a simple scroll test which is blitting the back 3 bit planes to show that the engine would actually work, what is in front is just a simple 32 colour bit map in the front 5 bit planes.

There's no double buffering or anything going on so it appears a bit jerky but the important thing is that I can scroll 2 playfields, 1 at 32 colours and the other at 8 colours... dual playfield mode in 16/16 colours just won't do the game justice.

[ Show youtube player ]

[mcgeezer]

A couple of hours tonight pretty much completing the sprite formatting.

There's a lot of work to be done with this as the sprites look a bit washed out, if I can switch palettes between enemies on screen then I can get more colours... probably double at least.

[ Show youtube player ]

Notice how I have put the enemies death sprites right at the end... this is so that I can easily work out that I don't need to generate enemy collision masks for those sprites.... anything else will interact with Rygar (either kill him or help him).

[mcgeezer]

I started work tonight on the collisions.

Now it doesn't look like much but the video showing the routine below is quite important to the game engine

As Rygar moves toward the right, the platforms that can be jumped upon scroll in from the right. Once the sprite masks are prepared I can then easily work out if Rygar is standing on a platform or any of the enemies for that matter.

Getting this bit right is very core to the game.

[ Show youtube player ]

The test here is just done with a mock map, but it's just as easy to determine if specific tiles are being moved in by their value.

The reason I only scroll in lines is to do with efficiency, I only need one blit to move all the platforms and 14 vertical platforms are allowed.

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.

[mcgeezer]

I completed the collision bitmap tonight so that it scrolls left and right with the joystick. It's bringing in collision tiles every 16 pixels in the left and right borders depending on which way you move.

Additionally, I set the blit modulo to 8 Y axis pixels as opposed to 16 because I anticipate that the little Rhino sprite needs to know when it has hit a wall, 16 pixels height would be tool large for this and I wouldn't have been able to have it collide with an obstacle.

[ Show youtube player ]

PS. And if you're wondering.... Leo is my 3 year old son.

[mcgeezer]

Ugghhh... the trials and tribulations of scrolling on the Amiga.

My oh my, this AGA coding just beat the shit out of me.

To get the best out of the AGA you need to use the machine in 32 bit mode (FMODE) so you can get full access to the speed for bitplanes or sprites. The problem is is that this has a lot of side effects (mainly unwanted) that you have to contend with... as I've just found out. I bet them console programmers don't have this bother.

Anyway, I've started work on the scrolling map as it's important I get this working along side the collision stuff.

This isn't working perfect yet, it's close but like I said it's beat me tonight, I'll sleep on it but I like to do regular updates.

For some reason the tiles are not coming in on the borders at the right times. I've had worse bugs though and fixed them so I doubt this will be any different. One thing I am fairly pleased with is the amount of processor time it's chewing up... compared to an A500 this is very favourable.

If I can fix it then the project will rapidly start to look like Rygar. Those numbered tiles are just for test, the map is 64 tiles wide by 12 depth... I'd just need to change the sizes and load the Rygar maps when I have it working.

[ Show youtube player ]

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

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

[mcgeezer]

So over the last couple of nights I've worked on something which is pretty fundamental to smooth running games - Double buffering.

Although the video below doesn't look much different to the last one, there is a key important process going on with the way in which the display is rendered.

[ Show youtube player ]

I have the vertical beam waiting for line 103 which is roughly at the start of where the mountains need to be drawn with the blitter. Now without double buffering what you would see here is a tearing effect when the mountains are scrolled left or right because as the beam is racing down the screen the blitter is also racing down drawing the next set of pixels to the left or right, the upshot being that you get an unwanted crap effect.

Double buffering solves this problem. With it in place, the blitter is drawing the mountains to a hidden display field somewhere else in the Amiga's memory so that it doesn't effect what is currently on screen. When the vertical beam reaches the bottom of the screen we flip the display pointers which then instantly shows the display that was just rendered with the mountains. This process alternates every frame.

Show the front display, draw the back display.
Show the back display, draw the front and so on.

Anyway, that's double buffering, bit a of pain to get right but once it's done you kinda leave it alone.

Next I'll be fixing up some of the graphics and palettes, you'll notice the background is short on length and the temple scene has transparent blocks in the background - both need to be fixed, then it'll building in the sprite engine.

PS: The scrolling is actually very smooth, the video capturing stuff just makes it look a bit jerky so I might use another method to do a capture.

[mcgeezer]

So I continued working on the scrolling routine late last night and have had a bit of time this evening too to work on it, I'm stopping now and going to enjoy a couple of beers and maybe play Transplant (I love that game).

In this update I've worked on the switching between rounds which is quite important for the game. I'm pleased to say that this is pretty much working barring the odd bug here and there. I haven't quite got round to finishing level 4 but you'll see from the video that it's almost there.

Those who know Rygar will know that every 4th level the background changes to something more static with a nice sunset and a silhouette of scrolling mountains.

This means I have to change the background blitter code somewhat, but not too much. What I'm attempting to do is have the sunset in 2 bitplanes / 4 colours and have the third bitplane scroll with the mountains. As I've found out I have to blit all three bitplanes because the Amiga scroll registers causes the static background to slide... so I have to blit two planes of the 96x84 sunset and then blit1 plane of the mountains underneath.

Gonna have a beer. Enjoy.

[ Show youtube player ]

[mcgeezer]

So this morning and tonight I worked on some more of the scrolling... there's still some bugz but it's getting better.

Now the video below is taken straight from WinUAE with no filter because I wanted to show that the scrolling is smooth, when I use OBS this isn't immediately obvious.

The eagle eyed among you will notice that I've put in gradient backgrounds
with the copper which really makes the scenery look the business, I haven't went too mad though but as it is different from the arcade you can let me know if it's an improvement or not for the Amiga.

[ Show youtube player ]

OBS Version here.

[ Show youtube player ]

Fixed the sunset round too - real pain it was.

Getting there with the scrolling then the real hard work starts.

Geezer

[mcgeezer]

Tonight I did a major tidy up on the code... organised everything into proper sections and documented the nuts off everything.

Also fixed the background positions (cheers @DamienD).

Also fixed (well patched) the broken tiles when switching rounds...

Got to say - it looks really nice, well pleased. I'll take a short break now before starting on the sprites.

[ Show youtube player ]

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

[dlfrsilver]

yes rygar arcade run at 60 fps.

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

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

[mcgeezer]

Another quick update here.

Last night I worked on fixing some things up like the background scrolling and doing bits of optimsations here and there.

This morning I've worked on integrating the hardware sprite animations.

Doing this has resulted in me losing a sprite or two though so I need to optimise some more.

There are factors in the scrolling which although look correct are not really doing what they are supposed to be, this is causing me to blit more words into the background than I should be... so I'm looking into it.

Another thing I plan on doing is some sort of blitter queue system so I can do all the blits in one go, this will hopefully enable me to mutli-thread the CPU to do other things.... all trial and error really.

[ Show youtube player ]