Tool Others F95Checker [WillyJL]

[ascsd]

Unfortunately that's how it is, banner images are very high quality and the program allows you to zoom a lot into them. With the imgui paradigm this means sending the full resolution texture to the gpu. You can compress the images on disk for yourself to lower both disk and gpu vram usage, and I plan to implement something like this in the tool eventually but it's low priority. Also I hope it's just vram you mean, it used to handle images a bit weirdly in the past, it would keep the texture data in ram if images were shown for a moment then hidden, now it properly passes to gpu.

but yeah keeping all images in vram is a bit of a problem. Not sure what is the correct way to handle it. Loading them is slow, and just having them unload when they go off screen seems like it will just make it horrible to use as it keeps loading images all the time.
As always cache invalidation is the unsolved computer science problem

cant remember if we talked about this suggestion before.. saving a thumbnail sized jpg alongside the original. if gifs are an issue, maybe even choose the middle frame to save as jpg?

cost of jpg storage size should be a small price to pay compared to limited vram.
I have 100 games, none animated, uses 1gb of vram so not directly affected by this, but i imagine the people with 1k+ games would suffer even from stills, let alone gifs.

use thumb for refresh button and grid view, which stays loaded in vram. while full res is loaded when game is opened, and unloaded when closed (if thats too slow, if loading can be done async/threaded you could possibly preload the full size on hover and unload on unhover if that isnt too demanding. possible optimisations are debounce or load queue of size 1 that gets flushed out on selection change so only last hover gets preloaded)

updated games could also be preloaded for the update popup

 

[Versace217]

WillyJL This is just me throwing an idea out; would it be possible for the F95checker itself to add the update date whenever a new version gets released? I saw 6 games versions get updated but only the dates of 3 games were entered correctly.

Having the system itself enter the date on the day a new version gets released would remove any human error from F95's mod team.

 

[WillyJL]

WillyJL This is just me throwing an idea out; would it be possible for the F95checker itself to add the update date whenever a new version gets released? I saw 6 games versions get updated but only the dates of 3 games were entered correctly.

Having the system itself enter the date on the day a new version gets released would remove any human error from F95's mod team.

not viable. neither the checker nor the api fetches info for threads when they are updated. they are fetched when someone refreshes their list and they have it in their list. so if an update happened last year but no f95checker user had it in their library, the date would be today, even though the update was last year. please drop this matter. it is an unsolvable computer science dilemma. i am fucking tired of all this crying about some stupid date. use a more reliable way of sorting, like the checkboxes, to sort by whether you have played the update, not when the update was released.

 

[WillyJL]

cant remember if we talked about this suggestion before.. saving a thumbnail sized jpg alongside the original. if gifs are an issue, maybe even choose the middle frame to save as jpg?

cost of jpg storage size should be a small price to pay compared to limited vram.
I have 100 games, none animated, uses 1gb of vram so not directly affected by this, but i imagine the people with 1k+ games would suffer even from stills, let alone gifs.

use thumb for refresh button and grid view, which stays loaded in vram. while full res is loaded when game is opened, and unloaded when closed (if thats too slow, if loading can be done async/threaded you could possibly preload the full size on hover and unload on unhover if that isnt too demanding. possible optimisations are debounce or load queue of size 1 that gets flushed out on selection change so only last hover gets preloaded)

updated games could also be preloaded for the update popup

