Does the AGA chipset has been fully exploited ?

[DanScott]

You could even scroll the screen vertically, and do a vertical perspective effect with it too

Now THAT would look cool for a unique Amiga fighting game, rather than trying to convert SFII

[ross]

There is however something very optimistic about the video: it relies heavily on BPLCON4 split.
Ok, simple to do vertically, as well as the horizontal and vertical multiplex of the sprites.
But how to easily couple the horizontal multiplex of the sprites with the horizontal colors split using BPLCON4?

[roondar]

Yeah, I saw that too. Asked the author about it on YouTube, he told me that the last bit with BPLCON4 rectangular areas was a kind of "prototype" made on modern hardware, some things were not final about that.

Anyway, he's apparently using the automatic sprite multiplexing that AGA offers, where sprites repeat after 256 pixels by themselves.

[ross]

Originally Posted by roondar

Anyway, he's apparently using the automatic sprite multiplexing that AGA offers, where sprites repeat after 256 pixels by themselves.

Does not appear that way from the video, observe how many times the clouds are replicated. With sscan2 you can have only two copies and using more sprites..

Moreover, a so close colors split for the passengers of the boat is very complicated, the copper is not so fine (and need to compete with the BPL DMA).
A way could be to 'alternating grouping' it with different colors of the palette, but that way you should reduce them considerably, or simply space out the people.

[DanScott]

It would appear that the video is just showing mainly some ideas, and not an actual Amiga AGA implementation. I fear that they WILL have some issues and have to backtrack on some things perhaps...

However they ARE thinking along the same lines as I've been thinking about a few things here and there

[roondar]

Originally Posted by ross

Does not appear that way from the video, observe how many times the clouds are replicated. With sscan2 you can have only two copies and using more sprites..

As I understood the video, he just used all 8 sprites for the clouds etc and reused them that way, but maybe I'm mistaken here.

Moreover, a so close colors split for the passengers of the boat is very complicated, the copper is not so fine (and need to compete with the BPL DMA). A way could be to grouping it and 'alternate' it with different colors of the palette, but that way you should reduce them considerably, or simply space out the people

Yeah, this is the bit that he pre-viewed on PC. I pointed out on YT that BLPCON4 changes could be delayed by up to 16 pixels due to DMA and he said that the current version is just a preview and that the end result would likely have more space between the passengers.

Anyway, it's still a very interesting result and one that shows that with lots of time and passion AGA can do very neat stuff

[ross]

Yes, I absolutely do not want to be in contrast with the attempt (quite the opposite!), the ideas are good, and as Dan says these ideas have crossed various mind.
I know AGA can do great things. But better not to overdo the expectations

[saimon69]

Originally Posted by ross

Yes, I absolutely do not want to be in contrast with the attempt (quite the opposite!), the ideas are good, and as Dan says these ideas have crossed various mind.
I know AGA can do great things. But better not to overdo the expectations

To be crazy in my opinion they could even do a decent ECS version, but will need to redo the player bobs in cel shaded style characters similarly to Shadow Fighter to have proper 8 colors... at that point, though, indeed will NOT be an arcade perfect port but rather an interesting reinterpretation...

[ Show youtube player ]

[Tigerskunk]

Originally Posted by ross

Moreover, a so close colors split for the passengers of the boat is very complicated, the copper is not so fine (and need to compete with the BPL DMA).
A way could be to 'alternating grouping' it with different colors of the palette, but that way you should reduce them considerably, or simply space out the people.

That was my observation as well.
I am not sure the copper can change so many colors in line this fast.
Also, while it's certainly possible to switch colors in line, it's a HUGE PAIN IN THE ASS while scrolling the whole scenery.

Writing that copper list dynamically each frame with palette swaps AND sprites being multiplexed as well horizontally will take some resources that he is not talking about in the video. And some crazy coding.

I experimented with this stuff a lot in my beginnings of my engine when it was still dual playfield and I was looking for ways to get more than 7 colours in the foreground, and I decided not to do it.

So, great video, but in the end it's simplifying things a bit too much too make it look more clever than it actually is.

[aros-sg]

Originally Posted by Toni Wilen

