exxos's Atari, Amiga & retro forum

Latest version available here:
http://www.happydaze.se/scummvm-lite-atari/

Mainly a performance release, and a bunch of graphics glitches fixed.

It runs slightly better than the video that was posted, and for what it is I actually consider my original performance goal for Monkey Island 2 reached.
Monkey Island 2 feels like the official Lucasarts releases did on stock 8 Mhz STs, and I am really quite happy with that :yay2:
I've only played the first island though, maybe it tanks completely later on in the game :lol:

Atlantis is slower than Monkey2 on 8 Mhz machines but playable depending on how picky you are, 90's me would probably have played it like that if it was released for the ST back in the days.
I wouldn't play Day of the Tentacle on anything less than a Mega STE (Falcon if you want to watch the intro in full framerate)


Going to revisit audio again and see if I can improve performance when playing speech. And hopefully that DMA playback on Falcon but it's a bit working in the blind since the issue is not there on the emulator, it may come down to someone else that has a Falcon having to fix it after the sources are put on Github.
Then there are other bugs to fix still of course.

Have fun, and do let me know if anything is severely broken :)

This is great, thanks very much :mrgreen:

Just a couple of notes as I've been playing about with it this morning.

It's actually faster than the A500 version, very noticeable when comparing between Hatari and WinUAE side by side. So performance is excellent! The Amiga does have better scrolling than both this conversion and the PC release as it appears to use hardware scrolling. But all animated NPC's and general Guybrush movement are sluggish on the A500.

When you release the source maybe someone will try and squeeze hardware scroll in there for the STe and Falcon :D

I noticed that the sunken ship wreck which parallax scrolls when you meet Largo on the bridge is now gone (same as Amiga), I'm guessing for performance reasons...has anything else been stripped out?

Are your converted GFX in a proprietary format? Or can the files be loaded into anything for manual editing/tweaking?

Amazing stuff to see!

EvilFranky wrote: 22 Jun 2020 11:26 This is great, thanks very much :mrgreen:

Just a couple of notes as I've been playing about with it this morning.

It's actually faster than the A500 version, very noticeable when comparing between Hatari and WinUAE side by side. So performance is excellent! The Amiga does have better scrolling than both this conversion and the PC release as it appears to use hardware scrolling. But all animated NPC's and general Guybrush movement are sluggish on the A500.

When you release the source maybe someone will try and squeeze hardware scroll in there for the STe and Falcon :D

I noticed that the sunken ship wreck which parallax scrolls when you meet Largo on the bridge is now gone (same as Amiga), I'm guessing for performance reasons...has anything else been stripped out?

Are your converted GFX in a proprietary format? Or can the files be loaded into anything for manual editing/tweaking?

Amazing stuff to see!

Thank you! It's amazing to see it on my real ST, especially comparing with how slow it was in the beginning :)
Hardware scrolling would be a very nice addition indeed! It certainly tricked me into thinking the Amiga version was much smoother until you pointed it out :D

I did take take out a few things:
- The PC game script already supported getting rid of the sunken ship for when running in EGA, so I tell it we're in EGA :)
- There are script conditions based on a computer speed variable. The PC script set this to "fast machine" when the game starts but I change it to slow machine - this halves the amount of flying bats in the swamp.
(I am going to play through the game to double check there are no bad side-effects from this)
- The large lamp post in the beginnings of Indy4 was removed with dirty hacks.
Amiga version embeds it in the background graphics but on PC this is a large sprite that simulates a parallax effect much like that sunken ship in Monkey2. It tanks the framerate on 8Mhz machines.

I think these hacks should really be made optional, or auto-detected based on computer speed. They're mainly only there to help when playing on 8Mhz machines.


GFX is converted from the original resource files but the output resource files are in the same format as the original so I have been using the available viewers when debugging the conversion process (the output generated for release builds are not though - these skips the XOR encoding for performance reasons and that makes the usual resource viewer unable to load them).

The actual graphics inside those new resource files are new proprietary formats not recognised by any of the viewers though.
I tried to make a fair compromise between data size and performance here but I feel like there's more room for exploration in that area. It is certainly possible to boost performance more by going nuts with the data size.

It's absolutely possible to use a scumm resource editor to modify the graphics in the original .001 files and then start the game to have it generate the .ST1 resource file from it.

Bug reports on TT:

Day of the Tentacle:

• As usual, no YM music.
• Some text in the intro has one or two pixels missing from the top, other parts are partly rendering in black rather than cyan.

Indy 4:

• Randomly locks up (rarely) when playing music.
• Some incorrectly rendered text similar to DotT intro in terms of renderting parts of the characters in black.

MI2:

• Some text overlays previous text in intro, e.g. iMUSE credits overly previous text.

P.S. I've removed the Indy ghost failure as that was me being stupid and not the game.

agranlund wrote: 22 Jun 2020 12:50 GFX is converted from the original resource files but the output resource files are in the same format as the original so I have been using the available viewers when debugging the conversion process (the output generated for release builds are not though - these skips the XOR encoding for performance reasons and that makes the usual resource viewer unable to load them).

The actual graphics inside those new resource files are new proprietary formats not recognised by any of the viewers though.
I tried to make a fair compromise between data size and performance here but I feel like there's more room for exploration in that area. It is certainly possible to boost performance more by going nuts with the data size.

It's absolutely possible to use a scumm resource editor to modify the graphics in the original .001 files and then start the game to have it generate the .ST1 resource file from it.

I've been messing about this afternoon for a few hours with some SCUMM resource extractor/viewers.

The hurdle I appear to have (other than my total lack of understanding :lol: ) is that encoded SCUMM graphics look to use a separate CLUT entry? And I haven't worked out how I can change the CLUT yet. As a proof of concept I extracted graphics for some static images from the game, specifically the 'Part 1 - Largo Embargo' image.

