Arcade / Console --> Amiga conversion discussions

[mcgeezer]

Originally Posted by AnimaInCorpore

This makes no sense at all.

Makes perfect sense to me, if you elaborate perhaps i can too.

[AnimaInCorpore]

Originally Posted by mcgeezer

Makes perfect sense to me, if you elaborate perhaps i can too.

So you have experience in programming the Atari ST?

[mcgeezer]

Originally Posted by AnimaInCorpore

So you have experience in programming the Atari ST?

Yes, programmed it when i was around 15 or 16 before i got an Amiga.
About 25 years ago - long time.

[AnimaInCorpore]

Originally Posted by mcgeezer

Yes, programmed it when i was around 15 or 16 before i got an Amiga.
About 25 years ago - long time.

Ah ok and you programmed the GLUE/MMU chips to the metal? Great, just give me some hints about the problems with it.

[mcgeezer]

Well i’ll put it this way. I recall creating copper bars much easier on the amiga using the copper. I think on the st there were 4 timers in the mfp68901 ( i think that was the chip ) which you had to manipulate (timer b iirc) to get copper bars going.

Also take the video register, on the st u could only set the video registers to a 256 byte boundary and no smooth scrolling at all - different atory on the amiga.

[ImmortalA1000]

Originally Posted by mcgeezer

You're comparing Apples with Oranges.

At the time the ST was the biggest rival to the Amiga as lots of games were coded on the ST first because it was more established as a games machine given it had the luxury of more time on the shelves.

When the Amiga got traction software houses just did the ports of ST games cos they could get them out of the way in a matter of weeks, in reality all they had to deal with was the bitplane, sound, input and floppy differences - everything else was pretty much the same. The slightly faster CPU in the ST was probably negligible and perhaps is the reason that the odd port is more shit on the Amiga than it was on the ST.

To say "everything else was pretty much the same" so casually means you have no idea about writing games on custom silicon rich systems or multiprocessing environments in general. The Amiga custom chips have a certain amount of CPU independent autonomy to achieve their specific A/V tasks, unlike things like the C64 or Megadrive.

In many cases the game engine 68k machine code would be 100% different from the highest to the lowest level of program abstraction.

THIS is why 95% of Amiga games are technically only suitable for the bin, to program an Amiga game the core routines have to be designed from the ground up to perfectly balance and synchronise the independent operations of Copper, Blitter and DACs via DMA meshed perfectly in the chipset/CPU alternating cycle and clock doubled memory bus. The scribbles on the back of a piece of paper stage of design is fundamentally different between the two, let alone the later stages.

The games that do this on the Amiga have to be totally re-written from scratch on the ST. THAT is the correct way it should have been done, and the fact it wasn't done like that let alone with enough coding/video/audio talent makes it worse in many cases. Piracy on the Amiga was a major problem, a problem the software houses created by releasing insulting products AFTER the technically stunning 1986 arcade conversion of Marble Madness on the Amiga. Shadow of the beast runs just fine on a 1985 Amiga 1000 with just 512k, there was no excuses.

Anyone writing arcade conversions more complex than Marble Madness in C were also not to be encouraged, the arcade machine in this case however was also coded in C and that's what they did, they rewrote the C code for the Atari custom chip libraries to work with the Amiga custom chip specific C libraries. This clearly can only work if the source machine has similar levels of a/v custom assistance and the original game engine is compiled C code. It can NEVER work with dual development between an Amiga and a glorified Amstrad CPC (which is what the ST is, a 16bit Amstrad CPC)

They were also charging 25% more for the games and using incorrect aspect ratio 320x200 graphics from the ST release on a PAL Amiga screen displaying 320x200 instead of 320x256 which is like watching a 4:3 movie in forced 16:9 mode. Of course this was also done due to greed, not having to do ANY extra coding to sell their crap games to the NTSC region Amiga owners.

[ImmortalA1000]

Originally Posted by ImmortalA1000

To say "everything else was pretty much the same" so casually means you have no idea about writing games on custom silicon rich systems or multiprocessing environments in general. The Amiga custom chips have a certain amount of CPU independent autonomy to achieve their specific A/V tasks, unlike things like the C64 or Megadrive.

In many cases the game engine 68k machine code would be 100% different from the highest to the lowest level of program abstraction.

THIS is why 95% of Amiga games are technically only suitable for the bin, to program an Amiga game the core routines have to be designed from the ground up to perfectly balance and synchronise the independent operations of Copper, Blitter and DACs via DMA meshed perfectly in the chipset/CPU alternating cycle and clock doubled memory bus. The scribbles on the back of a piece of paper stage of design is fundamentally different between the two, let alone the later stages.

