tomysshadow

Followup: I've now implemented this and I determined it doesn't take enough longer to have a noticeable impact. It so happens mango has an sRGB to linear function that is much faster than using Pixman to do the conversion so that's what I used. I kept it 32-bit all the way through which will introduce some colour banding but it's not really noticable with the photorealistic images being resized. So I expect this will be ready for whenever I release my next version

right, looking at it again, I think I get it now. You'd need: the 8-bit sRGB source, to the premultiplied image as floating point (Pixman can't do to 16-bit channels it seems,) then to the resized image as floating point, then unpremultiply that, and then go back to 8-bit sRGB. It makes sense in my head, I just don't know if it's really worth all that tradeoff, it's a lot of extra steps... I don't even know that the original resize algorithm would've even done it either given its age, and my goal is to replicate that. But maybe I'll test and see how it goes eventually

Someone on Reddit pointed out to me after, DDS is DirectX specific and the DVD was for Win/Mac, so it may have been more of a multiplatform issue than a space one. In an ideal world you'd use DDS on Windows because it's fastest there, and whatever the OpenGL equivalent is on Mac, but that would've been well, well outside of space constraints, at that point

1. There are probably better tools to do it, but I just used Google Drawings.

2. Not for Myst IV currently. All of the prior games are supported by ScummVM, which would work on an Android device, but Myst IV is not in there yet. Maybe someday though

No, actually, I did see this. The problem with using STBI_MALLOC in that way is that it is used for _all_ allocations by STB, not just the main image buffer. The image buffer I need to put the data into is passed in as an argument to Gfx Tools. It is already existing, and I couldn't touch the code where it was created, that code lived in yet another DLL, the one calling into Gfx Tools. So if I overrode STBI_MALLOC to just return that same buffer every time, then any time STB calls malloc, each malloc call would return the same buffer, that same buffer would be used for different allocations with entirely different purposes. So, it's close, but it wouldn't work. I would need to have done some hack like checking the requested buffer size to malloc matches the expected size of the image buffer, and only return it then, but that's of course quite fragile and error prone. Or, you know, just go into the STB source and find the one malloc I need to replace, but that's kind of dirty.

For me at least, with the optimized loader library, yes, the impact of the DDS conversion is almost unnoticeable. However, I have a pretty fast CPU so I don't want to assume that it'd be the case for everyone, and the DDS conversion was done first, so even if it is overkill it costs me nothing to leave in and will better serve anyone with a slow CPU where mango and Pixman aren't enough.

Shortly after I released my tool, I had someone report that it was crashing for them because they were using a third gen Intel CPU that didn't have a SIMD instruction set the x64 command line portion used (particularly the BMI instruction set.) It was a bug in the mango image library anyway because I had disabled that particular instruction set when I built it, but goes to show that when you're doing a retro game hacking project, a lot of gamers are keen to use older hardware for them and I'm quite aware of this fact

I was genuinely concerned that everything I was doing with mango and Pixman was going to turn out to be pointless. It wasn't, thankfully, there was a noticeable difference after introducing them. But it was a gamble for sure, because there was no smaller test I could really do to know it was worth it in advance - if I wanted to replace that DLL, I was going to have to replace the whole DLL because it was C++, the DLL exports were all mangled names for classes that all kind of interacted with each other, so I couldn't just cleanly replace one call and see that it was a good idea. I try to gather as much evidence as I can to back the idea it'll work before I make the leap, but I've learned that if you really want to get stuff done sometimes you just have to go for it and assume there is a way to salvage it if it fails

To be completely honest, it's surprising to me as well. I would expect it to be bad, but not as bad as it was. I entirely expected that the slow part would be decoding, not copying. In fact, my initial plan was to convert the remaining images that couldn't be DDS to Targa, on the assumption it would decode faster. However, when I investigated the slow functions and found they were only copying, I changed tactic because then in theory that would not make a difference.

There is no fixed amount of per-frame work. After the 550ms hardcoded timer is up, it is blocking during the loading of those images, and during this phase all animations on screen are completely still. I thought to check for this, because it did occur to me that if it tried to render a frame inbetween loading each image to keep the app responsive, that would push it to be significantly longer, and that would be a pretty normal thing to want to do! But I found no evidence of this happening. Furthermore, I never changed anything but the actual image loading related code - if it tried to push out a frame after every image load or every x number of image loads, those x number of frames wouldn't go away only by making the images load faster, so it'd have never gotten as instant as it did without even more change.

The only explanation I can really fathom is the one I provided. The L_GetBitmapRow function has a bunch of branches at the start of it, it's a DLL export so the actual loop happens in a different DLL, and that happens row by row for 500+ images per node... I can only guess it must be because of a lack of CPU caching, it's the only thing that makes sense given the data I got. Probably doesn't help that the images are loaded in single threaded fashion, either.

That said, there have been plenty of criticisms of my profiling methodology here in these comments, so it would be nice to perhaps have someone more experienced in low level optimizations back me up. At the end of the day, I'm pretty sure I'm close enough to right, at least close enough to have created a satisfactory solution :)

This is something I'd love to get right. Pixman does appear to support sRGB input, in the form of the PIXMAN_a8r8g8b8_sRGB format, which might work well enough for the premultiply step. It's the unpremultiply that I'm struggling to wrap my head around - I'm guessing I'd need Pixman to output to 16-bit channels in the destination, otherwise I wouldn't be able to convert back to sRGB? That's kind of a massive pain though, I'd have to allocate a whole other temporary buffer that's double the size, for something that is imperceptible enough I never noticed it with my test images or in my playthrough. So I'm unsure what the cheapest way to do it would be. This is all well outside of my area of expertise which is primarily hacking and reverse engineering, but I'm always open to learn.