Perhaps it is possible to have almost all sprites by taking advantage of bitplane DMA overrun situation (http://eab.abime.net/showthread.php?p=1144664)

Btw, what about hires/superhires? 64 superhires pixels look like 16 lores pixels. Do all sprites work on a standard non scrolling superhires resolution?


Superhires needs to "load" 64 pixels in 4 times shorter time. Could this be abused by switching from lores to superhires to lores in each scanline?

[chb]

Originally Posted by aros-sg

Superhires needs to "load" 64 pixels in 4 times shorter time. Could this be abused by switching from lores to superhires to lores in each scanline?

No, the DMA slots for sprites are fixed, and they always load the same amount of data to the sprite registers for all sprite and display resolutions - just depending on the sprite width/fetchmode.

[ross]

Originally Posted by aros-sg

Superhires needs to "load" 64 pixels in 4 times shorter time. Could this be abused by switching from lores to superhires to lores in each scanline?

There had been a user attempt for something like this.
Also for changing FMODE during the line.
I seem to remember that the attempts had not gone so well...

[ross]

Originally Posted by chb

No, the DMA slots for sprites are fixed, and they always load the same amount of data to the sprite registers for all sprite and display resolutions - just depending on the sprite width/fetchmode.

The main idea here is only to 'anticipate' the pixels to video, a shift of 64 in shires is only 16 pixels, so even with DDFSTRT=$38 you do not have to use a big DIWSTRT.
Then switch to lores during line.
But I see it as difficult or impossible to implement for different reasons

[chb]

Originally Posted by ross

The main idea here is only to 'anticipate' the pixels to video, a shift of 64 in shires is only 16 pixels, so even with DDFSTRT=$38 you do not have to use a big DIWSTRT.
Then switch to lores during line.
But I see it as difficult or impossible to implement for different reasons

I think I understood the question wrong - I thought it was about shires sprites, but it wasn't. Thanks for pointing that out.

BTW, you were at some point investigating the possibility to compensate the 64 pix shift to the right by fiddling with the hsstrt/hsstop registers, IIRC? In theory one should be able to do that, but it might be necessary to have a higher value for hsstop than for hsstop to compensate a full 64 pixels. Did you have some success with that approach?

[ross]

Originally Posted by chb

BTW, you were at some point investigating the possibility to compensate the 64 pix shift to the right by fiddling with the hsstrt/hsstop registers, IIRC? In theory one should be able to do that, but it might be necessary to have a higher value for hsstop than for hsstop to compensate a full 64 pixels. Did you have some success with that approach?

Yes, I did it many years ago when I still had a real A1200.
I definitely have some test code.
I don't remember exactly the results and the disadvantages but surely something worked
I would need a real AGA machine..

[vulture]

There's a mention of a Mortal Kombat AGA demo by a french coder, anybody knows more about this?

[Toni Wilen]

Originally Posted by ross

Well, Toni is needed

DDFSTRT=$36 seems the right value but it fail to overrun (maybe not emulated?)
DDFSTRT=$38 works but it destroy SPR1 and SPR2 that's bad because you loose 2 16 colors sprite (you maintain 2 x 4 colors + 2 x 16 colors)
DDFSTRT=$34 is what you see in previous message (3 x 16 colors sprites + 1 x 1 color, loss 1 channel audio)

I don't think emulation is perfect yet, nothing is guaranteed This is quite special edge without any good real world test cases.

But at least check DMA debugger (v-command) to see which cycles overrun bitplane cycles use. (v <line> to see the beginning, for example v <line> 160 to see the end).

[ross]

Originally Posted by Toni Wilen

I don't think emulation is perfect yet, nothing is guaranteed This is quite special edge without any good real world test cases.

But at least check DMA debugger (v-command) to see which cycles overrun bitplane cycles use. (v <line> to see the beginning, for example v <line> 160 to see the end).

HARDDIS work in WinUAE only if coupled with a variable beam counter bit active. (example: BEAMCON0=$4020 doesn't enable it)
Is this an expected behavior?

EDIT:
An observation.. I have always assumed (but not found written confirmation) that the possible deactivation of the sprites DMA is from the value in DDFSTRT, this even if the bitplanes activated in BPLCON0 did not 'compete' with the used sprites channels (this is even more unfortunate in AGA where the fetch is blocky, so many DMA slots are possibily unused..).
This is why the DMA overrun would allow high numbered sprites to eventually work (the comparison for deactivation is not reached because DDFSTRT > of the fetch position for the sprites).
Is this right?

[redblade]

Originally Posted by vulture

There's a mention of a Mortal Kombat AGA demo by a french coder, anybody knows more about this?

Yes it is on the French Amiga site. obligement.fr (I think that is the word) under the Assembler section.

Originally Posted by saimon69

To be crazy in my opinion they could even do a decent ECS version, but will need to redo the player bobs in cel shaded style characters similarly to Shadow Fighter to have proper 8 colors... at that point, though, indeed will NOT be an arcade perfect port but rather an interesting reinterpretation...

[ Show youtube player ]

I never knew that the fighters were 8 colour sprites. It's great to see how they used the sprite for the energy bar at the top.

I really liked that game, If it was released in 93 they would have sold a lot more copies. Some good techno songs on that as well.

[kremiso]

Another randomly find that could be useful to share here.
I'm trying a longplay with Bubble & Squeak AGA atm, and i have reached the 'Neon City' set of levels, imo nice upgraded despite the standard Amiga version, expecially for the use of some changing colors effects.
Prolly those levels were lastly developed, seems a little better dedicated work;
i can't find any video on tube, i'll share some pictures here, but obviously they can't return the changing effect;
little shame also because, due the game difficulty, that environment has prolly been explored by not too much players

This is the standard Amiga longplay, and the correct level starts at 1.18.40 (Neon City part2) :
[ Show youtube player ]

This instead is the longplay of that level alone, but on Megadrive;
i must say, even more effects, but less colors than AGA
(strangely on Megadrive is called Neon City part 3) :
[ Show youtube player ]

At last, two screenshots taken from the AGA release :