a comprehensive collection of all LucasArts background art (1987-2000)

[JPL]

Hi folks. A few weeks ago I started working on a spare time project: a complete collection of all the background art from every LucasArts adventure game (Maniac thru EMI), in palettized PNG format and in its original resolution and aspect ratio.

 

My ultimate goal is to upload this to archive.org, but since they don't seem to support editing the actual data contents of collections once you've uploaded them, I want to make sure I get things right before I do so. So I thought I'd present my work so far to some adventure game experts.

 

Here's a dump of the data on my personal website - as the page says, please do not link this page anywhere; I do not intend to host these files indefinitely and intend to take them down once the collection is completed and uploaded:

[link redacted for now]

 

The presentation on that page is also temp, it's just the quickest easiest way I found to provide access to all the data.

 

I'll let the draft readme on that page speak for itself - see the sections on "presentation of the work". To be very clear, these aren't raw dumps from a ripping program, though ripped data was the starting point for most of the images, I've edited these images (some quite extensively, eg the runtime-generated maze rooms in some games) to get them as close to how they look in-game as possible, minus most of the characters, obviously - the idea is to foreground and celebrate the art, and the artists who created it.

 

Stuff I'm looking for feedback on:

• Any artist credits I missed or got wrong in the draft readme.
• Any glitches in the images, ie places where I didn't patch in an object correctly, something is missing, etc.
• Anything I missed? ie entire rooms I forgot, etc.
  • In the interests of not flooding the collection hundreds of very similar images, I didn't include every maze room as those are cobbled together from pieces, but I tried to represent most or all of said pieces in a smaller number of "iconic" room images.
• Filenames - my naming convention was arbitrary and probably inconsistent in several places. Also I may have simply gotten the name or purpose of a room wrong. I didn't replay all these games while working on this, but I did jump in and out of ScummVM a ton to check my work.
  • I will probably rename all the files to move from snake_case to regular human filenames with capitalization and spaces.
• Any quality improvement suggestions, eg better versions of the existing images.

 

Stuff I can't figure out:

• How to get accurate palette shifts for the rooms in Zak FM Towns that use them, eg the jungle mazes, the Blue Crystal / Yellow Crystal / Mars Ankh / Mars Teleporter room, and the Egypt / Mars sarcophagus rooms. These rooms were all authored in one palette each, with SCUMM code (RoomColor?) setting the palette shift appropriately for each variation. But I can't figure out how to get those shifted palettes and map the images to them. It was easy to do this with Zak C64 and EGA because it's only 16 colors and it was trivial to just eyeball em... not so much with several different arbitrary 256 color palettes.

 

Edited August 11, 2023 by JPL
removed link to the archive hosted on my personal website, to keep bandwidth usage down now that this thread is possibly getting more attention.

[Serge]

Just a bit of what I remember from Zak FM, not sure if it helps any - don't have the scripts around... Generally, the palette was modified by moving rows of 16 palette entries around. E.g. replacing colors 16-31 with the colors in 128-143 - always a complete row, i.e. the first index to move (and move to) would be a multiple of 16. And always 16 entries to be moved. The one special room that I recall is the Egypt maze, which has one or two cases where the first 8 colors of a row are swapped with the last 8 colors.

 

Something you may or may not want to include: MI2 introduced parallax scrolling in the foreground, although I think they only did it for the ship hull in the foreground in Woodtick. FOA has quite a few more instances of it: The lamp post in New York, a palm tree and roof in the Azores, a rope in the Algiers Dig Interior, etc. I guess those might be considered part of the "background", although the parallax nature of them complicates things when representing the background as a still image, of course. 😁 Because objects (generally) can't really change their position within a room, these parallax effects were implemented with actors and costumes, rather than object images. I've attached the cels for those costumes (I may not have identified all of them), just in case. Ship hull in woodtick; roof in the Azores; palm in the Azores; pillar in the orichalcum machine room; rock in the lava pool room; rope in Algiers Dig interior; lamp post in New York.

