Great idea on the algorithm - that's one possibility I considered, actually! Depending on your requirements I'd say it's pretty good. It's way more memory-efficient than mine, though not as time-efficient, as usual you need to pick which of those to optimize :p But the real reason I didn't use that solution is that I'm too OCD to allow the textures to have inequal likelihoods to get randomized (each of the textures in the base folder is as likely to get selected as all of the textures in a subfolder together, and in subfolders, the textures in large texture packs have smaller likelihoods than ones with only a few textures in the same folder). Soooo, to fix this horrible inequality in the system xD, this is how mine works:
first it reads the entire folder structure starting from a selected base folder. It stores info on all the folders (how many textures in each), assigns them an index number range (as many indexes as there are textures in it), and then when there's info on all of the index numbers it's easy to just randomize using the indexes directly. And then go through the structure (I use a tree-like object cause it goes so well with a folder structure) searching for the folder with the index range where the random index falls, annd then I also check which of the textures it means (like if the range is 7001-7020 and the random index is 7005, I pick the 5th texture from that folder). Of course while this saves time at the randomizing phase, it takes a large amount of time at the start when you read the folder structure, so for this reason i also made it possible to save all this folder info in a settings file and then just read it directly the next time I open the program. This saves a lot of time, but that file still needs to be updated every time I download new textures. But it's a decent compromise.
However, if you're fine with not completely equal likelihoods for individual textures, I'd say use the algorithm you suggested - it's not only more memory-efficient but also probably easier to code :>
And yeah, you don't need a gui, opening them directly in PS works fine too. Actually the first version of the randomizer I made worked that way and it wasn't bad at all, I just got tired of closing all the files cause sometimes I need like 20 random textures before I find a good one :)
no subject
first it reads the entire folder structure starting from a selected base folder. It stores info on all the folders (how many textures in each), assigns them an index number range (as many indexes as there are textures in it), and then when there's info on all of the index numbers it's easy to just randomize using the indexes directly. And then go through the structure (I use a tree-like object cause it goes so well with a folder structure) searching for the folder with the index range where the random index falls, annd then I also check which of the textures it means (like if the range is 7001-7020 and the random index is 7005, I pick the 5th texture from that folder).
Of course while this saves time at the randomizing phase, it takes a large amount of time at the start when you read the folder structure, so for this reason i also made it possible to save all this folder info in a settings file and then just read it directly the next time I open the program. This saves a lot of time, but that file still needs to be updated every time I download new textures. But it's a decent compromise.
However, if you're fine with not completely equal likelihoods for individual textures, I'd say use the algorithm you suggested - it's not only more memory-efficient but also probably easier to code :>
And yeah, you don't need a gui, opening them directly in PS works fine too. Actually the first version of the randomizer I made worked that way and it wasn't bad at all, I just got tired of closing all the files cause sometimes I need like 20 random textures before I find a good one :)