When will TARGA streams be supported?

[jeffyjeffy1023]

I know the last release was in 2018, but still...

[ghost]

Never, unless you know how to code in the programming language it's written in lol

[jeffyjeffy1023]

:(

---

From: Sheik @.> Sent: Monday, March 22, 2021 9:12 PM To: RattletraPM/Snickerstream @.> Cc: jeffyjeffy1023 @.>; Author @.> Subject: Re: [RattletraPM/Snickerstream] When will TARGA streams be supported? (#66)

Never, unless you know how to code in the programming language it's written in lol

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/RattletraPM/Snickerstream/issues/66#issuecomment-804509412, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AK2WA3GR4TCWPLXBA55OSSTTE7TGNANCNFSM4ZN56IIQ.

[ChainSwordCS]

My friend and I are actually working on it, we hope to be finished in a few days or weeks.

[RattletraPM]

@ChainSwordCS If you're trying to implement it, I remember doing some experiments and stuff back in the day - no promises, but I might still have some code laying around!

A word of advice tho: one of the reasons I didn't end up completing TARGA support is that trying to decode TARGA with AutoIt is very, very, very slow. So much so that at some point me and Sono thought the only proper way to do it might have been to write an external DLL and calling it instead of native AutoIt functions. And if you think that TARGA games are already slow while being streamed via HzMod, well... yeah, imagine just how slow I'm talking about here.

At some point there were talks about a HzMod rewrite and that was also when I kinda started losing interest in Snickerstream, so yeah... that, coupled with what I said before plus some other reasons (2020 included) meant I just stopped working on it.

[ChainSwordCS]

@RattletraPM Sure, thanks. We will have a look. We actually already have a Python implementation, so maybe we will go the external route, but tbh I'm not the smart one lol.

[RattletraPM]

@ChainSwordCS All rightio, I did manage to find most of my old stuff: here

I thought I had gotten further before abandoning the feature but apparently all I had done is writing a function to decode an RGB RLE-encoded TARGA image written in pure AutoIT so, well... I don't know how useful you might find that alone. (FYI as WIC has no built-in TARGA support but a RGB888/RGBA8888 TARGA is essentially the same as a bitmap image, the idea was to first decode it to a non-RLE TGA and then convert it to BMP, which would be as easy as a header swap as you wouldn't have to touch the pixel data, and then feed it to WIC so it could be used with the Direct2D renderer). Still, there's also a benchmark program I made for that function and even if I tried all the tricks in my book to optimize it as best as I could, keep these test results in mind:

[20:58] Benchmark started, @AutoItX64: 0
[20:58] Time taken to decompress tga\bestcase.tga: 100.0095
[20:58] Time taken to decompress tga\randomtarga.tga: 178.0233
[20:58] Time taken to decompress tga\realscreen.tga: 537.0162
[20:58] Time taken to decompress tga\bestcase.tga: 60.1346
[20:58] Time taken to decompress tga\randomtarga.tga: 73.2821
[20:58] Time taken to decompress tga\realscreen.tga: 408.1622
[20:58] Time taken to decompress tga\bestcase.tga: 56.094
[20:58] Time taken to decompress tga\randomtarga.tga: 58.1222
[20:58] Time taken to decompress tga\realscreen.tga: 383.5263
[20:58] Time taken to decompress tga\bestcase.tga: 56.6037
[20:58] Time taken to decompress tga\randomtarga.tga: 54.5845
[20:58] Time taken to decompress tga\realscreen.tga: 551.9512
[20:58] Time taken to decompress tga\bestcase.tga: 60.1179
[20:58] Time taken to decompress tga\randomtarga.tga: 41.6252
[20:58] Time taken to decompress tga\realscreen.tga: 546.187
[20:58] Benchmark ended.

bestcase.tga is completely blank, randomtarga.tga has random colour values for each pixel and realscreen.tga is a screenshot taken from a real 3DS (all are 400x240 RLE-encoded images, results are in ms). These test results were taken on a computer running a Ryzen 9 3900X and, as you can see, it takes more than half a second to decode a single frame... and RLE decoding is just one of the various steps needed to get an image you can work with from HzMod (not to mention this is on a quite powerful CPU, the results would sometimes reach 700ms on my old Ryzen 5 1600). So yeah, I highly suggest you go ahead with an external decoding function instead of going ahead with a pure AutoIt solution, otherwise you may very well end up with seconds per frame instead of frames per second while streaming TARGA games =/

[Eiim]

@RattletraPM Hi, I've been doing most of the coding with @ChainSwordCS, although as I'm not very familiar with AutoIt it's been slow going and I started in python first (repo here).

I also figured a header swap to a BMP would make sense, but https://docs.microsoft.com/en-us/windows/win32/gdi/bitmap-compression suggests that you can only RLE-compress 4-bit and 8-bit images, while the HzMod TGAs we've decoded are 16-bit. Is there a way to RLE-compress a 16-bit bitmap that isn't documented there? Wikipedia mentions that a 24-bit image can be compressed, but that will still take some bit manipulation to convert to. I'm also not sure if 16-bit color data in BMPs is stored the same as in the TGAs, where it's 2 bytes in LE order, with the last bit unused/maybe a an extra bit of color depth for one of the colors that can probably be ignored.