An example of AGA sprites in OutRun

[rothers]

Originally Posted by ImmortalA1000

There was an improved version of Megadrive Mortal Kombat recently, a port of that to Amiga 1200 would be nice

I saw that the other day, it's excellent. I don't blame the original programmers, they will have been restricted by cartridge space and deadlines, but we all knew the MD was capable of a better port.

[jotd]

if the source code is available, that may interest me.

[rothers]

It actually adds to the MD version a lot of stuff the Amiga version already has, such as the voice samples, the Amiga version still wins on having the character intro animations (although I guess they might plan to add those).

Then they have added the background animations which the Amiga does not have, and fixed up the player graphics and the background graphics.

Lots of little tweaks - I assume they have just hacked the code of the original but I could be wrong, it might include heavy re-writes.

[jotd]

the 2 things that would be cool NOT to rewrite are

- the animations
- the A.I.

[rothers]

Here is the new MD version:

[ Show youtube player ]

[sandruzzo]

MK2 on Amiga lack of better copper usages to add more color to background, nonetheless is was a good port

[jotd]

the base MD version was already very good. Amiga ECS version is really good & playable but colors are globally rather terrible.

even without the source code it's not impossible to enhance a game. The logic doesn't change, "just" the assets and the number of bitplanes & palette (you have to understand how and where the bitmaps are stored), ... no need to fully understand the game logic to enhance that part. CFou! has already created AGA versions of EOB 1/2 that way.

I did that with Supercars 2. I had the source and that was helpful, but I didn't change or even try to understand the logic of the game.

Ask to add new weapons, new characters, etc... that's a different story!

Originally Posted by sandruzzo

MK2 on Amiga lack of better copper usages to add more color to background, nonetheless is was a good port

IMHO it wouldn't have helped much. Each background would have to be specially processed with dynamic color changes, but those colors were probably also used for characters... What would have helped would have been AGA, 16 color dual playfield & 64-bit wide sprites.

[ImmortalA1000]

Originally Posted by jotd

the base MD version was already very good. Amiga ECS version is really good & playable but colors are globally rather terrible.

even without the source code it's not impossible to enhance a game. The logic doesn't change, "just" the assets and the number of bitplanes & palette (you have to understand how and where the bitmaps are stored), ... no need to fully understand the game logic to enhance that part. CFou! has already created AGA versions of EOB 1/2 that way.

I did that with Supercars 2. I had the source and that was helpful, but I didn't change or even try to understand the logic of the game.

Ask to add new weapons, new characters, etc... that's a different story!



IMHO it wouldn't have helped much. Each background would have to be specially processed with dynamic color changes, but those colors were probably also used for characters... What would have helped would have been AGA, 16 color dual playfield & 64-bit wide sprites.

SF2 Champion Edition is top of the class on the Megadrive I think, I'm not sure even the A1200 could match that game on maximum speed settings no matter what you did or how expert a coder is writing it, never seen a PAL SNES beat 'em up go that fast even with the huge SNES hardware sprites but maybe with a DSP to circumvent the horrible CPU it uses.....

Mortal Kombat 1 and 2 is OK on the Sega but really you wanted the much nicer SNES ports anyway. Was nice the MD got an upgrade to push it's original conversion to the machine's limits and closer to the SNES.

To be honest none of the big rich software houses gave a crap about anything after A500, the CDTV solved a lot of problems (no cheap hard drive option replaced with a huge game loaded from CD and only 4 8bit sound channels supplemented with loads of CDDA data for ambient background music/sound and speech for characters). I was completely underwhelmed with everything that came out on the A1200. As horrible as it is to say I wouldn't have missed out on bugger all by not getting one for £399.99 in Oct 1992. It's not like there's anything better on it than OCS Beast 1, Lotus II, Turrican 3, Lionheat, Sword of Sodan, Battle Squadron, Unreal (3D bits only, 2bit is naff), Goal/Speedball II, etc etc and Cinemaware only did 32 colour graphics. Worse still those Accolade games are all frame locked (Test Drive 1+2 and Grandprix Circuits). A1200 is a great computer but AGA is not a great gaming platform considering the rival's from NEC and Sega are older technology. We needed a Beast 1 or Lotus II style game changer for A1200, it never happened. Maybe if Cinemaware hadn't gone bankrupt making that PC Engine CD cringefest.

[jotd]

A huge problem on the A1200 was that you had more memory, more bitplanes, but the same blitter speed to copy more data... If the AGA blitter had been faster (what where they thinking...) and with 2 or 4 more audio channels, it could have been a game changer.

Sega/SNES are 2D specialized game consoles with a dedicated tile engine that the amiga has to emulate with the blitter.

[rothers]

Honestly, never mind the MD hardware, if they had even put the Sega Master System sprite hardware (64+ 16 colour sprites) in the A500+ it would have vastly improved things.

[roondar]

Originally Posted by rothers

Honestly, never mind the MD hardware, if they had even put the Sega Master System sprite hardware (64+ 16 colour sprites) in the A500+ it would have vastly improved things.

The Master System Sprites can't actually cover as many pixels as the Amiga Sprites can, so I'm not too sure about that.

Sure, you get more individual Sprites without multiplexing, but you're still limited to only 64 pixels on a line, where the Amiga can do up to 128 (64 in 16 colour mode and you can mix and match and end up in between). Worse, the Master System Sprites also have height restrictions, which Amiga Sprites don't have. Amiga Sprites also offer hardware based vertical multiplexing, so they're not limited to 8 Sprites per screen, just 8 per scanline. Several games use this to great effect.