The games that do this on the Amiga have to be totally re-written from scratch on the ST. THAT is the correct way it should have been done, and the fact it wasn't done like that let alone with enough coding/video/audio talent makes it worse in many cases. Piracy on the Amiga was a major problem, a problem the software houses created by releasing insulting products AFTER the technically stunning 1986 arcade conversion of Marble Madness on the Amiga. Shadow of the beast runs just fine on a 1985 Amiga 1000 with just 512k, there was no excuses.

Anyone writing arcade conversions more complex than Marble Madness in C were also not to be encouraged, the arcade machine in this case however was also coded in C and that's what they did, they rewrote the C code for the Atari custom chip libraries to work with the Amiga custom chip specific C libraries. This clearly can only work if the source machine has similar levels of a/v custom assistance and the original game engine is compiled C code. It can NEVER work with dual development between an Amiga and a glorified Amstrad CPC (which is what the ST is, a 16bit Amstrad CPC)

They were also charging 25% more for the games and using incorrect aspect ratio 320x200 graphics from the ST release on a PAL Amiga screen displaying 320x200 instead of 320x256 which is like watching a 4:3 movie in forced 16:9 mode. Of course this was also done due to greed, not having to do ANY extra coding to sell their crap games to the NTSC region Amiga owners.

In fact Chase HQ or Karnov on the ZX Spectrum and Commodore 64 is a classic example of why you shouldn't share core game engine design let alone code. The C64 release of Chase HQ vs Spectrum version is basically what you describe by tacking on some shit game engine source code from the ST and get the blitter and Portia/Paula chip to do something now and then with a nicer tune....yes that 8 bit game on those two radically different systems perfectly highlights why the C64 had a better time of it....no one was thick enough usually to suggest joint game engine development. And before you say the ZX had a Z80 and C64 a 6510....well the assembling to machine code bit is done on the fly or with trivial editing via the dev systems big companies used for cross compiling into machines so that was not a barrier, the barrier was if they did it this way you suggest all the time for the C64 there would not be many sales for them. One bad game and hardly any proper games reviews before ZZAP64 meant a company had to try to use the features of the C64 as best it could or the consumer would just ignore ALL their releases.

[idrougge]

Why are you quoting yourself, man?

[mcgeezer]

Originally Posted by ImmortalA1000

To say "everything else was pretty much the same" so casually means you have no idea about writing games on custom silicon rich systems or multiprocessing environments in general.

Yep, not a clue. I don't even know the difference between a bit and a bite.

[nobody]

Originally Posted by ImmortalA1000

In fact Chase HQ or Karnov on the ZX Spectrum and Commodore 64 is a classic example of why you shouldn't share core game engine design let alone code. The C64 release of Chase HQ vs Spectrum version is basically what you describe by tacking on some shit game engine source code from the ST and get the blitter and Portia/Paula chip to do something now and then with a nicer tune....yes that 8 bit game on those two radically different systems perfectly highlights why the C64 had a better time of it....no one was thick enough usually to suggest joint game engine development. And before you say the ZX had a Z80 and C64 a 6510....well the assembling to machine code bit is done on the fly or with trivial editing via the dev systems big companies used for cross compiling into machines so that was not a barrier, the barrier was if they did it this way you suggest all the time for the C64 there would not be many sales for them. One bad game and hardly any proper games reviews before ZZAP64 meant a company had to try to use the features of the C64 as best it could or the consumer would just ignore ALL their releases.

You are just assuming things, like it would be trivial to compile machine code for different machines with minor editing without taking into account the type of game, what is needed to get going and if the system is suitable for that game. Then another assumption that if one game has a crap review the consumer won't buy another product from the same developer.

[zero]

Conversions in general were an issue for the Amiga, because the hardware wasn't suited to some things but did others very well. Games designed for the Amiga took advantage of its strengths, but ports often needed stuff that the Amiga struggled with.

A great example of this is Robocop. The Amiga port is based on the Atari ST one. It makes dumb decisions like having a border around the screen, which means it can't use the Amiga's hardware scrolling support. It could easily have been so much better, but the publisher just wanted a straight ST port to cash in on the movie.

[touko]

Originally Posted by zero

The 68000 is really limited by the large number of cycles that instructions take. It makes sense for a workstation CPU to have fairly complex instructions and highly orthogonal instruction set that was good for the C compilers of the day, but for games...

For games having more instructions per second is more important. I've said it before but the 8 bit 6502 derivative in the PC Engine, running at 7MHz, is a much better fit for assembler code and games that just need to move sprites around and implement some game logic.

The best way I can think of to offset this on the Amiga is to take advantage of its relatively large RAM. You can pre-compute things like movement patterns, use triple buffering and generally trade RAM for CPU cycles wherever possible.

I agree, you're entirely right .

[ross]

Originally Posted by zero

A great example of this is Robocop. The Amiga port is based on the Atari ST one. It makes dumb decisions like having a border around the screen, which means it can't use the Amiga's hardware scrolling support.

