NeoGeo Metal Slug conversion to Amiga 500 - madman task ;-)

[sandruzzo]

@Steril707

If you need helps to do programming, I'm up to it.

[Tigerskunk]

Naah, I really don't have any intention to go on working on this.
I just could not let our Atari ST friends drive that far away with their demo. Which is still a lot better than my little thing I put together in an hour.

[sandruzzo]

You did a hell of job. Fully respectful.

[Tigerskunk]

Originally Posted by sandruzzo

You did a hell of job. Fully respectful.

Thanks, man..

[frank_b]

Originally Posted by Samurai_Crow

I guess it does! That would make it faster yet. What kind of sprites does the STE have?

Yes and it is very very fast for most GUI stuff. Area filling, window translation. Simpler operations are usually faster than the Amiga's if bits need to be preserved in the destination. Like translation of a window raster from one place to another with fringes preserved. It has an interesting indirect addressing mode which can be used to hflip or linearly scale rasters. It has full 24 bit wide addressing too. More complex operations are faster on the Amiga. The Amiga is probably 1.5-2x as fast at regular masking. The technique used in AGT gives you 1 pass masking on the ST blitter and it is very fast too. Comparable to the Amiga. It doesn't do line draw or polygon fill though. It doesn't run in parallel to the CPU. Swings and roundabouts. They're both pretty awesome blitters.

[dreadnought]

Originally Posted by Steril707

Naah, I really don't have any intention to go on working on this.

Great. I'm not doubting that you could pull off a pretty decent port, but I'd much rather see you working on quality original stuff. Hopefully it will be that First Samurai-style game you've mentioned before

[roondar]

I'm still impressed by the 1 pass masking* method on the STE Blitter (basically it completely changed things for the STE's objects Blitter drawing speed). It's a very clever way to do things. And it's always cool to see stuff like that. The STE is a nice system, for sure

*) I'm assuming this is a variation of the line-by-line-based blitting method you talked about at an earlier date?

[frank_b]

Originally Posted by roondar

I'm still impressed by the 1 pass masking* method on the STE Blitter (basically it completely changed things for the STE's objects Blitter drawing speed). It's a very clever way to do things. And it's always cool to see stuff like that. The STE is a nice system, for sure

*) I'm assuming this is a variation of the line-by-line-based blitting method you talked about at an earlier date?

Yes. It has 3 mask registers which preserve bits in the destination rather than 2 for masking off the input on the first and last words on a line. It is used for the first, last and middle lines of a raster. The trick is to blit column by column a line at a time. The downside is the mask needs to be preshifted which takes up memory. Doug's engine looks like it analyses the sprite and can blit arbitrary line lengths in between transparent parts too. It's copy speed in the middle at 8 cpu cycles per word and 12 cycles for the fringes. On certain sizes where the middle is a larger ratio than the sides, a regular window blit of rectangular area can beat the Amiga with all its DMA switched off. It's mind boggling very few games used it on the ST. On its own it isn't enough though. It really needs to be combined with hardware scrolling.

[roondar]