Edited July 30, 2023 by Serge

[JPL]

1 hour ago, Serge said:

Just a bit of what I remember from Zak FM, not sure if it helps any - don't have the scripts around... Generally, the palette was modified by moving rows of 16 palette entries around. E.g. replacing colors 16-31 with the colors in 128-143 - always a complete row, i.e. the first index to move (and move to) would be a multiple of 16. And always 16 entries to be moved. The one special room that I recall is the Egypt maze, which has one or two cases where the first 8 colors of a row are swapped with the last 8 colors.

 

That's consistent with what I'm seeing; I'm down to looking through decompiled scumm scripts, and the numbers it's giving for room color changes are definitely all single digit numbers, and looking at the palettes in GNU IMP they're pretty much all even 16-color ramps. It'd be easy to swap one of those ramps (from another room's palette, possibly?) in for another, but the question is which one... it's kinda hard to just eyeball. My guess is that the alt palette / ramps are *somewhere* in existing game data, ie they didn't just make new palette ramps just for these swaps. I'm just not quite good enough at decompiling and reading these old scripts to know which ones they might be.

 

 

1 hour ago, Serge said:

Something you may or may not want to include: MI2 introduced parallax scrolling in the foreground, although I think they only did it for the ship hull in the foreground in Woodtick. FOA has quite a few more instances of it: The lamp post in New York, a palm tree and roof in the Azores, a rope in the Algiers Dig Interior, etc. I guess those might be considered part of the "background", although the parallax nature of them complicates things when representing the background as a still image, of course. 😁 Because objects (generally) can't really change their position within a room, these parallax effects were implemented with actors and costumes, rather than object images. I've attached the cels for those costumes (I may not have identified all of them), just in case. Ship hull in woodtick; roof in the Azores; palm in the Azores; pillar in the orichalcum machine room; rock in the lava pool room; rope in Algiers Dig interior; lamp post in New York.

 

Ahh, yes I remember those parallaxy bits! I forgot all about them, so I'll try them out.

[Lagomorph01]

6 hours ago, Serge said:

Something you may or may not want to include: MI2 introduced parallax scrolling in the foreground, although I think they only did it for the ship hull in the foreground in Woodtick. FOA has quite a few more instances of it: The lamp post in New York, a palm tree and roof in the Azores, a rope in the Algiers Dig Interior, etc. I guess those might be considered part of the "background", although the parallax nature of them complicates things when representing the background as a still image, of course. 😁 Because objects (generally) can't really change their position within a room, these parallax effects were implemented with actors and costumes, rather than object images. I've attached the cels for those costumes (I may not have identified all of them), just in case. Ship hull in woodtick; roof in the Azores; palm in the Azores; pillar in the orichalcum machine room; rock in the lava pool room; rope in Algiers Dig interior; lamp post in New York.

Wasn’t SMI the first game to do so? I remember the ship in the Governor’s Mansion really coming at you, and a friend of mine actually got startled by it.

 

Other than that, cool project! And it’s great that you’re so thorough on it, JPL!

[Thrik]

Yea the mansion had parallax scrolling, and similarly was the only case of this in the game.

[Serge]

11 hours ago, JPL said:

 

That's consistent with what I'm seeing; I'm down to looking through decompiled scumm scripts, and the numbers it's giving for room color changes are definitely all single digit numbers, and looking at the palettes in GNU IMP they're pretty much all even 16-color ramps. It'd be easy to swap one of those ramps (from another room's palette, possibly?) in for another, but the question is which one... it's kinda hard to just eyeball. My guess is that the alt palette / ramps are *somewhere* in existing game data, ie they didn't just make new palette ramps just for these swaps. I'm just not quite good enough at decompiling and reading these old scripts to know which ones they might be.

 

The palette mutation script looks pretty much like this:

https://scumm.jither.net/?Jither/4ad155c14594f848e3e4cc8d2c39355e

 

The room-color command here doesn't actually set a color, it puts an index to the actual palette (the PA chunk for Zak FM) into the room palette. By default (when entering a room), the room palette looks like 0, 1, 2, 3, 4, 5... 254, 255 - meaning the room will just use the colors in the actual palette as-is: If the background or an object image has the value 78 for a pixel, it will use color 78 from the PA chunk. So, changing a value in the room palette using e.g. room-color 215 in-slot 78 doesn't actually change any colors as such - it just makes color 78 in room graphics use color 215 in the actual palette stored in the game files.

 

The palette mutation script works with the palettes in a 16x16 grid:

 

 

It is generally called in one of two ways: With 2 arguments or with 4 arguments. You'll see cases in room 47 (which contains the system scripts) where it's called with a third 0 argument, but that has the same effect as calling it with two.

 

The two argument version changes a row of 16 palette entries to point to a different row than the default. The four argument version allows to change a subset of a row - in practice, it's only used to swap the two halves of a single row.

 

So, for example:

mutate-palette 3 12

 

... will remap 16 palette indices starting from row 12 - i.e. index 192 (16 times 12) to instead point to the 16 colors starting at index 48 (16 times 3) in the actual palette. So, it can be read as "change the palette at row 12 to use the colors at row 3".

 

mutate-palette 6 6

This will change the room palette to the default for this row. The 16 palette indices starting from 96 (16 times 6) will point to the actual palette colors starting from 96. In other words, the colors are unchanged from the PA palette (for this row). So, it can be read as "change the palette at row 6 to use the colors at row 6".

 

mutate-palette 5 5 0 8

This will remap 8 palette indices starting from 88 (16 times 5 + 8) to instead point to the colors starting at 80 (16 times 5 + 0). So, it can be read as "change the palette of the last 8 colors in row 5 to point to the first 8 colors in row 5".

 

The script where this occurs follows up with mutate-palette 5 5 8 0 - in combination, the two result in swapping the 8 "left" colors of row 5 with the 8 "right" colors of row 5.

 

Does that make sense? 🙂

 

5 hours ago, Lagomorph01 said:

Wasn’t SMI the first game to do so? I remember the ship in the Governor’s Mansion really coming at you, and a friend of mine actually got startled by it.

 

Yeah, you're right. 🙂

Edited July 31, 2023 by Serge
Fix link

[JPL]

3 hours ago, Serge said:

Does that make sense?

 

Yeah, thanks! That's pretty much what I gathered was happening. What I'm having the most difficulty finding are the actual color values (or indices, for some existing palette I can sample) that the default palettes are being set to in these few specific rooms. I had an idea to go to one of them (eg the Yellow Crystal room in the Mayan pyramid) in ScummVM and take a 1:1 unfiltered / original pixels screenshot, sample one of the shifted colors, and then wrote a Python script to search all the existing background images' palettes for that exact color - thinking that it's defined in some other palette.

 

But that didn't return any results! So last night I tried a more manual, lower tech solution on one image, as a test to see how it looked: I sampled a few (3-4) colors along one of the shifted ramps in the ScummVM screenshot (ie the actual colors specified by the game data, AFAICT), and then opened up the unshifted palettized image in DPaint IIe in DOSBox, set those same indices to those colors, and then used the "Spread" palette function to fill in the rest of the ramp with the approximately-correctly shifted colors. When I pasted this result back into GNU IMP over the screenshot, there were definitely some small discrepancies in color, but it looked "pretty close", and it got me closer than any other method I've tried to date. So I might just try that approach for the remaining 6-7 images that need these palette shifts. Which involves playing fairly deep into Zak (skipping to the room #s via the debug console doesn't work, because they're all variations on the same room!) which I hadn't done in years.

 

What is that Palette Viewer program you've screenshot there? I've been amassing all kinds of old quirky SCUMM tools throughout this process and that one doesn't look familiar.

[Serge]

2 hours ago, JPL said:

 

Yeah, thanks! That's pretty much what I gathered was happening. What I'm having the most difficulty finding are the actual color values (or indices, for some existing palette I can sample) that the default palettes are being set to in these few specific rooms. I had an idea to go to one of them (eg the Yellow Crystal room in the Mayan pyramid) in ScummVM and take a 1:1 unfiltered / original pixels screenshot, sample one of the shifted colors, and then wrote a Python script to search all the existing background images' palettes for that exact color - thinking that it's defined in some other palette.

 

But that didn't return any results! So last night I tried a more manual, lower tech solution on one image, as a test to see how it looked: I sampled a few (3-4) colors along one of the shifted ramps in the ScummVM screenshot (ie the actual colors specified by the game data, AFAICT), and then opened up the unshifted palettized image in DPaint IIe in DOSBox, set those same indices to those colors, and then used the "Spread" palette function to fill in the rest of the ramp with the approximately-correctly shifted colors. When I pasted this result back into GNU IMP over the screenshot, there were definitely some small discrepancies in color, but it looked "pretty close", and it got me closer than any other method I've tried to date. So I might just try that approach for the remaining 6-7 images that need these palette shifts. Which involves playing fairly deep into Zak (skipping to the room #s via the debug console doesn't work, because they're all variations on the same room!) which I hadn't done in years.

 

What is that Palette Viewer program you've screenshot there? I've been amassing all kinds of old quirky SCUMM tools throughout this process and that one doesn't look familiar.

 

https://quickandeasysoftware.net/software/scumm-revisited

 

The one in the dump specifically is SCUMM Revisited 5, but as far as I recall, there are palette viewers in all 3 versions (but they don't all support the same games or features - I was rather haphazard with coding back then).

 

The default palette is in the game data - for Zak FM it's the PA chunk. All SCUMM Revisited versions open Zak FM, but 2 may be slightly more useful in this case, since it also list the hex values for each color. Although, of course, you can use a color picker to get the colors too - 5 is generally more useful for viewing rooms, since it also allows showing or hiding object images individually (click "View Room" when a RO or ROOM chunk is seleced) etc. In general, the colors may be more reliable than ScummVM, since ScummVM may apply filters and color profiles(?) that will change the actual output. The palette viewer (and image and room viewers) use the colors straight from the game files.

 

All that should really be needed is to rearrange that default palette according to the calls to the palette mutation script. I.e. copy the colors in row 3 to row 12 if the parameters are "12 3". Of course, beware that if another line says e.g. "10 12", you'd need to copy the original colors in row 12 to row 10 - not the colors that were copied from row 3 earlier.

 

Oh, and it should be entirely possible to skip to a specific room - while, yes, they're variations on a single room, they all do have their own room number. I haven't annotated all of Zak, so a lot of the rooms in this script are unnamed, but this shows the general idea:

 

https://scumm.jither.net/?Jither/8f01826cd23b042264fc50db2b59a438

 

I.e., room 29 has four "variations" (pseudo rooms) - which have the room numbers 189, 190, 191, and 182.

[JPL]

12 hours ago, Serge said:

All that should really be needed is to rearrange that default palette according to the calls to the palette mutation script. I.e. copy the colors in row 3 to row 12 if the parameters are "12 3". Of course, beware that if another line says e.g. "10 12", you'd need to copy the original colors in row 12 to row 10 - not the colors that were copied from row 3 earlier.

 

Oh, and it should be entirely possible to skip to a specific room - while, yes, they're variations on a single room, they all do have their own room number. I haven't annotated all of Zak, so a lot of the rooms in this script are unnamed, but this shows the general idea:

 

https://scumm.jither.net/?Jither/8f01826cd23b042264fc50db2b59a438

 

I.e., room 29 has four "variations" (pseudo rooms) - which have the room numbers 189, 190, 191, and 182.

 

Thanks a ton for the info! I only just realized that the colors I'm looking for are in the exact same palette, and being shifted around like that. With accurate screenshots (which I was able to get easily, thanks to your room numbers list) I was able to work out exactly which ranges are being moved. I now have a python script that can manipulate the palette slots appropriate based on a series of commands for each specific image. Rather than think about the order of operations, I simply operate on a copy of the palette and "paste" ramps into that, and then set the output image to use that. That was the final technical hurdle facing this project. Thanks again!

[Laserschwert]

Amazing project! So many times I've been searching for a specific background, so this is perfect.

[JPL]

I'm now at a Release Candidate stage, as far as the actual images are concerned.

 

http://vectorpoem.com/lucasarts_backgrounds

 

Lots more work compared to my last update, here's what I can remember:

• Finished up images for the remaining games, eg the palette shift rooms in Zak256.
• Integrated all the costume-based parallax objects I know of: the Mansion interior in Monkey1, the Woodtick boat wreckage in Monkey2, and several in Fate of Atlantis (New York, Azores, Crete, Algiers, Atlantis). And one I found in The Dig.
• Did a file rename pass to replace all my 001_snake_case_style_names.png with easier to read names with capitalization and spaces, retaining the room number for its historical meaning.
• Renamed the game and version directories to be similarly more human-readable, eg "Commodore 64", "DOS EGA", "Windows", etc.
• Added and edited several more images I realized were missing or inaccurate when I was doing this big renaming + quality control pass.

If anyone spots any inaccuracies, omissions, or otherwise at my temp archive link there, now's the time to call em out. Besides that, I just need to finalize the readme file and decided on a format for it (plaintext, markdown, HTML) - this is probably something where I should browse archive.org for the better put-together collections and see what they did.

 

Thanks again for the help in getting this together! Serge and the rest of yall definitely get a credit in the readme, along with all the tools I used.

Edited August 6, 2023 by JPL

[JPL]

Heyy, thanks for the writeup!

 

I ended up soft-launching the bot part of this first, on Mastodon and Cohost, because the code part was easy and the data was ready to go. I was planning on "announcing" it officially from my main accounts on those respective sites sometime this week, once the masto version had a couple more posts in its timeline. It's all good, they're out in the world and I'm happy to have people looking at em.

 

I'm a little more uncertain on how best to make the actual images available in a collection, as I originally intended. The more I looked at archive.org, the more I realized it wasn't actually a great way to publish and browse certain collections of images - it's more of a "here's a big dump of stuff, all in one big directory" sort of thing, and you don't have much of any control over how it's presented, eg it's a long tiled scroll of square thumbnails. I'd really like to present this work in a format that's easy to browse (ie sorted by game and by game-version) and appreciate its visual quality (ie original res + click to view larger in a lightbox)... but I'm not sure what websites are out there for doing this, that has the commitments to archival integrity that archive.org does - ie I don't want to use one of those image hosting sites (like imgur) that are just going to "pull a photobucket" and vanish from the web when the VC cash runs out, leaving tons of broken links. This kinda includes even my own personal website, which even if bandwidth cost me nothing isn't going to be a reliable place to keep data for the long term future.

 

I'm also thinking about the copyright status of this work - obviously the original artwork is LucasFilm's copyright, and I don't want to do anything that would make them feel like their work is being "pirated" or anything (even though it's hard to imagine it being used in this way - people using it in their own games without attribution?). In various senses these images are highly edited screenshots, and I've read several assertions online that game screenshots count as "derivative works". But they're very obviously not my artwork; the whole point of this is to celebrate the actual artists. I've used Creative Commons licenses for some things I've personally created in the past, but this is not that kind of case, so I don't think I have any right to stick a CC license on these files.

 

So I dunno, I'd love to share the full collection of this stuff, but I'm not sure what the best outlet and format would be. Suggestions welcome but certainly not expected! Thanks again for the technical and moral support so far.

[Laserschwert]

Regarding archive.org, it might work by putting the PNGs of each game version into a PDF and uploading those. Sure, it has that "take a screenshot, paste it into Word, print it out, scan it into a PDF"-vibe, but that would a) keep the PNGs uncompressed, and b) make them browsable all the way from thumbnails to full-screen zoom.

[Thrik]

I’m sure you know this, but if you go to web.archive.org, it will automatically store copies of websites it knows about for all eternity. As far as I’m aware these aren’t compressed, and it is presented exactly as you chose to do so. It is also versioned by date.

 

Now, the discovery part is more challenging. There is no end of gold out there, but knowing it’s there is another story. It also struggled a lot more to capture everything with the early web, while it is much better nowadays — and if you manually trawl your archive and notice something is missing, you can command it to fetch it from the live page for future copies.

 

One thought I have had (with regards to my own projects like brutallegend.net and razputin.net (which now exist on web.archive.org only) and perhaps eventually grimfandango.net is to ensure they are archived properly on the web archive, and then perhaps find some way of linking to a certain copy on archive.org itself so it’s easier for people to find.

 

https://web.archive.org/web/20010301044512/http://www.mixnmojo.com/ 

[Laserschwert]

While that would take care of the archival part, it wouldn't increase user-friendliness. At least having it as a PDF would allow easier browsing and previewing.

[Thrik]

I think that depends on how the site is presented.

 

JPL has expressed they find the limitations around how they present and organise the images frustrating, and there is no medium better suited to giving you complete control of this while still being compatible with virtually any device for the foreseeable future than a website.

 

You can use any tool you like to make this easier and the web archive will archive it just fine, as long as it’s online for a while. In my mind, something like Remi’s efforts here and here would work great for a project like this.

 

Personally I’d  prefer browsing something like that (or JPL’s original site) than having to deal with PDFs. It’s also very easy to save images from websites, nest links, build a hierarchy, etc whereas this can be flaky with PDF readers on various devices and/or just not suited to the medium.

[Laserschwert]

Either way, uploading them as PDFs would still make sense, just from a backup perspective. As a test, here are the backgrounds from SoMI EGA / Zak FMT / CoMI compiled into PDFs.
 

The files are still in their original formats, with - from what I can tell - their palettes fully intact.

Edited August 11, 2023 by Laserschwert

[Thrik]

Yes, no disagreement there. I think you have two purposes really:

 

1. A comprehensive, self-contained, and easily copied artefact that contains as much of the content as possible with minimal if any loss of quality — the real archivist’s resource

 

2. A more explorative museum-style experience for people to dip into and enjoy, who aren’t so much interested in the archival itself and just want to look at it and it be presented in an engaging way

 

I think your PDFs suit #1 well, while for #2 it’s good to have things like the Mastodon bot, and an attractively structured and presented website that works well on phones as casual browsers are akin to use. Or better yet, print then all out and put them in the exhibition hall! 😅

[Laserschwert]

I agree, the ideal presentation would be in the form of a more elaborate website or app. I'm thinking of features like thumbnails and light box view, but also the ability to zoom into the images, switch between different versions of the same background, toggle aspect ratio correction, maybe simulating a CRT screen, etc.

 

Edit: Ah, screw it, I converted them all. Acrobat created a bookmark for each page, named after the file, so those names are still intact as well.

https://drive.google.com/drive/folders/1C3v3cQNGdU6qgElSDKxen5OeU1OtGUNF?usp=sharing
 

Edited August 11, 2023 by Laserschwert

[Benny]

46 minutes ago, Laserschwert said:

I agree, the ideal presentation would be in the form of a more elaborate website or app. I'm thinking of features like thumbnails and light box view, but also the ability to zoom into the images, switch between different versions of the same background, toggle aspect ratio correction, maybe simulating a CRT screen, etc.

Sounds like something that could be done on Mojo maybe? In the past we have talked about doing things like that for the games database.

[Laserschwert]

Something I've noticed missing are the credits/menu/inventory backgrounds for several games (CoMI, EMI, MI2, S&M come to mind). Maybe some of those aren't that interesting to look at, but for preservation's sake, all of them should be included. Plus, you should probably include clean versions without foreground overlays (like the parallaxes) or sprites (like the cannon "game" from CoMI).

 

Edited August 11, 2023 by Laserschwert

[LuigiHann]

Great collection! I agree that it'd be amazing to have at least a lightbox view, and it does seem like a good fit for mixnmojo's media section (which could, honestly, also benefit greatly from a lightbox implementation).

 

If you're looking to set up a unique collection on Archive.org it may be worth shooting a friendly message to Jason Scott (https://mastodon.archive.org/@textfiles or jason@textfiles.com I think). I don't know him well but he was a big part of setting up the Winamp Skins archive (https://archive.org/details/winampskins?tab=collection) so we've chatted a bit and he seems nice enough. He manages a lot of the interactive gaming-related collections on there (eg. https://archive.org/details/consolelivingroom?tab=collection) so he'd probably find the backgrounds collection intriguing and he wouldn't stress much about the copyright status. 

[Jake]

I’m friends with the guy who made the Winamp skin museum and Webamp (Jordan Elderedge) and can put you two in contact if that’d be useful. 

[LuigiHann]

Oh haha yeah, a version of this gallery laid out like https://skins.webamp.org/ would be pretty fun

[JPL]

Wow, great replies folks! Some exciting possibilities here.

 

Laserschwert, thanks for the PDF suggestion, I'm such a digital-only guy and not at all used to thinking of PDF as a target format, but it's clearly got high value for preservation. I was curious if the PDF specs support embedded PNGs with indexed color specifically (the PNGs in the sample you gave were RGB, afaict) - according to this page they do - because IMO it's important to hold onto that for uses like color cycling and palette swaps (see below).

 

I hadn't considered the possibility of a subsite hosted here on mixnmojo but the examples you posted, Thrik, are great and really got me thinking how ideal it could be with the right presentation. My personal site is all hand-coded/generated, really basic CSS and barely uses javascript for anything, and I don't know anything about modern frameworks and stuff, but if there are lightbox implementations out there that could provide pixel perfect (even multiples, I guess, like ScummVM) + aspect-corrected scaling with good scrolling, that work work perfectly.

 

The option of a CRT filter is a dream feature (some of the art looks 10x better with eg crt-easymode-halation.glslp in scummVM!) but I'm guessing it's not trivial; most CRT filters are done with shaders which implies a WebGL/WebGPU context (the latter of which I really want to learn for other projects!) so maybe that's in the gravy category for now.

The absolute dream would be an individual image view mode that also supports color cycling for the few dozen images in the collection that use it, using something like this library used by the famous HTML5 Color Cycling page.

 

But it seems like there's two distinct levels of fanciness here, the well-presented but nothing "dynamic" level that is super achievable with a well-designed conventional page (using a modest amount of js?) and the "fully dynamic" view which adds CRT filter(s), color cycling, maybe streams an appropriate soundtrack track (heck, give them an option where appropriate for Adlib vs MT-32, etc!)... just a full sense of "being there" in your web browser. The latter is much more experimental, maybe I'll mess with those ideas on the side to see how tractable it is.

 

The former, though - I'm pretty sold on the idea of a LucasArts Places page that is hosted on a site more reliable than mine, has a nice browseable design, etc. I'd be happy to do the bulk of the work on that and/or collaborate with someone on it.

 

That WinAmp skin museum is a beautiful achievement, I love it and I love how the layout offers this endless cornucopia of stuff. The LucasArts images aren't all the same size so it wouldn't be the same vast tiling landscape, and I think I'd want each game + version to be its own page. But it's inspirational for sure.