Excuse me while I run around kermitflailing because WE'RE ALMOST THERE!

Great work! The writing part will take me a little longer - I'm hoping for today but no guarantees - so I'm uploading a new version for final testing of Version 1 reading.

Edit: Debugging will take another day at least.

Sending cheerleader crabs and rubber ducks for the debugging! I should be able to do some testing tonight, whether it's making LRLEs and hopefully putting them in the game or just testing the v1 decoding.

Thanks! Right now writing is a big mess but at least I've got it producing something vaguely resembling a valid LRLE, lol. I'm a little slow these days. Testing of version 1 would be helpful, although my feeling is that that's working fine.

I Wish I knew what I could do to assist you right now beyond wait for the first version of the writer.

Actually I would very much appreciate help since I haven't been feeling well but really want to get this in shape for testing as soon as possible, so if you could take a look and see where I went wrong that would be great. I think I finally got the run calculations right (maybe) but it's not making readable LRLEs. Code is attached, thanks so much!

Alright, give me some time to see where things are going wrong. One thing I did notice is that EA/Maxis seems to sort the colors by use count. It's something we don't need to do unless a 100% match is important.

Yes - I want to take care of the finer points like that when it's basically working. Also it looks to me like EA creates the mipmaps with colors restricted to what the main texture uses so I want to take a closer look at mipmap creation - maybe it just needs better quality resizing but we'll see. Maybe I can look into those two things meanwhile.

Alright attached is my work so far on the code. I got it to the point where the LRLE the converter spits out can also be read by the converter. I did start work on converting dds files with mip maps straight to LRLE, mostly so I could do some comparisons to a EA LRLE and one of our LRLE files made from a EA provided DDS without going through PNG. Some things are still hardcoded to be based on a 1024 by 2048, 32 bits per pixel, BGRA dds file and it needs to we wired up to the UI.

Seems there's been another contribution, and converted LRLEs default to pretty useable makeup sliders even when you don't plug any values in.

Version 2.0 uploaded, with support for conversion from PNG to LRLE. Thanks, tau534! Testing will be helpful, everyone. When I feel better I'll look at the DDS conversion.



Good, the modding community needs S4S to support LRLE so I'm glad. I guess they did their own testing or maybe their own version of conversion to LRLE. It's amusing they gave me second billing but at least they gave credit to both of us.

I was expecting, and 100% fine with, the S4S team to use CmarNYC and my work to get LRLE working in their program. I just did not expect it so soon.

Yes! I just saw that Andrew reached out to me on the EA forums with a thank you. He wrote his own conversion to LRLE. He's shared his code on GitHub if you're interested: https://github.com/andrew-tavera/LRLE

I'm glad he did since I already spotted one issue. He missed the embedded color commands you found so one of use is going to have to get his attention on that.

Oh, yeah, Andrew has to have been working in parallel to you two all week to have this done so fast. I don't even think any code for writing to LRLE had been shared here at all yet when the S4S update went up. And given that there's very likely a patch coming out early next week or the week after, and we have very little idea what will be in it, that was probably a real smart plan.

(I like this method, though. So often I don't even hear that something big is in the works before it's done, let alone know anything about the development, but here I got to follow along, and the fact that I wouldn't know an op code if it bit me in no way diminishes my enjoyment of getting to watch and sometimes particpate in the process.)

And now we all get to enjoy the results of your respective work! I have crossed a couple of previously-planned recoloring projects right off my to-do list (I definitely don't need to recolor my favorite subtle lipstick to go with occult skintones any more now) and I'm currently turning the textures from my default eye set into hue and opacity adjustable face paint for basically infinite eye colors. (Those I probably will still recolor, though, because then I'll have a larger number of eye colors available without using up a makeup slot... but now I wonder if it'd be possible to export textures from the custom swatches we create and save in-game somehow. I suppose I'll have to see if I can figure out where it's keeping them, and whether it actually saves them as textures or just data... ooh, pretty sure I found something... but do I have any idea what to do with it? No, no I do not.)

At the moment I am playing with the shiny new toy, but I'm only on the clock a little bit tomorrow to run a virtual holiday party, and then I can do some testing. Get some rest!

I passed that on to him, thanks.

This is the first time I've attempted a publicly collaborative project like this turned out to be, and it worked out better than I'd hoped!

I've been poking at the mipmap resizing and having some luck keeping the number of unique pixels down while retaining quality in the higher mips. I may try writing my own low quality resizing routine for the lower mips. Looks like at least some images are converting into LRLEs that are significantly bigger than the EA originals so we need to check if the opcode stream is inflated somehow.

I'll see what I can do to optimize color ordering. That I know causes opcode inflation.

Makes sense. I'll wait for you and then test and fiddle some more.

Here is what I got done so far. What is produced is still bigger than EA files but not quite as bad. On the plus side Encoding is much faster and, because I needed it to test some things, we can now dump LRLEs to dds files. The code is even more of a mess though.

Thank you! It is much faster which is a big improvement. I've tweaked the resizing to try to get an acceptable trade off of size vs quality of the first couple of mipmaps. Oddly enough, while some textures get bigger than EA, at least one gets smaller. Maybe someday one of us will figure out what's causing it. Tomorrow I hope to feel up to starting on updating my tools.

Edit: It really bugs me that many of the output lrles are so bloated. I may try writing the conversion from scratch again just to see if it turns out different.

Son of Edit: Updated with the latest version.

I've figured out a cause of the bloat. A pixel that should have gone to repeat run was being put in a copy run. Assuming I have not screwed any thing up, any other bloat should be caused by color ordering.

It's certainly better - most images get bigger but not as much. I'm uploading the new version.

Unless I've missed something this is the best I've got without spending more time than I want to on it. I've figured out a color ordering that seems to beat EA's in some cases and I've minimized the length of inline color runs.