Well, actually you can
Even if for some dumb reason programmers needed the same playfield area, they could use an edge made with sprites and use the hardware scroll..

[zero]

Originally Posted by ross

Well, actually you can
Even if for some dumb reason programmers needed the same playfield area, they could use an edge made with sprites and use the hardware scroll..

True, they could... But they didn't.

I actually really like that game for some reason, probably nostalgia.

[nobody]

Lots of games look crap now but you could have some fun back then. I guess they took the spectrum level layout and added borders around on the ST. The choice of colors is too 8bit and mostly simple graphics without much detail even though the coin op existed and had a reference.

[zero]

I think because it was harder to get games back then we were more willing to put effort into enjoying them. Once you can download every game ever you have little tolerance for crap and just move on, but when you had to get a cracked copy off your cousin or save up your cash and pay it was different.

Robocop has some good elements. The music, while using crappy instruments and only two channels, was kinda catchy. The speech was sorta good for the time too. The gameplay was okay, and it wasn't even too buggy. The only major one I remember is that if you punch barrels from the right they fly off in the wrong direction.

The graphics were typical early 16 bit era, and in some ways charming. I love the way they drop French baguettes on you in the junkyard level. Maybe they are supposed to be girders but they look like bread.

Even the performance, while not great, is at least consistent. Even when lots of sprites, or large sprites like ED-209 come on the screen it doesn't slow down. It's slow, but consistently slow.

[Galahad/FLT]

Originally Posted by AnimaInCorpore

The Atari ST didn't do major damage but minor at most. Damage was done by the limitations of the Amiga system itself. More than 30 years ahead we have no proof of a different view since the Amiga homebrew community wasn't able to deliver like others did on "lower spec" systems.

I'm sorry, but you're just factually wrong on this.

It has ZERO to do with the Amigas "limitations", and more to do with the ST limitations and the programmers writing for those limitations.

Developers had limited time to get a conversion done and out the door, much like movie studios set in advance the release dates for sequels in established franchises, the software companies did the same. They wanted X game on X systems done by X date because all the advertising is telling everyone that X game is coming on that date.

Now unless you're Thalion software (aka demo coders) who seemed to be the only guys that understand how to get the ST to perform miracles, you're just going to be churning out whatever you can that will pass muster on the ST.

Scrolling window too small? Its as big as previous games.
Only 16 colours? We got away with it last time.
Scrolling a bit jerky? Its the ST, no-one is expecting smooth.

And because of this lazy attitude to programming on the ST, developers simply don't bother to improve their craft on the ST, which also happens to invariably mean that they are the least capable programmers to be given the Amiga version to do.

Scrolling window too small? Haven't got time to rehaul the entire game.
Only 16 colours? Artist is busy on the next game and it would be a pain.
Scrolling a bit jerky? The design around the ST limitations would mean a lot of extra work when theres a deadline.

Quite clearly if David Broadhurst didn't have to consider the Atari ST in his thoughts, then it goes that his Amiga work would either of started out a whole lot better or at least would have accelerated quicker.

Imagine that Ghouls n Ghosts was done with the same technical prowess as Assassin or Dojo Dan? It still wouldn't have been quite up there with the Megadrive version, but it would have been a hell of a lot closer.

Its not that the Amiga couldn't do the game justice, its that the developers couldn't do it justice because of having to have development consideration for the Atari ST as well.

[zero]

Galahad is right, the gulf between games designed for the Amiga and those that are ports is huge.

Having said that, not all ports are terrible. Midnight Resistance was a pretty good arcade port. The original arcade system has a lot of slow-down anyway, and they did a good job keeping the port running at a more consistent frame rate. All the levels and enemies are there, it plays really well...

The music is probably the weakest aspect. Great tunes, and the conversions aren't bad or anything, but not the best on the Amiga either. Since most of the music is in-game they were limited by the available channels and RAM though, rather than lack of skill.

[roondar]

Indeed, there are plenty of games from back in the 90's that show that the Amiga could do a whole lot better than the lets-not-use-the-hardware ports we almost always got. There's also a bunch of dual format games (ST/Amiga) made after developers decided to use the hardware and they usually have much better results on the Amiga.

There are some nicer ports though, I've always liked Dragon Breed, Pacmania and Rod Land for example. They run smooth, look good and play well.

[dlfrsilver]

Originally Posted by roondar

Indeed, there are plenty of games from back in the 90's that show that the Amiga could do a whole lot better than the lets-not-use-the-hardware ports we almost always got. There's also a bunch of dual format games (ST/Amiga) made after developers decided to use the hardware and they usually have much better results on the Amiga.

There are some nicer ports though, I've always liked Dragon Breed, Pacmania and Rod Land for example. They run smooth, look good and play well.

Dragon Breed is an ST port, while Pacmania and Rod-land were both amiga first, and made with the Amiga strength in mind.