1st attempt it encoded only 356 of the 534 games. Since 313 of those were png converted to webp, I converted those back to png to see if that would change things, but while comparing image names, I saw it had done webp's too before I reconverted those back to png's.
2nd attempt it encoded only 135 images, and no matter what I did, it didn't do anymore. But while creating this post I checked back and somehow it actually had come alive again as the count had risen. But stopped again at 319... (see *NOTE)
Now as I said, I found an easy way to check which it had done. The bad news is none of the encoded image's show. All I get to see is a black area. And it's that black area which revealed which it had encoded.
I discovered that if I opened the More Info popup and scrolled through the list, for every image it had encoded, the black area had the aspect ratio of the original image. For those images that still weren't encoded, the black area was a square (verified by checking ID's against encoded images)..
#NOTE: Then I noticed that whenever I scrolled through images showing a black square, the encoded count went up again. Contrary to this, when I switched to grid view (middle button) scrolling through the list had no effect on the encoded count.
this whole things sounds like trying to link your actions to some meaning where there isnt. whats most likely happening when it appears to be stuck is it is compressing a gif. each frame needs to be converted to png first then compressed to astc, so gifs take a few orders or magnitude longer to compress than normal images. when you said it was stuck at 313, then when it was at 135 and stopped then came back alive, and then when you were scrolling through the more info popup, i believe all of these were cases where it was compressing a large gif image (which using sse2 and the relatively older cpu made even slower than one would expect) but you interpreted it as being stuck, then something else you did coincided with it finishing encoding that large gif and thus moving onto the next image.
Since 313 of those were png converted to webp, I converted those back to png
webp is not supported by astcenc but it should be by pillow, the checker converts to png temporarily using pillow as an intermediary for astcenc
The bad news is none of the encoded image's show. All I get to see is a black area. And it's that black area which revealed which it had encoded.
I discovered that if I opened the More Info popup and scrolled through the list, for every image it had encoded, the black area had the aspect ratio of the original image. For those images that still weren't encoded, the black area was a square (verified by checking ID's against encoded images)..
this makes sense, after compressing and loading from .aastc file it knows the size of the image so it draws the right shape, but then looks like opengl didnt like the texture format. the black square is just a placeholder 1x1 texture (resized to fit the more info popup) while images load (same one that was always there, just that first compression takes longer than loading from file so you noticed it now). i feel like changing it to text that says "Loading..." or a loading spinner is unnecessary and distracting, if youre scrolling by with images slowly loading all that text / spinners doesnt bring much info, and is just distracting, so simply showing a brack image when it is still loading but not yet failed is the best solution. as for why even after loading the compressed image it shows black for you is a separate topic, will need to dig deeper to find a way to fix it or detect it to show an appropriate error
So, after 45 minutes of scrolling and waiting till it had done all, the total count became 532 out of 534 entries. Turns out I got two tools in my list that don't have a banner.
well thats atleast some "good" news, compression worked fine, even if slow. that is of course offset by it being a one-time thing, and from now on it will be 1 or 2 images getting compressed at a time when they get updated. also i suppose it would be wise to add a status message to bottom right like "Compressing X textures..." (where each frame in a gif counts as a texture, so the counter is proportionate to processing time), would also help the uncertainty of what is happening that i explained in the first paragraph.
Conclusion. apart from uncovering a bug, ASTC is not something I can use. Encoding works, as I said, but displaying the result is a total failure. (*Tacent however does show them, so it does something other than directly dumping them to the GPU)
ill have to look at how tacentview does it then
Final note... If I turn off ASTC Compression, it does not load the originals, not even after removing all .aastc files. Here yet another suprise surfaced... it actually did load some and it turned out these were all animated gif's. All the rest just stays a solid black area.
Ah, Now this is a situation where you DO need to have Unload off-screen checked. Doing so immediately made it reload the original images.
toggling the astc compression checkbox, or the astc replace checkbox, will unload all images and reload them from file. i supposed i forgot to add a check to make it prefer the original file instead of the .aastc file when the toggle is off, i will fix that.
what happened here as far as i can tell is:
- you disabled the toggle
- it reloaded the images, but it still preferred the .aastc ones (this is a bug, will fix it)
- you deleted the .aastc files, but did not trigger the program to reload the images (as far as its concerned, they are already loaded, just your gpu cant show them)
- unloading off screen triggered the reload. its not at all required to disable astc compression, i simply forgot to make it avoid .aastc files when the astc compression toggle is off. with that bug fixed, then simply toggling off astc compression will reload all images and use the original files instead of .aastc even if present
EDIT: Almost forgot the most important thing.
No errors showed, neither in the Checker nor in the debug console
yeah hard to say why, i wouldve imagined the gpu wouldve just errored saying astc is not supported and the opengl error wouldve crashed the main loop... but then again tacent view loaded it... will need to look more into it.
EDIT: fixed the priority, now .aastc is avoided if the settings is disabled, prefers .gif first then any other format that is not .aastc. but will use .aastc if no other format is present.
also added a counter for image compression, but i realize that with how its currently architected, it can only process one image at a time, so it cant know how many frames the next images will need to compress (they might not have anything to compress even), so it would always show "Compressing 1 texture" when actually theres many images that are queued to compress. only gifs would show a varying number, as they have multiple frames.
what i think ill do is show "Compressing images..." generically when the counter is exactly one, since thats the case for static images and you can actually see that message blink when it finishes one image and moves to the next. for gifs ill make it "Compressing x frames..."
EDIT: did those, also fixed the flicker when clicking the arrows (i had noticed it long ago and never cared enough, thought it was imgui closing the popup, but it was actually due to how i was telling it to do so). and also made it always show a scrollbar in more info popup so width doesnt keep shiftin when changing the tabs or cycling through games
so of all things reported here, only the fact that your gpu doesnt like the astc textures is missing hmmm
