EvilFranky wrote: Mon Jun 22, 2020 10:40 pm
The hurdle I appear to have (other than my total lack of understanding
) 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.