I converted this down to 16 colours, the image is uploaded into the SCUMM file fine, but the colours are totally messed. It looked to me like it was using the first 0-15 colours of the CLUT which appear to always be the standard VGA colours. I'm guessing these are always static and reserved? And the remaining 240 colours can be used for game assets?

I would assume the SCUMMVM engine and file format supports 4-bit colour images? We have MI1 on the ST already :)

EvilFranky wrote: 22 Jun 2020 22:40 The hurdle I appear to have (other than my total lack of understanding :lol: ) is that encoded SCUMM graphics look to use a separate CLUT entry? And I haven't worked out how I can change the CLUT yet. As a proof of concept I extracted graphics for some static images from the game, specifically the 'Part 1 - Largo Embargo' image.
I converted this down to 16 colours, the image is uploaded into the SCUMM file fine, but the colours are totally messed. It looked to me like it was using the first 0-15 colours of the CLUT which appear to always be the standard VGA colours. I'm guessing these are always static and reserved? And the remaining 240 colours can be used for game assets?
I would assume the SCUMMVM engine and file format supports 4-bit colour images? We have MI1 on the ST already :)

Yes, the official scummvm supports a ton of different formats to cope with being able to run Atari/Amiga/FMTowns/Mac/PC versions of the games. And then each Scumm version will have its own set of formats as well..
Scumm-ST supports the formats used by Scumm.v5 and some of Scumm.v6 (just the early Day of the Tentacle stuff, it does not support any of the newer stuff added in for Sam'n'Max)
It doesn't support any earlier formats, or formats used by non-PC versions.

You can imagine why the real ScummVM is a tad big and slow.. I can only speak for the very old 0.6.0 sources but it's littered with "if this format, and not that platform, and this specific game then do this, else if blahblah do something else".
I ripped all that out and decided to support only PC-v5 stuff and enough of v6 for Day of the Tentacle to work.

I'm certainly no expert so some of the Scumm info may be completely incorrect. I only learned enough about it for the purpose of converting them into my own format.
You are correct that the BG/OBJ graphics references that CLUT in the room. Scumm v5 games can only have 1 CLUT per room, but v6 can have several CLUTs per room.. it's up to the script at runtime to change/modify/merge the active CLUT whenever it wants.

The first x entires in the CLUT is generally the same and used as some sort of system palette, and a chunk at the top is usually the same or common among many of the rooms (sprites seem to usually use the top of the clut)
I don't think there are any hard rules but at least these 3 games appear to work somewhat like that. I think it's really up to the game script coders and graphics artists how they want to lay out the palettes.

Your images should be 8bpp. The original graphics is always 256 colour for v5/v6 games. Scumm/ScummVM can reduce and dither on the fly for EGA etc but that's not really a viable option for an 8Mhz machine :)

Sprites are more complex. They have their own CLUT, which point to the active room CLUT, that points to the color data :)
For v6, that active-room CLUT is not necessarily in the same room as the sprite is stored.. A bunch of sprites in DOTT are stored in room X but intended to be drawn only in room Y using the CLUT from room Y - only the script knows this.
Sprite CLUT can be 16 or 32 colours.

You may want to check if there are any forums for homebrewing Scumm games. I am not sure what the best approach is for modifying existing graphics and not messing up sprites/scripts in the process..


ScummST has a much easier task compared to what you are describing, which is essentially modding a Scumm game.
It never tries to build an optimal palette for each room, it simply matches whatever colour scumm wants with the closest one in my hardcoded 16 colour palette which never changes.
The installer process is able to resolve the majority of this so it doesn't have to do this kind of stuff when the game is running.
v5 sprites are easy and the installed gets rid of all CLUT indirections completely making them quite fast at runtime.
It sadly needs to keep one indirection for v6 games because there it is impossible to 100% resolve the colour data statically (instead it resolves the last indirection when a room is loaded and it knows the "active room" CLUT)

Basically, that palette which is stored in the original resource is then not really used much after the conversion process.
It's there as a means to colour match stuff, and for generating speed-tables, when a room is loaded.

And a new version available now: http://www.happydaze.se/scummvm-lite-atari/
It's mostly fixes and minor improvement:

- Tuned the Indy4 colour palette to make it look good
- Lower quality DMA sound on 8Mhz STE to make Indy4 playable with speech enabled on these machines
- Made the YM sound/speech option work on Falcon
- Re-enabled some expensive graphics on machines with 68030 or better (sunken ship in foreground of Monkey2 etc..)
(Thanks for this idea @EvilFranky !)
- Fixed missing-sprite issues for objects which are spawned off screen (MI2 lady in swamp, INDY4 snake in jungle etc..)


@nemo , do you run FPATCH2.PRG from Atari on your Falcon? I've been trying to read up on STE DMA sound usage on Falcon and I found some mentions about having to run this program in order for some STE games & demos to play DMA sound correctly on the Falcon.
But I am assuming I have to just bite the bullet and do whatever Falcon specific stuff there is to do for Falcon DMA to work instead of relying on STE backwards compatibility.. Crossbar needs set up probably, and I have no idea what else yet.
In the meanwhile, I believe the YM option for speech should work on Falcon now..

Are the save games from the previous version compatible with this? I'm half way through Indy4 :-)

agranlund wrote: 23 Jun 2020 17:36 - Re-enabled some expensive graphics on machines with 68030 or better (sunken ship in foreground of Monkey2 etc..)
(Thanks for this idea @EvilFranky !)

Was just an observation buddy, but appreciate the shout out :mrgreen:

stephen_usher wrote: 23 Jun 2020 17:46 Are the save games from the previous version compatible with this? I'm half way through Indy4 :-)

Yep, they should be.

(but perhaps back them up just to be safe :D)