Well, technically I suppose you can use a somewhat similar trick on the Amiga: blit the transparent surrounding using cookiecut blit(s) and blit the centre using copy blits (though the order matters here - you'd have to blit the centre section first and the cookie-cut section second using a pristine background copy as source). Obviously the centre then would not have any transparency. Actually been meaning to try something like that.

But that's besides the point and just my coder heart talking. It's quite impressive, for sure

[frank_b]

Originally Posted by roondar

Well, technically I suppose you can use a somewhat similar trick on the Amiga: blit the transparent surrounding using cookiecut blit(s) and blit the centre using copy blits (though the order matters here - you'd have to blit the centre section first and the cookie-cut section second using a pristine background copy as source). Obviously the centre then would not have any transparency. Actually been meaning to try something like that.

But that's besides the point and just my coder heart talking. It's quite impressive, for sure

The second you shift you need to preserve bits in the destination if the source is aligned You could do line by line, use a constant for the mask and achieve something similar with first and last word masks. It would still take 8 cpu cycles with an idle cycle free for the CPU. Line by line overhead with the CPU would cancel it out. You could do fast vertical translation for scrolling though. Do the fringes as a separate blit. The Amiga one is fast enough for brute force masking anyway.

[roondar]

Originally Posted by frank_b

The second you shift you need to preserve bits in the destination if the source is aligned You could do line by line, use a constant for the mask and achieve something similar with first and last word masks. It would still take 8 cpu cycles with an idle cycle free for the CPU. Line by line overhead with the CPU would cancel it out. You could do fast vertical translation for scrolling though. Do the fringes as a separate blit. The Amiga one is fast enough for brute force masking anyway.

Actually, I was thinking more of just outright cutting out the background with a shifted copy blit and then blitting the now missing parts of the background back in via one or more cookie-cut blits. Anyway, it's just a random idea. Thinking about it for a second, this idea might only actually be faster for gigantic blits due to the 2-word minimum for blitting the shifted cookiecut "fringes" on the Amiga

[frank_b]

I'd just use a dual playfield display, make sure the enemies don't intersect and do a raw copy instead if they need to intersect at 16 pixel boundaries, use an OR instead and have a spare column on the source to shift into. That should mean zeroes get shifted down to the next line and you don't need to use the masks. The ST one can also optimise out the read of the RMW on the last column even with regular masking. btw AGT is open source. It could be ported to the Amiga.

[Samurai_Crow]

Originally Posted by frank_b

I'd just use a dual playfield display, make sure the enemies don't intersect and do a raw copy instead if they need to intersect at 16 pixel boundaries, use an OR instead and have a spare column on the source to shift into. That should mean zeroes get shifted down to the next line and you don't need to use the masks. The ST one can also optimise out the read of the RMW on the last column even with regular masking. btw AGT is open source. It could be ported to the Amiga.

On the A500, dual-playfield has a total of 7 foreground colors. You'd need AGA to get 15 foreground colors and huge sprites. Which makes this technique a bad idea.

[roondar]

Originally Posted by frank_b

I'd just use a dual playfield display, make sure the enemies don't intersect and do a raw copy instead

Funny you should say that... I may have written an article about that idea at one time http://powerprograms.nl/amiga/dpl-fastbobs.html

if they need to intersect at 16 pixel boundaries, use an OR instead and have a spare column on the source to shift into. That should mean zeroes get shifted down to the next line and you don't need to use the masks. The ST one can also optimise out the read of the RMW on the last column even with regular masking. btw AGT is open source. It could be ported to the Amiga.

AGT does sound quite interesting. I'm not too sure all of it is applicable to the Amiga environment equally, but some of the ideas surely would be quite interesting to experiment with.

[frank_b]

Originally Posted by Samurai_Crow

On the A500, dual-playfield has a total of 7 foreground colors. You'd need AGA to get 15 foreground colors and huge sprites. Which makes this technique a bad idea.

Yes I know. It would be 7 over 8 in that case. You could also just make sure enemies don't intersect with any tiles for the same effect and do it in whatever mode you wish. Think of a platformer where the meanies only walk on ledges.
Cheating but would work for some games.

[Samurai_Crow]

Originally Posted by frank_b

Yes I know. It would be 7 over 8 in that case. You could also just make sure enemies don't intersect with any tiles for the same effect and do it in whatever mode you wish. Think of a platformer where the meanies only walk on ledges.
Cheating but would work for some games.

I get the opaque blitting technique. It's like using character maps on the C64 to fake more sprites. My objection is the shallow palette depth.

[frank_b]

Originally Posted by Samurai_Crow

I get the opaque blitting technique. It's like using character maps on the C64 to fake more sprites. My objection is the shallow palette depth.

Then do it in 32 colour mode and make sure you only ever write to a zeroed area of the screen Would work for some games and it would be really fast. Or just pre calc the sprite / background combination and use a smaller tile count.

[frank_b]

Originally Posted by roondar

Funny you should say that... I may have written an article about that idea at one time http://powerprograms.nl/amiga/dpl-fastbobs.html

Ex professional games developer like me? Missed the Amiga though. Started on the GBA.

[roondar]

Originally Posted by frank_b

Ex professional games developer like me? Missed the Amiga though. Started on the GBA.

Nope. Professional developer, but never in games.
My Amiga "coding obsession" was mostly borne out of regret: back in the day I didn't have a hardware reference manual (or a proper knowledge of 68000 assembly). But I always really wanted to know how the Amiga really works and still kind of want to make my own games one day. So I taught myself everything I could find about the Amiga and 68000 over the past few years. The article is part of that process

[sandruzzo]

@roondar

Fast blit operation works fine even on no DualPlayfield. Have some limits, but it worth implementing it