You might try saving the .png files as you create them in a separate dir, THEN running the cruncher on just the new files before dumping the newly created webp files into your game.
That way you don't have to crunch EVERYTHING every single time.
You might try saving the .png files as you create them in a separate dir, THEN running the cruncher on just the new files before dumping the newly created webp files into your game.
That way you don't have to crunch EVERYTHING every single time.
hmm.. soo basically when i put an update out.. i could simply make a folder, put the pics in it and run that tool to compress the pics size ???
instead of using the game folder and let the tool scan everything over and over..
hmm.. soo basically when i put an update out.. i could simply make a folder, put the pics in it and run that tool to compress the pics size ???
instead of using the game folder and let the tool scan everything over and over..
recreation & macadam
This cruncher makes sense for us compressors working with games that are already "fully baked". The script has a "light touch", meant to avoid causing issues that would require modifying .RPY files to fix. If you already have years of content and don't want to mess with getting it to work, this script(or another like it) makes a lot of sense.
If you are making your own game and don't have a lot of old/legacy script to go over I'd recommend you just make sure your game is built from the ground around an efficient/compressed release. It'll save you time in the long run.
Pixieblink's recommendation does make sense. That is one way to keep everything organized.
One big recommendation I have for you is to make sure
You must be registered to see the links
is enabled and refer to images in your .RPY files using that method.
IE instead of:
Python:
\game\images\v1\sylvie\blue_giggle.png
Use:
Code:
sylvie blue_giggle
If you do that, it won't matter what file extensions you use and the game won't break as easily if you move folders/pictures around. That is important because you can actually track what has and hasn't been compressed by looking at the file extension. Not with this script though, since part of that "light touch" is preserving the .png file extensions, even if they are wrong.
No matter what you do, I recommend you always keep a copy of the original files around, just in case you need them in the future. Don't be like Toei/Funimation and get stuck with crappy 3rd generation copies for your Blu-Ray release.
recreation & macadam
This cruncher makes sense for us compressors working with games that are already "fully baked". The script has a "light touch", meant to avoid causing issues that would require modifying .RPY files to fix. If you already have years of content and don't want to mess with getting it to work, this script(or another like it) makes a lot of sense.
If you are making your own game and don't have a lot of old/legacy script to go over I'd recommend you just make sure your game is built from the ground around an efficient/compressed release. It'll save you time in the long run.
Pixieblink's recommendation does make sense. That is one way to keep everything organized.
One big recommendation I have for you is to make sure
You must be registered to see the links
is enabled and refer to images in your .RPY files using that method.
IE instead of:
Python:
\game\images\v1\sylvie\blue_giggle.png
Use:
Code:
sylvie blue_giggle
If you do that, it won't matter what file extensions you use and the game won't break as easily if you move folders/pictures around. That is important because you can actually track what has and hasn't been compressed by looking at the file extension. Not with this script though, since part of that "light touch" is preserving the .png file extensions, even if they are wrong.
No matter what you do, I recommend you always keep a copy of the original files around, just in case you need them in the future. Don't be like Toei/Funimation and get stuck with crappy 3rd generation copies for your Blu-Ray release.
Thanks for the explanation, but I already know that^^
All the images in my games are compressed to a degree, but not crunched, videos also use webm vp9 codec.
And yes, the settings of the cruncher are a bit too heavy for an official release version, I used a different version with higher settings for my 4k game to make a 1080p version.
If there's demand I'll look into doing RPGMCruncher.
The zip includes Mac versions of cwebp, ffmeg and nconvert. Linux users should install the relevant packages. Linux users shouldn't delete the Cruncher-Mac directory, because it contains webp-header-fix.py.
You need python 2.7.x to run this. I couldn't get Ren'Py's python to work, and I think having python is a reasonable requirement. Get it from
You must be registered to see the links
.
This has NOT been tested on Linux.
Like the PC version, this assumes you've gone ahead and extracted RPAs, so you have the image/audio/video files.
To run:
Mac: double click RenCruncher-v0.4.command. Drag the Ren'Py app to the terminal window and hit enter, or type in the path to the app.
OR
Mac: launch terminal
Mac/Linux: run RenCruncher-v0.4.command. You can pass in the game directory on the command line, or type it in when asked.
Flash001, thanks for reporting it - there indeed was a small error/bug in rpgm cruncher 0.4.1 (line 93 should end with ")", and line 105 should be deleted), affecting virtually not only the mentioned game, yet any rpgm game being compressed in a "classic" way (/ww/img/...). Attached is a "fixed" version (called 0.411 at this instance). I have tested it on a few more games. Please, let me know if that works for you as well.
p.s. bas if you are around please, dont bas me for messing with it
Flash001, thanks for reporting it - there indeed was a small error/bug in rpgm cruncher 0.4.1 (line 93 should end with ")", and line 105 should be deleted), affecting virtually not only the mentioned game, yet any rpgm game being compressed in a "classic" way (/ww/img/...). Attached is a "fixed" version (called 0.411 at this instance). I have tested it on a few more games. Please, let me know if that works for you as well.
p.s. bas if you are around please, dont bas me for messing with it
Will try the fixed version on the game that was causing the crash and let you know once I test. Thanks Abhai for fixing this!(or at least giving it a try )
Will try the fixed version on the game that was causing the crash and let you know once I test. Thanks Abhai for fixing this!(or at least giving it a try )
in order to speed up testing things a bit you could/should delete all folders apart parallaxes and system (lets say) from img-folder - and to do only images compressing
in order to speed up testing things a bit you could/should delete all folders apart parallaxes and system (lets say) from img-folder - and to do only images compressing
Flash001, thanks for reporting it - there indeed was a small error/bug in rpgm cruncher 0.4.1 (line 93 should end with ")", and line 105 should be deleted), affecting virtually not only the mentioned game, yet any rpgm game being compressed in a "classic" way (/ww/img/...). Attached is a "fixed" version (called 0.411 at this instance). I have tested it on a few more games. Please, let me know if that works for you as well.
p.s. bas if you are around please, dont bas me for messing with it
ok, have checked one of those games.
it has fairly reduced video 1080p files already, so by using standardized cruncher settings, you could reduce size by only 30-35%.
to play crunched video files (if you choose so), instead of flashplayer, use html5player.
ok, have checked one of those games.
it has fairly reduced video 1080p files already, so by using standardized cruncher settings, you could reduce size by only 30-35%.
to play crunched video files (if you choose so), instead of flashplayer, use html5player.
Just FYI... Scripts do not recognize AMD CPUs. The 32-bit and 64-bit checks fail. You can force it to continue by setting OS=64BIT on line 15, but otherwise it will fail. Attaching the registry key in case you want to alter it to search for AMD64 as well.
Just FYI... Scripts do not recognize AMD CPUs. The 32-bit and 64-bit checks fail. You can force it to continue by setting OS=64BIT on line 15, but otherwise it will fail. Attaching the registry key in case you want to alter it to search for AMD64 as well.
wow, are you really the first AMD user to try this script?
Uh, since I kinda "borrowed" that section of this script for my own, I'm gonna try and use you as my test subject. Please do me a favor and test this updated script and see if it works for you. I've changed the check to use a completely different method that should work for any CPU brand. If it works I'll have to update my own script as well...