I tried my hardest to create something that was as "technically correct" as I could approximate given my lack of graphics experience and the performance constraints I was under, but I kind of knew it was likely I could mess up some small detail. Maybe since it's open source someone will eventually come along to correct it? One can dream :P

Probably because Director was originally created under a different name, VideoWorks, which WAS released by MacroMind before they eventually became Macromedia.

Note that Shockwave installers will also stop working after that point, as even the "full" installer downloads components from the web during the install.

Here's the thing. A lot of the games being saved here are games that the original publishers/developers no longer care about - that or the original creators don't even exist anymore. That throws a large portion of Flash games into the gray area of abandonware, although that's a different discussion entirely.

This is actually a place where I differ with BlueMaxima (BlueMaxima is Flashpoint's creator and the writer of the article linked here.) Personally, if I were running the project I would remove a game if the original creator asked, simply out of respect for them.

However, I think that most of the staff involved with Flashpoint would disagree with me here. It is more of a "for now, just go go go and we'll worry about organizing everything and dealing with the repercussions later." There's a lot of Flash games out there to say the least and Flash being discontinued in 2020 leaves us limited time if we hope to save as much as possible.

Because it gives the Java programmer too much power in an environment that should be safe. For example there are applets like AppEmbed that can run an EXE in the browser. That's just insane. Flash and Shockwave in contrast are limited in that sense, you are constrained to doing what you are able to accomplish with ActionScript or Lingo (or at least, that is intended to be the case.) Flash is insecure because it's buggy, Java is insecure because it's buggy AND because it's intended to work in ways you'd think are obviously insecure!

You don't need to change your user agent. Just click the "Need Shockwave for a different computer?" button on that page.

You definitely want the Full version not Slim. The Slim version throws out some backwards compatibility stuff to decrease the filesize.

Right, I suppose it's not fair to say it was originally meant for "creating CD-ROM games," that's an oversimplification. It's more like it was meant as a way to make applications without needing to learn a more advanced language like C++.

There's an excellent command line application called Auto Saving Sniffer which can be found here (ignoring the rather crude abbreviated name.)

https://www.cockos.com/assniffer/

While you need to play through the entire game to be sure you have all of it, this is a big time save, though with the downside it doesn't work over HTTPS. It's also possible to use a Fiddler script to accomplish something similar, which defeats the HTTPS problem.

The thing is, Flash is still in use, just not on the web and it's not called Flash. It's called Adobe Animate. Adobe Animate, formerly Flash, is still in use for animating shows on television. Open sourcing Flash would mean creating a potential competitor with Animate, which Adobe surely doesn't want. The only reason Adobe would have to open source Flash is "out of the kindness of their hearts" which is not enough. This is nothing but a needlessly risky business venture to them.

I don't see how this contradicts my point at all. This project is about saving Flash games, not Javascript.

Yes. Alternatively, you can use Pale Moon which is an actively maintained fork of Firefox that never got rid of NPAPI. Or, if you don't want to leave the comfort of your preferred browser, you can use the IETab extension.

Note that plugins do not work in Microsoft Edge. It has to be Internet Explorer. Edge didn't replace IE, you can still find IE by searching for Internet Explorer in the Windows 10 start menu.

Unfortunately, Java is a bit of an archival nightmare. Java Applets can do pretty much anything they want, they aren't consistent in that sense. Unlike Flash you can't just run them offline in a Projector, and the code structure of an applet is different from that of a normal Java app. This is on top of being unable to play Java games without getting a tonne of (well deserved) security warnings (unless you want to pay Oracle $100 per month for a signature.) Java in the browser was just a bad idea all around.

Actually, it's still being updated, but only on Windows. Director (the authoring tool used to create Shockwave Movies) was discontinued, but Shockwave was not.

Both Lingo and ActionScript compile to bytecode.

When asking the difference between Shockwave and Flash, you'll often get the answer that they're two products that have nothing to do with each other. That is almost true, but not entirely true.

Director was originally meant for creating CD-ROM games. However, in the early 90's, it began finding a new home on the web. "Shockwave" was Macromedia's term which meant "compressed for the web." The first entry in the Shockwave line of products was Shockwave Director Player - so called because it could play Director Movies which had been compressed for the web. Because it was, at the time, the first and only product in the Shockwave line of products, Shockwave Director Player was often shortened to just "Shockwave."

Enter Flash. Again, Macromedia wanted Flash Movies to be able to be compressed so they could be downloaded quickly over the web - so they made the Shockwave Flash Player plugin, so called because it could play Flash Movies which had been compressed for the web. So there was Shockwave Director Player, to play compressed Director Movies, and Shockwave Flash Player, to play compressed Flash Movies.

The problem is, by this point, everyone already knew Shockwave Director Player as just "Shockwave." To those uninformed, it seemed that there was now both a Shockwave AND a Shockwave Flash. Shockwave Flash Player was more often referred to as just Flash, to avoid confusion with what was already being referred to as Shockwave.

So when we say Shockwave, we're referring to the first word in Shockwave Director Player, but when we say Flash, we're referring to the second word in Shockwave Flash Player...

Or at least, this was the case until Adobe acquired these names from Macromedia, at which point they just decided to rename the plugins to what they were being popularly referred to as. Now what was Shockwave Director Player is officially just called Shockwave, and what was Shockwave Flash Player is officially just called Flash. In order to further undo the confusion, SWF was changed to stand for Small Web Files instead of ShockWave Flash.