In general, the only real advantage the Master System has is the number of individual Sprites per line in 16 colour mode, but this is a very minor gain compared the Amiga's other Sprite advantages. In short: don't underestimate Amiga OCS HW Sprites. Yes, they're not nearly as good/useful as the 16 bit console HW Sprites, but they're clearly better than what the 8 bit consoles (excluding the PC-Engine) offer.

[ImmortalA1000]

Amiga sprites always had a problem with colours, on OCS you have to share the palette with the bitmap screen (very rare) and they are not wide enough. On AGA you can have wide and screen high sized sprites and the 8 bitplane chipset means the shared bitmap/sprite palette method is fine but you are limited to just 16 colours per scanline for all of them. This is not up to PC Engine standards. Sprites are lightning fast and it's difficult to write bad code for powerful sprite hardware, blitter coding on the other hand......

If they had only expanded it to 4x 16 colour sprite palettes using the last 64 colours of the bitmap screen that would be fine for many situations. Amiga sprites were always just a bonus, never a main feature.

I thought the AGA blitter could do twice as much raw blitting in mb/s than OCS on A500/1000/2000 OCS machines. Perhaps it is just 32bit wide data processing per DMA cycle at the same speed?

[rothers]

Originally Posted by roondar

The Master System Sprites can't actually cover as many pixels as the Amiga Sprites can, so I'm not too sure about that.

Sure, you get more individual Sprites without multiplexing, but you're still limited to only 64 pixels on a line, where the Amiga can do up to 128 (64 in 16 colour mode and you can mix and match and end up in between). Worse, the Master System Sprites also have height restrictions, which Amiga Sprites don't have. Amiga Sprites also offer hardware based vertical multiplexing, so they're not limited to 8 Sprites per screen, just 8 per scanline. Several games use this to great effect.

In general, the only real advantage the Master System has is the number of individual Sprites per line in 16 colour mode, but this is a very minor gain compared the Amiga's other Sprite advantages. In short: don't underestimate Amiga OCS HW Sprites. Yes, they're not nearly as good/useful as the 16 bit console HW Sprites, but they're clearly better than what the 8 bit consoles (excluding the PC-Engine) offer.

Erm... you do you man.

I'd take 64 sixteen colour sprites over 8 four(!) colour sprites any day of the week.

64 sixteen colour sprites would have revolutionised the Amiga scene.

[ImmortalA1000]

To be honest Amiga OCS sprites are a bit of weird fusion between Atari 400/800 player missile size idea and Famicom sprite colour resolution.

They were just a bonus freebie in there. It's odd because most computers with sprites have them as the main feature, you use sprites a lot on the C64 and some character graphics for bullets. On the Amiga you use the bitmap screen via blitter for the heavy lifting and possibly the sprites for bullets.

AGA sprites though really should have had 4x 16 colour palettes, a bit of a half arsed job that, if done well, could have made all the difference as four 64x256 pixel sprites in their own 16 colour palette would have been very useful.

On the C65 they never improved the sprites of VIC-II either, they just stuck a blitter into the mix!

[kamelito]

Originally Posted by jotd

if the source code is available, that may interest me.

I don't think it is.

you've this though :

https://archive.org/details/Various-...ode-Collection

[Havie]

Originally Posted by kamelito

I don't think it is.

you've this though :

https://archive.org/details/Various-...ode-Collection

Now that would be a port and a half!

[ImmortalA1000]

Very rough mockup of what I'm trying to do, limited by the video editor but you get the idea. 1 bob 4 colours, 64x32 pixels drawn in 15 positions x6 with a 3 frame gap in overlap step on upper playfield. 25fps. Car is an AGA sprite as before, 15 colours, blue is background placeholder for lower playfield

[ Show youtube player ]

[CFou!]

Originally Posted by jotd

even without the source code it's not impossible to enhance a game. The logic doesn't change, "just" the assets and the number of bitplanes & palette (you have to understand how and where the bitmaps are stored), ... no need to fully understand the game logic to enhance that part. CFou! has already created AGA versions of EOB 1/2 that way.
.

For EOB1&2AGA, I generated the game engine source codes using ReSource4.
Then I lazily modifyed memory management and display code without optimizing the code...

[jotd]

the hardest part is to identify code/data sections because data seen as Bcc instructions change values when reassembled if you add some code, even if you don't use any asm optimizer.

[CFou!]

Originally Posted by jotd

the hardest part is to identify code/data sections because data seen as Bcc instructions change values when reassembled if you add some code, even if you don't use any asm optimizer.

indeed, well isolated the DATA was boring and long to do for both EOB.

main EOB2 code was also boring to resourse due to the overlay hunk structure.
I had not found an assembler to compile the executable in overlay at once
then I have to compile 5 temporary executables that I assemble into one by modifying the structure of the Hunks with a homemade tool...

PS:
Jeff, if you are interested to I could send you the sources and the compilation scripts.

But for the moment I don't release them officially because one day I would like to take the time to clean them up a bit or to optimize code (especially the automap code) or even to code intro/outro 100% in ASM with a good scrolling and parallax.

moreover, for the moment, the EOB2 overlay executable is generated by a WHDload slave from 5 temporary executables compiled by Barfly (practical for debugging), I would have to make a standalone tool