Jump to content

Markie

Member
  • Content Count

    21
  • Joined

  • Last visited

Reputation Activity

  1. Like
    Markie reacted to EVERGREEN in Proposal: "Debloated" Installs (Remove unused files)   
    Today more than ever, (fast) storage space is expensive. One thing that always makes me mad is the insane amount of unused Localizations, game modes (often dead/closed multiplayer modes) that are installed by default - this is literally dead content. Wasted storage. Wasted money.
    Now back in ye old days, it used to be a gigabyte at best. Not the end of the world, and not exactly worth the time investment. But old habits die hard, and I'm still doing it today.

    With games becoming larger and larger, storage has become an issue that can thankfully be alleviated. 
    I'm going to list a few interesting examples, then propose a solution and finally suggest a way to integrate it to PCGW's structure. I'll also list a couple of issues with my proposal, potential flaws and uses cases etc. If you have a better idea or any suggestion to make this a thing, you're more than welcome.

    Please note that all the numbers given are taken from Steam, but GoG, Uplay, EGS & Origin are guilty of the very same thing. Uplay's even worse, as always. 
    Any constructive feedback would be much appreciated - I never suggested a feature before, but this one has been on the back of my mind for at least a year. I feel like it could be very useful to many folks out there.

    So, let's get to it. Those are easy ones to "clean-up" (more on that later):
    Batman Arkham Origins. Had a multiplayer mode, servers are down. Delete one folder and the install size goes from 27.06Gb to 18.1Gb. 9Gb (33%) saved Final Fantasy XIII. Well documented, check the PCGW entry for it, you can remove ~20Gb if you don't want the Japanese audio. 57.6Gb to 37.7Gb. 19.9Gb (52%) saved (!!!) Doom 2016. Do you really play the MP or Snapmap modes? That's ~15Gb (11Gb if you only delete the MP) saved. From 69.68Gb to 54.68Gb. 15Gb (21.5%) saved Here's the problem. I can manually delete all localizations, "deluxe edition content", Readme/Support and redists safely from most MT_Framework, UE3 and Ubi games just fine because they use the same naming conventions. All I have to do is search in the root folder for any file with the _ita. suffix for instance and delete it - but that's because I know what I'm doing and I'm willing to take the time to locate and delete those files. 
    Listing that would massively bloat any page of course, and not many users would do it anyways. 

    The best way I can think of to implement a reliable and simple method to delete files that we're absolutely sure are safe to delete goes something like this:
     
    Add a "debloatable" boolean to the Other Information infobox, If True, how much can be shaved-off at best. Users like myself could build a database of games we know we can "shave" (much like SK/ReShade compat, with a dedicated page) The end user would download a batch file, hosted here and verified by members based on a template which would include one option for each localization, and a "clean-up" option (remove Readme, Deluxe content, redists if safe) So for instance, I can flag all the localization for Resident Evil 6 and write them down in the dedicated page. I don't have any experience making modular batch files like that however, so someone else would have to make a template. I can then edit that batch to point it to all the files we want to delete. The end user launches the batch file, delete all locales but the one he's/she's using and boom. That's money saved right there.
    I know there are programs that are much better than Win Explorer's Search feature - if we can feed such a program with a config file it should do the trick too. We'd still need to build a database though. 

    I do realize that I make it sound much easier than it may be, or that it may sound overkill if we're talking about a Gb at best. But for extreme cases like Doom 2016, Far Cry 3/4, FF XIII, the Arkham series, The Evil Within - huge games basically, it would be very helpful and hey, I'm already doing it anyways so might as well share it. There's also games like Battlefront 2 (2005) where you can cut the install size in half. It's about 5Gb (vanilla) if memory serves, about 2-3Gb when cleaned. 
    With that said, if anything I hope that this thread at least brings more attention to this issue. 

    Last but not least, to everyone: Happy holidays! I hope you're all doing well, and ready for more PCGW grunt work for this year to come.
    "Keep on keeping on". 
  2. Like
    Markie reacted to Aemony in Anisotropic filtering and anti-aliasing   
    @Marioysikax hit the nail on the head. Changing the vast majority of games to "hackable" when resorting to GPU-based overrides essentially dummies the "hackable" state down to not mean a thing. Especially now that GPUs also supports post-processing AAs like FXAA and such that can be performed separately after the game have been rendered without affecting anything in the game itself. It would also open up a question whether using third-party generic tools like ReShade should also simply suffice to set the AA field in particular to "hackable" -- and seeing how ReShade supports all D3D9, D3D10, D3D11, D3D12, and OpenGL games, and you can force FXAA in all of them, wieeee, let's set all to hackable!
    Basically, if you want the "hackable" and "false" states to mean nothing on such fields, that's the way to go forward. But if you want actual informative information, you need to exclude generic tools better covered in the glossary page from the "hackable" state, as we're currently doing.
  3. Like
    Markie reacted to Marioysikax in Anisotropic filtering and anti-aliasing   
    If my memory serves me correctly, the reason why it's like this is because in huge majority of cases, forcing AF works without any problems, so it would not serve anyone if all games had it either true or hackable. I know people who have set AF to globally forced on and even Microsoft is doing this with Xbox X. 
    Because if we only put false on games which have issues with forced AF, there would only be handful from thousands and thousands. 
    Also this way, hackable is reserved for per game methods so they are easier to see and find, so that if there's native way of doing things, that's usually preferred over external methods. 
    Also if it's been tested to not work, it's far easier to note games were forcing AF externally causes issues. 
×
×
  • Create New...