i dont see how this would help. gpu does not speak jpeg. it speaks pixels. any image file is decoded and rendered to a pixel bitmap and transferred to gpu. no matter what file fortmat or compression you use for the image file, what the gpu has to store will always be the same size for the same width and height in pixels. only thing that will change with image format and compression is disk space, and ram usage while its between cpu and gpu, but once its on gpu vram is removed from ram.
also, if you mean using lower resolution images, then no grid would not be able to use them, as you could keep a low amount of grid columns and keep the window fullscreen, now the grid images are huge and would look horrible at a lower resolution. only place where lower resolution would help are refresh button on hover, and updates popup. the amount of complexity it introduces is not worth the savings.
what im considering to investigate is if theres some way to optimize how theyre actually stored in vram (consider game textures, theres 4k texture mods and they have so many textures, yet they work with today's gpus), and to see if convertin to bitmap on disk would help load times in exchange for disk space. if so, could possibly just store bitmaps and unload as soon as images are not on screen

 

[Dukez]

i dont see how this would help. gpu does not speak jpeg. it speaks pixels. any image file is decoded and rendered to a pixel bitmap and transferred to gpu.

Speaking of the GPU since I have a unique problem that results in your program turning into a white screen when using newer AMD drivers in a virtual machine setup (that I'm once again trying to figure out a way around without reverting drivers lol), I was searching through the thread here and saw there is apparently a way to disable F95Checker from using the GPU but it was in Linux using some chromium command.

However I use Windows and not linux so is there a way to do this same thing, launch the program with the --disable-gpu line?

I can disable the GPU entirely in Windows but then the program doesn't open at all and using the debug launcher shows the error "Could not initialize window" which makes me assume it needs a GPU and doesn't have like a software rendering fallback?

My driver issue extends further than just you're program though, renpy games get the same thing but if you hold shift while opening the game you can switch the render. So just for informative purposes, renpy games work fine for me on this driver if I'm using the ANGLE2 renderer but not the default GL2Renderer - that gets the white screen too.

Obviously this is an AMD issue first and foremost, I'm just trying to figure out a way to get things working since it's a very driver issue that only affects your program and renpy, one of which I can work around easily lol. It made me test out an older version of your program and I got a slightly different error with this one. "GLFWError: (65542) b'WGL: The driver does not appear to support OpenGL'". I guess this is more to the point and I'll have to research it, but is there a way to change how the program renders itself built in or not, probably not I'm guessing? I am still curious if the disable-gpu thing would work since the post here mentioned it did work for them but that was under linux.

 

[estrada777]

the tool is made for users managing games theyre playing and keep track of what they have installed and played and so on. i understand that this isnt exactly what you use it for, but youre the minority here then and i cant change the behavior yet again just for you. if you explain better what exactly is your workflow i can suggest a way to use the checkboxes in a way that makes sense for you.

from what i understand you do game ports and modding right? i would imagine you need to download games to do these things. here is what i imagine could work:
- download an update, then mark as installed (checkbox fully set), this will make the finished checkbox half set
- port and mod the version you just downloaded, then mark as finished (checkbox fully set), now youre done with this game until next update
- when an update happens, the installed checkbox will be half set, as you do not have the latest one installed
- again from the start: update it, then mark as installed
- now finished checkbox is half set, because you havent made ports or mods or whatever for this new version you just downloaded
- port and mod this update, then mark as finished, done until next update
you know which games have been updated by the half-set installed checkbox, and you know what you still need to port/mod by the half-set finished checkbox. you cant port/mod the games without downloading, so first step is downloading the update.
if you dont usually keep games installed after youre done modding them, then just delete the files after marking as finished. the tool will remember you marked it as installed and finished for that version, regardless of what files you have downloaded, thus it will still tell you about an update with the installed checkbox being half-set.

if this is not the kind of workflow you need then ill need more information to understand how to help you use it effectively

I think I know what is happening that I didn't fully understand. First, I use filters. I filter out the games that I have marked Finished. When a new update comes in, sometimes the Finished box is checked and sometimes it is not, so my filter is causing it to disappear from my list even though I haven't done anything with it yet.

Is the Finished filter aware of the three different states or is it only a two state filter?

 

[WillyJL]

Speaking of the GPU since I have a unique problem that results in your program turning into a white screen when using newer AMD drivers in a virtual machine setup (that I'm once again trying to figure out a way around without reverting drivers lol), I was searching through the thread here and saw there is apparently a way to disable F95Checker from using the GPU but it was in Linux using some chromium command.

However I use Windows and not linux so is there a way to do this same thing, launch the program with the --disable-gpu line?

that was when talking about the integrated browser, its an argument passed to it. its equivalent to passing this argument to chrome.exe. doesnt apply to f95checker itself

I can disable the GPU entirely in Windows but then the program doesn't open at all and using the debug launcher shows the error "Could not initialize window" which makes me assume it needs a GPU and doesn't have like a software rendering fallback?

as far as i know, "software rendering" just means that its not using a gpu but the cpu as a gpu. its still using a "gpu", just changes whether its the cpu in a gpu coat, or an actual gpu. what youre doing is disabling the gpu entirely, so there is no gpu

My driver issue extends further than just you're program though, renpy games get the same thing but if you hold shift while opening the game you can switch the render. So just for informative purposes, renpy games work fine for me on this driver if I'm using the ANGLE2 renderer but not the default GL2Renderer - that gets the white screen too.

this tells me that its not an issue with the gpu driver in general, and youre not making renpy games disable gpu rendering i would assume. to me it sounds more like youre making the gpu use a different renderer, but still using a gpu. i would imagine that disabling the gpu like you tried for f95checker would make renpy games fail to work aswell

Obviously this is an AMD issue first and foremost, I'm just trying to figure out a way to get things working since it's a very driver issue that only affects your program and renpy, one of which I can work around easily lol. It made me test out an older version of your program and I got a slightly different error with this one. "GLFWError: (65542) b'WGL: The driver does not appear to support OpenGL'".

to me it sounds like these new amd drivers have broken opengl. opengl is not the only language gpus speak. but it is the only one f95checker speaks. implementing more graphical backends is for all intents and purposes out of the question, opengl is the most basic and accepted standard for these simple graphics. implementing more is way too complicated and would invalidate a bunch of code we already have (for example, everything to do with images is opengl specific, and the window itself is glfw which is opengl only)

PS: i looked at renpy source code, theyre using sdl via pygame, not glfw. angle is a translation layer from opengl es to native operating system calls, sdl supports this, glfw doesnt, let alone pyopengl or pyglfw. also there is no option to enable software rendering in these libraries.

i have spent far more time investigating this than i wanted to, and got no further than i knew previously really. rewriting everything to another graphics library is out of the question. basically im telling you youre on your own on this issue. wait for amd to fix it or whatever

 

[WillyJL]

Is the Finished filter aware of the three different states or is it only a two state filter?

 

[estrada777]

View attachment 4365809

Ah, I wondered what outdated meant.

So a game that I previously marked as Finished, gets an update and is supposed to get the Finished half check. But what I've been seeing is that sometimes these games are getting the full check, and in my case get hidden by the filter.

 

[ascsd]

i dont see how this would help. gpu does not speak jpeg. it speaks pixels. any image file is decoded and rendered to a pixel bitmap and transferred to gpu. no matter what file fortmat or compression you use for the image file, what the gpu has to store will always be the same size for the same width and height in pixels. only thing that will change with image format and compression is disk space, and ram usage while its between cpu and gpu, but once its on gpu vram is removed from ram.
also, if you mean using lower resolution images, then no grid would not be able to use them, as you could keep a low amount of grid columns and keep the window fullscreen, now the grid images are huge and would look horrible at a lower resolution. only place where lower resolution would help are refresh button on hover, and updates popup. the amount of complexity it introduces is not worth the savings.
what im considering to investigate is if theres some way to optimize how theyre actually stored in vram (consider game textures, theres 4k texture mods and they have so many textures, yet they work with today's gpus), and to see if convertin to bitmap on disk would help load times in exchange for disk space. if so, could possibly just store bitmaps and unload as soon as images are not on screen

jpg was for storing the thumbnails to reduce size since u'd be adding another image alongside the original image. just so this change doesn't have a big impact.

I meant lower res, to reduce vram usage. my grid is 3 columns and forgot its customizable so I thought you could get away with smaller..
Id say only low column grids need the larger images, so you could just treat it as an outlier, or even have a system that checks image size and choses the low vs high res image, that way they are not hindering optimisation for the small images.
In saying that, im giving all these suggestions in a optimistic vacuum, i know you might not have the time

as for storing as bitmap, storage size might balloon real quick, but im sure you'd already test that beforehand

onto a more promising path:
did a quick search, opengl supports texture compression which seems to be alot better than simple lower res resize.

You must be registered to see the links

DXT1 seems to be popular, not sure if there is a newer compression format thats taken over nowadays

You must be registered to see the links

glfw should support glCompressedTexImage2D? havent checked, but more importantly idk if its exposed to imgui

 

[WillyJL]

So a game that I previously marked as Finished, gets an update and is supposed to get the Finished half check.

for the 4th time now, no, this is not what is intended to happen at all. the *installed* checkbox is half-set after an update. as you do not have the latest version installed. the finished checkbox indicates if what is installed is the same version that you finished. when theres an update, it doesnt magically install a new version, therefore the installed version is different than latest version, causing a half-set *installed* checkbox, but since its still the same installed version that you had marked as finished, finished is still fully set, as you did not install any new content to be marked as finished. youve already finished what you have installed. only after changing the installed checkbox from half set to fully set, the installed version will differ from the finished version, and thus the finished checkbox will be half set.
the filter you have was suitable for the old behavior, not the new. for 4 times now ive been asking you what the workflow was and repeating the same explanation that frankly it seems you never even bothered to read, but finally we know the sacred workflow you use, that my previous explanations wouldve explained to actually do the opposite of what you wanted if only they had been read.

snarky comments aside, i take it that you want to only see games you need to do whatever with, then when youre done with them hide them until the next update.
this is not really possible with the current filter system if you use both checkboxes (after an update installed is half set, then after installing the update the finished checkbox is half set) as filters do not have any logical "and/or" nor any grouping at this time.
i plan to have these in the future as part of the filter rework, but that is months if not even years away.
what you can do to preserve this workflow is change to using only 1 checkbox.
if the game is not marked installed (checkbox fully empty), the finished checkbox will relate to the latest version instead of the installed version (as there is none). this means you can use it as a simple marker for "i am done with this game" that gets half-set right after a game gets an update (again stress on the "if the game is not marked installed").
if this is what you want, you can proceed to:
- ctrl+a to select all games (repeat for all tabs if you have more than one
- right click > installed > click the X, this marks all games as not installed
- filter by finished, disable "include outdated", invert the filter (this will hide games that have finished fully checked)
now only games with finished half checked, or not checked, will show. and since all the installed checkboxes are empty, game updates will cause the finished checkbox to be half-set instead of the installed checkbox

 

[estrada777]

for the 4th time now, no, this is not what is intended to happen at all. the *installed* checkbox is half-set after an update. as you do not have the latest version installed. the finished checkbox indicates if what is installed is the same version that you finished. when theres an update, it doesnt magically install a new version, therefore the installed version is different than latest version, causing a half-set *installed* checkbox, but since its still the same installed version that you had marked as finished, finished is still fully set, as you did not install any new content to be marked as finished. youve already finished what you have installed. only after changing the installed checkbox from half set to fully set, the installed version will differ from the finished version, and thus the finished checkbox will be half set.
the filter you have was suitable for the old behavior, not the new. for 4 times now ive been asking you what the workflow was and repeating the same explanation that frankly it seems you never even bothered to read, but finally we know the sacred workflow you use, that my previous explanations wouldve explained to actually do the opposite of what you wanted if only they had been read.

snarky comments aside, i take it that you want to only see games you need to do whatever with, then when youre done with them hide them until the next update.
this is not really possible with the current filter system if you use both checkboxes (after an update installed is half set, then after installing the update the finished checkbox is half set) as filters do not have any logical "and/or" nor any grouping at this time.
i plan to have these in the future as part of the filter rework, but that is months if not even years away.
what you can do to preserve this workflow is change to using only 1 checkbox.
if the game is not marked installed (checkbox fully empty), the finished checkbox will relate to the latest version instead of the installed version (as there is none). this means you can use it as a simple marker for "i am done with this game" that gets half-set right after a game gets an update (again stress on the "if the game is not marked installed").
if this is what you want, you can proceed to:
- ctrl+a to select all games (repeat for all tabs if you have more than one
- right click > installed > click the X, this marks all games as not installed
- filter by finished, disable "include outdated", invert the filter (this will hide games that have finished fully checked)
now only games with finished half checked, or not checked, will show. and since all the installed checkboxes are empty, game updates will cause the finished checkbox to be half-set instead of the installed checkbox

I'll go with the one box solution.
Sorry for bothering you.

 

[WhiteVanDaycare]

simple_human rentalunshipped982 M0narh BrockLanders ascsd blackop Nerro MaxTheEro
thanks to FaceCrap finding

You must be registered to see the links

, sorting bug might be fixed
try build 1406 please
basically there is a bug where imgui can return corrupted sort specs if you check them when the specs arent dirty (havent been changed by user). i was doing this because changing tabs with "independent views" option would cause to have different sorting, but would not trigger the dirty flag as its technically just a different table, for which the specs did not change. now i only get new sort specs when dirty flag is set, and save them. meaning when changing tab it just uses the specs it had saved, not ones reported by imgui. and when you change sorting for a given tab, it saved the new specs for it for later use.
the imgui bug has been fixed, but pyimgui is on an older version. the usage i had before was supported by imgui, but not ideal. regardless this new system should be more efficient, and also avoid the bug.

This seems to have squashed the 'lost sorting' bug, hasn't recurred all weekend!

 

[GrammerCop]

On a separate subject, it would be very helpful if the software had a user manual. The easiest way to do this would be for WillyJL to set up a wiki and allow advanced users to build it. I think it would substantially reduce repeat questions and help users that don't ask but instead just give up.

Although F95Checker is fairly intuitive [kudos to WillyJL and his helpful associates, I agree it has evolved to be sufficiently complex to need SOMETHING.

As for myself, I don't use it except in the most basic manner to check all my games for updates. using it to launch my games would require rearranging my folder structure, which I am too lazy to do ATM.
Edit: Having said that, I will probably re-structure my folders anyway, just because I was already thinking about doing it.
I also don't use a lot of the other more advanced features mostly because I am unaware of them. I don't read this thread or the GitHub threads faithfully enough to be aware of all the advanced features which are currently the only places I know of that has any mention of them.

 

[WillyJL]

jpg was for storing the thumbnails to reduce size since u'd be adding another image alongside the original image. just so this change doesn't have a big impact.

I meant lower res, to reduce vram usage. my grid is 3 columns and forgot its customizable so I thought you could get away with smaller..
Id say only low column grids need the larger images, so you could just treat it as an outlier, or even have a system that checks image size and choses the low vs high res image, that way they are not hindering optimisation for the small images.
In saying that, im giving all these suggestions in a optimistic vacuum, i know you might not have the time

as for storing as bitmap, storage size might balloon real quick, but im sure you'd already test that beforehand

onto a more promising path:
did a quick search, opengl supports texture compression which seems to be alot better than simple lower res resize.

You must be registered to see the links

DXT1 seems to be popular, not sure if there is a newer compression format thats taken over nowadays

You must be registered to see the links

glfw should support glCompressedTexImage2D? havent checked, but more importantly idk if its exposed to imgui

starting to investigate this. picked 4 images from my images folder to test on. posting this as a reference for myself, to see what we can manage to achieve.
shows in order, file size on disk, texture byte size to send to gpu, and pixel resolution

(idk what happened with those floating brackets, powershell is tripping, they dont exist)
from what i found here

You must be registered to see the links

we might be able to achieve a 6:1 compression ratio with DXT1 (actually, maybe even more, that wiki mentions 6:1 from 24bit RGB to DXT1, but we're currently using RGBA which i assume is 32bit, so 32bit RGBA * 16pixel per chunk / 64bits per DXT1 chunk = 8:1 compression). but converting to that format might take time. will probably do something like, first time an image is loaded, if not correct format it gets converted then overwritten to disk. means all images will be .dds from now on, when this is all worked out. also, it mentions that DXT1 is an extension, not part of opengl spec, so might not work on all gpus?

EDIT: yep, 800% compression ratio

thats the first image, the 18.2mb on gpu and 5.8mb on disk. crazy how dxt1 gets even better compression than the original png image (btw thats "race of life" banner)
now next problem is that i used this wand library, its basically image magick. ideal would be to have just dxt1 conversion in python without extra dependencies, but pillow doesnt do that from what i can see. could maybe include the magickwand .dll / .so

 

[FaceCrap]

(actually, maybe even more, that wiki mentions 6:1 from 24bit RGB to DXT1, but we're currently using RGBA which i assume is 32bit, so 32bit RGBA * 16pixel per chunk / 64bits per DXT1 chunk = 8:1 compression)

Curious if DXT5 would do even better if sticking with RGBA. Don't waste time on DXT3, between the two of them DXT5 is the better choice anyways.
Although why RGBA..., yes it's 32bit but why waste 8bits that never get used? Transparency is just not a thing with image banners.
Less bits in is less bits out...

 

[WillyJL]

Although why RGBA..., yes it's 32bit but why waste 8bits that never get used? Transparency is just not a thing with image banners.
Less bits in is less bits out...

thats what it was before, not what im making it do now. for our application here, alpha doesnt matter. but when i was implementing images with imgui and opengl long ago, it just did not like RGB without alpha for some reason. it would always end up with a few buggy images that were skewed or incorrect colors. so i just made it do RGBA.

 

[WillyJL]

starting to investigate this. picked 4 images from my images folder to test on. posting this as a reference for myself, to see what we can manage to achieve.
shows in order, file size on disk, texture byte size to send to gpu, and pixel resolution
View attachment 4367392
(idk what happened with those floating brackets, powershell is tripping, they dont exist)
from what i found here

You must be registered to see the links

we might be able to achieve a 6:1 compression ratio with DXT1 (actually, maybe even more, that wiki mentions 6:1 from 24bit RGB to DXT1, but we're currently using RGBA which i assume is 32bit, so 32bit RGBA * 16pixel per chunk / 64bits per DXT1 chunk = 8:1 compression). but converting to that format might take time. will probably do something like, first time an image is loaded, if not correct format it gets converted then overwritten to disk. means all images will be .dds from now on, when this is all worked out. also, it mentions that DXT1 is an extension, not part of opengl spec, so might not work on all gpus?

EDIT: yep, 800% compression ratio
View attachment 4367520
thats the first image, the 18.2mb on gpu and 5.8mb on disk. crazy how dxt1 gets even better compression than the original png image (btw thats "race of life" banner)
now next problem is that i used this wand library, its basically image magick. ideal would be to have just dxt1 conversion in python without extra dependencies, but pillow doesnt do that from what i can see. could maybe include the magickwand .dll / .so

some preliminary vram results, with opening the tool to 12 collections gif banners:
background baseline usage before opening the tool: 1.6gb
no compression: 3.5gb (1.9gb used by the tool)
dxt1 with wand library: 2.1gb (0.5gb used by the tool)
dxt1 with opengl compression: 2.7gb (1.1gb used by the tool)
dxt1 with opengl compression and reapplying after compressing: 2.0gb (0.4gb used by the tool)
so yeah, 800% compression ratio between 1.9gb uncompressed and 0.4gb dxt1

what i gather from this is that dxt1 usage is same between these options, just with some caveats. opengl can compress in realtime, but seems like some of the uncompressed data is left behind. this is fixed by applying the texture uncompressed, letting opengl compress it, then reapplying the compressed texture. that gives 2.0gb, which id say is same usage as the wand library 2.1gb, probably just some background fluctuation on my pc in the meantime.

what im not super sure about is visual quality. dxt1 is lossy, i had not realized this when i started looking into this. it compresses in 4x4 pixel chunks, so after compression you can see some artifacts in some cases. its especially evident in gifs, where the different pixel chunks have slightly different color shades and are pretty visible. the original gifs already had some artifacts due to small color palette, but dxt1 makes it a bit more noticeable when zooming in. still tho, very much usable from what i can see. might make it only compress images above a certain resolution later on.

i cant really tell which would work best between opengl and wand, they both have some pros and drawbacks:
- opengl seems to cause more artifacts on smooth gradients, while wand seems to cause more artifacts around well defined shapes
- opengl compresses while applying the texture thus blocking the interface while compressing, wand is a separate step so interface is responsive during compression
- opengl is already here, wand would be a new dependency and a new dll to include and adds complexity
- opengl might compress differently between gpu vendors, wand would be same for everyone

overall the visual quality seems better with wand, and i think im leaning towards using that one. still tho, would be nice to get some feedback.
ive pushed build 1410 that includes some initial testing of these modes, you can switch between them at the bottom of the sidebar settings.
i am still trying to figure out how to bundle image magick, for now youll need to install it from

You must be registered to see the links

(any of the "dll" options) if you try this build.
KEEP IN MIND: images will load slower with compression. for now, the files on disk are left untouched, so compression is done every time the image is loaded. the idea eventually is to compress once, then store on disk, which will make images loading much faster and occupy less disk space. but for now, i am looking for feedback on vram usage and on visual quality of compressed images. once that is figured out and compressed textures will start being saved to disk, we might even be able to make it unload images when offscreen, if loading textures will be fast enough for that. would mean constant vram usage for how many are on screen, not exponential with more games in library.

Dukez FaceCrap ascsd

 

[FaceCrap]

might even be able to make it unload images when offscreen, if loading textures will be fast enough for that. would mean constant vram usage for how many are on screen, not exponential with more games in library.

personally speaking, I wouldn't like the images getting compressed written to disk. Especially if the deterioration in quality is visible when zooming in (thinking of a future slideshow option), and even more so if the original image is already compressed with a lossy format like jpg.

And regarding your final comment, if that would become possible, then why even bother with the whole compression complexity and the need to install a 3rd party bundle. Since that alone would already drastically reduce vram usage, not?

On top of that, we're talking VRAM, not regular ram, if it's there, use it. It's not like you're going to be needing it for something else much other than the VN you're playing alongside. Don't understand the problem folks have with it getting used. I can understand not keeping things loaded if offscreen, but that's a different issue.

Let's have some examples where the use of VRAM causes issues for other software. (where not compressing to dds, coupled with offloading if not on-screen, would still be an issue)

Guess I'm glad F95 doesn't have these hangups about storage, otherwise we'd seen them already converting the lot to dds.

 

[WillyJL]

And regarding your final comment, if that would become possible, then why even bother with the whole compression complexity and the need to install a 3rd party bundle. Since that alone would already drastically reduce vram usage, not?

The whole "unload images off screen" entirely depends on precisely the texture compression. Without it, images need to be decoded and converted for the gpu to understand. Writing compressed images to disk would mean no more conversion at all, just read from file and dump to gpu. Right now, it has to load the file, interpret it, convert it to RGBA if it's not, then make a huge pixel buffer for it, and dump that to gpu. Storing the converted RGBA pixel buffer to disk is also not an option, a 5mb image becomes a 18mb image on disk then, people already complain of how much space images take up, and I understand them, this is not doable. And even if, it would mean more data needs to be loaded from disk, which might even make slow hard drives even slower to load images as the bottleneck becomes disk io instead of cpu converting the images.

On top of that, we're talking VRAM, not regular ram, if it's there, use it. It's not like you're going to be needing it for something else much other than the VN you're playing alongside. Don't understand the problem folks have with it getting used. I can understand not keeping things loaded if offscreen, but that's a different issue.

ive had issues myself with running out of vram, and I have 16gb of vram, with not even that many games. With the previews feature on the horizon, keeping EVERYTHING in vram is absolutely not possible at all. It may be fine if all are compressed since it takes 8 times less space, but even more so if this simplification in loading without conversion will mean it's fast enough to load each time the images become visible, then nothing would need to be in vram unless it's on screen. O( 1 ) instead of O( n ) space required then. Games libraries can keep growing, vram can't. And you're wrong, people can, already have, and will continue to be affected by all this vram being used. There's a whole background mode, what if you play a modern videogame? These games already struggle to work with todays gpus, if my tool is in the background hogging half the vram it's a lost battle, that game you want is never launching.

Let's have some examples where the use of VRAM causes issues for other software. (where not compressing to dds, coupled with offloading if not on-screen, would still be an issue)

loading each time the image is shown and unloading when it goes off screen, without converting beforehand, is obviously going to cause issues. You already know how slow images can be to load. And some folks, me included, symlink their config colder to a spinning hard drive, which makes it even slower. Switching to animations tab I have takes for me close to 10 seconds to load all images since they're gifs. Now imagine that they always take that long to show up when you move around in the tool or scroll your list. That's a horrible user experience.

Guess I'm glad F95 doesn't have these hangups about storage, otherwise we'd seen them already converting the lot to dds.

thats a disingenuous comment and you know it. We're talking about vram which is very limited, and about user's drive space, which both are already causing issues with how much this program hogs of them as banner images are stored in high resolution. Obviously f95zone server will have enough space to store the huge files, that's what they are designed for, and its browsers that show the images, which are state of the art in showing images efficiently. We don't have this luxury, we're dealing with the equivalent of game textures and need to convert images to such a format before being able to show them. Storing the RGBA pixels on disk would mean no more converting, but then a 5mb image takes 18mb on disk, and in slow hard drive cases would maybe take even longer to load as the bottleneck becomes disk I/O instead of cpu converting the textures, which again would make loading each time the image is show unfeasible. So the only solution here to speed up image loading and lessen disk usage and vram usage is to compress. Atleast for large images. As I said, it could be enabled only for images above a certain resolution, where the quality loss I can't even notice myself, and lower quality images remain as is, but that's for later. Now it would be useful if you tried it and gave some honest feedback about how it looks compressed and how much difference you get in vram usage, in stead of making disingenuous comparisons like a grumpy grandpa (I'm sorry but that's how you sound here, just skeptical of change in any way without even trying it from what I can tell. If that's not how you meant it I apologize). Nothing is set in stone yet, but this is the general direction that I will likely take. Getting some good feedback will help this not be such of an issue and become a net positive for everyone.