[Bug]: Noticeable hiccup when loading the next track section

[Tenome]

Tweaks version

0.4.2 action build e7016a8

Describe your issue here (please attach the OutRun2006Tweaks.log file with your report, you can drag+drop it into the text area)

Edit: All right, I did some testing and narrowed it down. It indeed seems to be SceneTextureReplacement = true that's causing it, but I only have a couple billboard texture replacements, which shouldn't cause this much of an issue right?

I was doing time attack, and noticed that whenever I approached the next track area/loop, there would be a brief one-frame freeze as it presumably loads the next area. I suspect this might be related to the new loading speed hack that was implemented to prevent the next area from not being loaded at all. I'll experiment with it more later (mess with the settings) and try to get a video.

I tried the next level, and I didn't get the hiccup, so it seems like this level is resource-intensive when loading? Time attack singles, Outrun, Imperial Avenue.

https://streamable.com/vzepck

OutRun2006Tweaks.log

INI settings:

https://pst.innomi.net/paste/5h9o6ms737omte6urfape6v2

[Outrunner24]

I did some testing and narrowed it down. It indeed seems to be SceneTextureReplacement = true that's causing it, but I only have a couple billboard texture replacements, which shouldn't cause this much of an issue right?

You sure those billboards aren't too big/uncompressed/wrong size etc? Even a small difference in the file format can make loading the new assets longer, and there's your extra lag.

That said, I've had this glitch for years in OR2006 no matter the setting and even with the OG files. It seems to be linked to the HDD you're using or the type of memory it's streaming track data from.

[Outrunner24]

Isn't this the same as #49? It also happens with vanilla textures.

Nope, #49 is about the environment not loading (prolly a driver bug for that user).

But yeah, like I said these "frameskips" have always been there since the original release.

[Tenome]

I probably had the wrong compression setting, I was just unaware it would cause such a noticeable hiccup. I'm on an new NVME drive for reference. I'll make a new one and try again.

[emoose]

Loading stutter is a known issue with stage texture replacements sadly, there's no kind of pre-loading of textures right now, so texture only gets loaded from disk when the game actually tries drawing it, inside the main thread...

Tried a few ways of caching them first but it didn't really help too much, the game is also 32bit so we can't cache too many textures in memory else we'll hit the 4GB limit :(

Got an idea about trying to hook games loading thread, so that when it tries loading in a stage .gz file for the first time it could also scan textures/load/[stage gz filename]/ and load them all in, hopefully might reduce it a bit.

[Tenome]

Don't worry too much about it if it's a pain in the ass, I had a DXT5 when it should have been a DXT1 so that was most likely it.

[DonelBueno]

@Tenome DXT1 textures doesn't stutter on your system?

DXT1 looks like crap on textures with alpha channel and most of the game's textures seem to use DXT5.

[Tenome]

@Tenome DXT1 textures doesn't stutter on your system?

DXT1 looks like crap on textures with alpha channel and most of the game's textures seem to use DXT5.

The billboard seems to be DXT1, unless they were dumped incorrectly or Honeyview is wrong. I haven't tried DXT1 billboards yet.

[DonelBueno]

So it probably uses DXT5 for textures with alpha channel and DXT1 for the rest.

It stutters pretty badly here with upscaled environmental textures, maybe if I upscale them respecting the original compression setting it gets better (all of the upscales are using DXT5).

Some modes stutter way more than others, heart attack mode is the worst here.

[Tenome]

Matching the original compression is probably for the best. I tried it again with DXT1, the stutter was almost imperceptible this time. My billboard texture is 1280x640 so perhaps that's too high for a billboard as well (just didn't want it to look blurry). Or perhaps a microstutter is just a side effect of loading new environment textures that we'll have to contend with for now.

[DonelBueno]

Using DXT1 will also lower the file sizes. Does anyone know a tool to sort textures acordding to their compression setting? So I can upscale all the DXT1 textures without having to look one by one.

[Tenome]

Using DXT1 will also lower the file sizes. Does anyone know a tool to sort textures acordding to their compression setting? So I can upscale all the DXT1 textures without having to look one by one.

Not off the top of my head, but img2dds.exe can print information about DDS images. If you run a batch script and tell it to print the info to a txt, you can then get a list of files. In Windows, a basic recursive script would be for /R %%f IN (*.dds) DO "path\to\img2dds.exe" -I "%%f " >> out.txt

The results will look like:

E:\Game Mods Data Extraction etc\Convert Image to DDS\img2dds\16729EC5_128x64.dds RGBA 512x256 1 mipmaps E:\Game Mods Data Extraction etc\Convert Image to DDS\img2dds\19CEDB9_512x512.dds DXT5 512x512 10 mipmaps E:\Game Mods Data Extraction etc\Convert Image to DDS\img2dds\1C5326FF_128x128.dds DXT5 512x512 10 mipmaps

On that note, I wonder what would happen if you compressed it as BC7 instead? It's the same size as DXT5 but it should look better.

[Tenome]

Nevermind, the reason is was loading so fast...is because it wasn't loading at all! lol. So I guess my initial assumption about the game not supporting them was right. Well, I'll still post the tools here in case anyone doesn't know about them.

I just tried BC7 compression and had zero stuttering compared to DXT1/DXT5. There are probably other tools, but this is what I used to convert. I was wondering if it would work since it's a newer compression method.

https://forums.dolphin-emu.org/Thread-custom-texture-tool-ps-v52-5 or https://github.com/bj-rn/texconvgui/releases (has batch)

[DonelBueno]

Yeah, I've tried BC7 here on the UI textures and it was all broken LOL

[Tenome]

I wonder if it would be possible to hack in wider texture streaming support?

[DonelBueno]

About the stutters, they are completely CPU bound and single-threaded, so an NVME won't help, I'm also using an NVME here (Samsung 980 Pro)

[equinoxe3d]

Loading stutter is a known issue with stage texture replacements sadly, there's no kind of pre-loading of textures right now, so texture only gets loaded from disk when the game actually tries drawing it, inside the main thread...

Tried a few ways of caching them first but it didn't really help too much, the game is also 32bit so we can't cache too many textures in memory else we'll hit the 4GB limit :(

Got an idea about trying to hook games loading thread, so that when it tries loading in a stage .gz file for the first time it could also scan textures/load/[stage gz filename]/ and load them all in, hopefully might reduce it a bit.

Ah that's nice to know, thanks!

I'm using the upscaled environment textures by jojo670 and getting big stutters between stages despite loading from my SSD. However, the visual uplift is worth the tradeoff to me and I just blamed it on my very old PC.

Interestingly the second playthrough of the same stages load fine with minor or no hiccups even after quitting and restarting the game, so most of the stuff stays in memory (or VRAM) which was giving me hope for a precaching mechanism.

With all texture packs in the release thread I'm never going above 1.8GB on VRAM usage at 4K rendering, and system memory seems to be way below the 32-bit limit.