On AMOS, art vs performance, and crappy conversions

[Eleas]

I don't know if the subject has been raised before, so I think I should be clear before I start: this is speculation, not a call to action. I'm asking what would be possible, not what the community should do.

Anyway, AMOS. Other than lack of AGA support, music bugs and some scrolling issues, and ignoring the sometimes significant overhead, AMOS is basically capable of everything the Amiga can do. Of course, it's got its own drawbacks. Even compiled AMOS is limited in ways. For one, it falls well short of Asm performance. Of course, for all intents and purposes, a lot of classic titles seemed no better.

I mean, we've all seen some truly awful conversions and even original games. Even otherwise solidly designed titles were within the Amiga envelope but didn't truly push the machine. It got me thinking. Surely some of those could have been written in AMOS, and even in some cases improved upon.

So that's my question: what Amiga titles do you believe a skilled coder could have realized in AMOS, to equal or superior effect?


Note: I considered putting this in the AMOS corner of the forum. The reason I didn't do so is because it's not so much an AMOS question as a comparison between languages and techniques. If there are objections, please let me know and I'll ask a mod to move the thread.

[ajk]

Well, the primary limitation of AMOS is the speed. So it can't really compete with any decent platformer or shooter type game. But with other genres, like adventure, strategy or puzzle games speed is not as important so AMOS would do alright.

It will likely take more resources (larger executable, more RAM needed) to achieve the same results, though. I don't see how an AMOS version could ever be superior to a C or assembly program in a technical sense, unless the original already leaves a lot to be desired.

[Eleas]

Originally Posted by ajk

Well, the primary limitation of AMOS is the speed. So it can't really compete with any decent platformer or shooter type game. But with other genres, like adventure, strategy or puzzle games speed is not as important so AMOS would do alright.

It will likely take more resources (larger executable, more RAM needed) to achieve the same results, though. I don't see how an AMOS version could ever be superior to a C or assembly program in a technical sense, unless the original already leaves a lot to be desired.

Yeah, the RAM and the exe size I could buy. I do wonder if the custom chips might not give some boost that a lesser coder might not have managed in pure CPU-based Asm, though. Consider Rolling Thunder, Torvak the Warrior or even (if you want to be mean about it) Teenage Mutant Hero Turtles. Or, for a more provocative example, any of the later Sierra conversions (I mean those that bring an 020-equipped Amiga to a stuttering halt).

In the case of such games, would a decent AMOS coder really make the situation worse?


(I know Sierra titles count among the other genres you spoke of, so I don't disagree with you. But man, I just really, really hate how they did those conversions.)

[ajk]

There are definitely lots of games which are so poorly made to begin with, that a skilled re-make with AMOS could improve them But there may have been reasons other than pure coder incompetence that lead to such poor results; usually something to do with budget, schedule or having to aim for the lowest common denominator among many platforms when porting the game.

[Eleas]

That's kind of what I'm driving at, I guess: the good old "worse is better" argument. One wonders if, in the case of all these shitty conversions, something like AMOS (which I know didn't exist for most of that time, natch) wouldn't have been the better choice.

My reasoning is kind of this: if you have to do a game in like a month, and your art assets are limited at best, and you have to aim for the lowest common denominator... I actually think AMOS (or Blitz, possibly, I'm not shilling for any specific platform) could start to look more attractive, not less. After all, under these packages, getting something graphical and testable to run without crashing is literally a work of ten minutes, and even if it's inefficient, it's not as if you you would have had the time to push the envelope anyway.

Not sure if it would help in the "lowest common denominator" situation, now that I think about it. But still.