terriblefire wrote: 19 Apr 2020 09:17
It looks like its struggling in places @50 Mhz and 6Mb of RAM. I dont think its even worth trying for stock.
If we're talking about a proper port to Atari, or Amiga for that matter, then I absolutely agree!
Official ports, or ports where you care about not diverging code too much from mainline ScummVM, will always struggle and I would agree it's impossible to get it running on anything but really fast machines.
This is not a fault of ScummVM. It's an incredible software and it's doing things in a very sensible way for something that needs to support a lot of very different game engines, as well as work on a lot of different platforms.
I am taking the mindset of porting a specific game (well, three specific games) to Atari and in a way similar to what we would have done at work a few console generations back if we were porting something to a vastly inferior platform compared to the baseline.
Anything that slows down is fixed no matter the cost in code-cleanliness, portability or if code diverges beyond recognition from mainline.
It becomes a clean break, and it's own thing, with no plan of merging back to main.
I picked version 0.6.0 as a start because the code is faster, but uglier, compared to the newer version. Most code not needed by my three target games were removed for speed and size reasons and some bits were changed to be more like 0.2.0 since that version is faster still.
This way there is a non-moving target in terms of code, a fixed platform, and a fixed input (ok, three, but they are very similar).
ScummVM likes to keep a fixed internal representation of graphics and sound, the different interpreters are responsible for outputting to this format, and the platform layer is responsible for converting to something the target machine understands.
The sound was a good example:
MI2/INDY4/DOTT outputs 11khz,8bit mono sound effects.
ScummVM converts everything to 22khz,16bit stereo at runtime during playback.
Platform layer converts this to something the machine understands.
So my first iteration was to make the atari platform layer, it accepts ~11khz,8bit mono.
Without any other changes this was extremely slow. It had to do this conversion at runtime:
11khz,8bit,mono -> 22khz,16bit,stereo -> 11 khz,8bit,mono (see the sillyness? :D)
With the freedom of being able to do whatever I want, and caring only for these three games, my second iteration was to "simply" make scummvm's internal representation 11khz,8bit,mono, got rid of a bunch of conversion code and we're ending up with just simply copying data instead (here is potential for further optimization to get rid of even that - as well as some mixing code)
But graphics will be the big one.
Similar to sound, it goes Game -> ScummVM common format -> Platform format
The plan is of course to rewrite the ScummVM layer to work with Atari bitplane graphics internally.
Right now, anything moving or animating is doing very costly chunky->planar conversions. As well as very costly game->scumm gfx conversion and chunky drawing in the first place.
But yeah, I wouldn't hold my breath. :)
The chance of success is still very low.
I am happy even if it ends up requiring a fast accelerator.
Even happier if works fine on stock TT.
Incredibly happy if it ends up working fine on stock Falcon.
Stock ST for Monkey2 only, possibly Indy4, is the target - working towards that puts me in a mindset of treating the code in a way that will help reach more of the above goals.
I don't see memory as a problem. 4MB has to be enough and that is what I test with when I run it on an emulator.
But yeah, I'm going to have to log memory usage to be sure.