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 23 August 2018 13:49

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.

https://youtu.be/uiBChqNZtho

ross 23 August 2018 14:31

Quote:

Originally Posted by mcgeezer (Post 1263559)
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!
:great

mcgeezer 23 August 2018 23:15

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.

https://youtu.be/C9eg8xmtFOk

DamienD 23 August 2018 23:25

Looking good my friend :great

vulture 25 August 2018 17:32

Great work so far!

ReadOnlyCat 26 August 2018 22:21

Quote:

Originally Posted by mcgeezer (Post 1258209)
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.

Quote:

Originally Posted by Retro-Nerd (Post 1258217)
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.

Quote:

Originally Posted by jotd (Post 1258223)
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. ;)

Quote:

Originally Posted by jotd (Post 1258296)
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 26 August 2018 22:42

Quote:

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 26 August 2018 23:15

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 27 August 2018 00:02

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.

Steril707 29 August 2018 19:15

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

Steril707 31 August 2018 09:32

Quote:

Originally Posted by chb (Post 1259189)
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 31 August 2018 11:02

Quote:

Originally Posted by Steril707 (Post 1265572)
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 :)

Steril707 31 August 2018 11:54

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 31 August 2018 12:10

Quote:

Originally Posted by Steril707 (Post 1265610)
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 31 August 2018 13:24

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

Steril707 31 August 2018 13:46

Quote:

Originally Posted by mcgeezer (Post 1265631)
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 31 August 2018 13:49

Method 2 is :banghead:spin:banghead

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

roondar 31 August 2018 13:53

Quote:

Originally Posted by ross (Post 1265617)
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 :p)

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

--
Quote:

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 :D

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 31 August 2018 13:59

Quote:

Originally Posted by roondar (Post 1265640)
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 31 August 2018 14:03

Quote:

Originally Posted by Steril707 (Post 1265637)
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


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.08137 seconds with 11 queries