English Amiga Board

English Amiga Board (http://eab.abime.net/index.php)
-   Coders. Contest (http://eab.abime.net/forumdisplay.php?f=130)
-   -   Discussion: Rygar AGA Edition (http://eab.abime.net/showthread.php?t=93545)

mcgeezer 13 August 2018 17:12

Quote:

Originally Posted by AChristian (Post 1260722)
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 13 August 2018 21:11

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

mcgeezer 13 August 2018 21:21

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.

https://youtu.be/EmRAbpdY1_o

Retro-Nerd 13 August 2018 22:20

According to MAME info:

VIDEO:
256 x 224 (H) 59.185606 Hz

roondar 13 August 2018 22:44

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 13 August 2018 22:47

Quote:

Originally Posted by roondar (Post 1260890)
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 16 August 2018 19:38

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 16 August 2018 20:33

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 16 August 2018 20:48

Quote:

Originally Posted by chb (Post 1261591)
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 17 August 2018 01:53

Will you animate the river fall ??

AmigaHope 17 August 2018 03:05

Quote:

Originally Posted by mcgeezer (Post 1260894)
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 17 August 2018 07:23

Quote:

Originally Posted by turrican3 (Post 1261686)
Will you animate the river fall ??

Yep.

DamienD 17 August 2018 11:13

Quote:

Originally Posted by turrican3 (Post 1261686)
Will you animate the river fall ??

Quote:

Originally Posted by mcgeezer (Post 1261704)
Yep.

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

mcgeezer 17 August 2018 12:55

Quote:

Originally Posted by DamienD (Post 1261757)
...and the lava in the section below the ground? :p

It wouldnt be Rygar without it!

mcgeezer 18 August 2018 21:54

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.

https://www.imageupload.co.uk/images...pain1243f2.jpg

https://www.imageupload.co.uk/images...olourpain2.jpg

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 18 August 2018 22:23

I wish you luck !

mcgeezer 18 August 2018 23:02

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.

https://youtu.be/xYn9wgA6YfI

It will be better.

alpine9000 19 August 2018 00:24

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 19 August 2018 02:11

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 19 August 2018 09:12

Quote:

Originally Posted by alpine9000 (Post 1262264)
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.

Quote:

Originally Posted by buzzybee (Post 1262284)
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.


All times are GMT +2. The time now is 02:42.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.

Page generated in 0.09491 seconds with 11 queries