English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Language

 
 
Thread Tools
Old 06 March 2019, 09:47   #1
Eleas
Registered User

 
Join Date: Feb 2019
Location: Malmö
Posts: 7
On AMOS, art vs performance, and crappy conversions

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.

Last edited by Eleas; 06 March 2019 at 09:52.
Eleas is offline  
Old 06 March 2019, 09:55   #2
ajk
Registered User
ajk's Avatar
 
Join Date: May 2010
Location: Helsinki, Finland
Posts: 1,286
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.
ajk is offline  
Old 06 March 2019, 10:21   #3
Eleas
Registered User

 
Join Date: Feb 2019
Location: Malmö
Posts: 7
Quote:
Originally Posted by ajk View Post
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.)

Last edited by Eleas; 06 March 2019 at 10:47.
Eleas is offline  
Old 06 March 2019, 11:23   #4
ajk
Registered User
ajk's Avatar
 
Join Date: May 2010
Location: Helsinki, Finland
Posts: 1,286
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.
ajk is offline  
Old 09 March 2019, 21:01   #5
Eleas
Registered User

 
Join Date: Feb 2019
Location: Malmö
Posts: 7
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.
Eleas is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
crappy direct X in winuae 2.30? trydowave support.WinUAE 1 06 January 2011 19:30
Need a little help with my own crappy frontend ! kirk Amiga scene 2 01 September 2009 02:24
Your favourite crappy games Predseda Retrogaming General Discussion 37 24 March 2009 09:55
Crappy Noise Ebster support.WinUAE 2 13 February 2006 23:23
Crappy CyberVision64 ? astuermer support.Hardware 4 17 October 2005 16:43

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 06:50.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.06235 seconds with 13 queries