Tool RPGM Ren'Py Cruncher - Ren'Py & RPGM MV Game Compactor [v0.4.1] [bas]

[agregen]

Hello - asking as there doesn't seem to be an obvious way to make this work. I want to compress RPGMV games in OSX. Is there a particular version or guide on how to do this? While working in OSX? I could probably do this on a pc, but want to set this up to do on a MacBook Pro...

The OP links to a version which is made for a Mac (marked as “Linux/Mac port” though the dev apparently hadn't tested it on Linux); it should probably work for you.
Alternatively you could try my version from a couple posts above (linked to in my signature); it should work but I've no way of knowing since I don't have a Mac . It has a few improvements and a manual of sorts (though I'm not sure how well it translates to Mac – at least the installation part; I guess you might need to add /usr/local/bin to your $PATH and use Homebrew to install packages).

Both of these versions run in command line (like the original does) – IIRC in goobdoob's version you're meant to type/copy-paste/drop the name of the unpacked game folder into the terminal, while mine is supposed to be run from within that folder instead.

…And yes, my version does support RPGMV games – both compression and decoding (see Features/Usage sections for more info).

 

[June Sunday]

Are there plans to expand the game engines supported?

 

[agregen]

Are there plans to expand the game engines supported?

Considering the last update was in 2019 – probably not…
I've made a few improvements to my port (including support for more engines) but it might be a challenge to run it under Windows so no clue if that's useful for you
…This one appears to support more, though I can't say how well it works or whether it's even usable (haven't managed to make it work)

 

[arthurevil]

These are some unsung heros

 

[Viressa]

I had issues making it work on Linux, so I ended up taking the Windows version and rewriting it on Bash. (I also added a few tweaks while I was at it.)
It's obviously heavily untested can be considered working by now, but the games I tried it on seem to work fine; so I'm sharing it here. (The other attached file is a script I use for decoding RPGM files.)

Spoiler: Features

You don't have permission to view the spoiler content. Log in or register now.

Spoiler: Usage

You don't have permission to view the spoiler content. Log in or register now.

Spoiler: Usage (tl;dr)

You don't have permission to view the spoiler content. Log in or register now.

…And yes, most file managers allow for quick terminal access (Ctrl+O in Midnight Commander, Shift+F4 in Dolphin).

P.S. webp-header-fix.py can be made compatible with Python 3 (as Python 2 reached end-of-life last year) by changing offset value from 04 to 0o4 (or plain old 4).

Spoiler: Technical notes

You don't have permission to view the spoiler content. Log in or register now.

Spoiler: How to compress RPG Maker MV games with .soldata files:

You don't have permission to view the spoiler content. Log in or register now.

Edit: added GIF conversion (for HTML games)
Edit 2: added support for RPGM MZ (with minor fiddling)

Spoiler: How to compress RPG Maker MZ games:

You don't have permission to view the spoiler content. Log in or register now.

Edit 3: fixed upcase extension matching & added progress printing per extension (also see: LOGLEVEL)
Edit 4: added parallel processing for images/audio (optional, requires GNU Parallel to work)
Edit 4a: fixed file counter for output (oops)
Edit 5: added pretend mode (for estimating amount of files to be processed before a proper run)
Edit 5a: added a dry-run (in pretend mode) before printing the menu
Edit 6: added support for .dotfiles (‘hidden’ files) and RPA unpacking/repacking (also see: RPATOOL)
Edit 6a: added support for RPGM resource decrypting (also see: MVDECRYPTOR)
Edit 7: added support for RPGM VX Ace; opaque PNGs are converted to JPEG (also see: OPACITY)

Spoiler: How to unpack RPG Maker VX Ace game resources archive

You don't have permission to view the spoiler content. Log in or register now.

Edit 8: added support for key autodetection (based on PNG header) in MvDecryptor by supplying DETECT=yes (pick D in RPGMCruncher)
Edit 9: added ETA for non-parallel progress bar (based on average processing time)
Edit 10: added status display in terminal title (%w in Konsole)
Edit 11: added VP9 (WebM) acceleration support via Intel VAAPI (also see: ACCEL)
Edit 11a: fixed accelerated encoding for videos with sound
Edit 12: added compression of MOV video format

You are my hero, I was frustrated trying to get the Mac/"Linux" version to work and was about to bite the bullet and write my own implementation, glad I looked through the thread to see if anyone else had done this first. Saved me many hours of work!

 

[DIKSIE NORMAS]

Mac product give much errors:

Passing a number to -vsync is deprecated, use a string argument as described in the manual.

Please use -b:a or -b:v, -b is ambiguous
[NULL @ 0x558fce5968c0] Unable to find a suitable output format for '4'
4: Invalid argument

Error opening file ffmpeg2pass-0.log.
Error reading log file 'ffmpeg2pass-0.log' for pass-2 encoding

This very nice friend

I had issues making it work on Linux,

 

[Naitoh]

One of the best tools I use. Thanks a lot for making it.

 

[Sieglinnde]

Isn't there a 32 bit version?

 

[Rameron]

Is it planning to port the application to more performance platform with the paralleling of file processing (.NET for example)? Because bat realization is EXTREMELY slow.

 

[killilolipop52]

Finally found it. Thank guys. God bless you.

 

[Madeddy]

Isn't there a 32 bit version?

Answer is a bit late and even some grave digging, but better then unanswered:
>| 32 bit support isn't possible anymore because the used image converters like cwebp and ffmpeg do NOT support it anymore. |<

Curiosity Question: Is this tool still widely used by many people or do they use one of the alternates?

 

[master861]

Answer is a bit late and even some grave digging, but better then unanswered:
>| 32 bit support isn't possible anymore because the used image converters like cwebp and ffmpeg do NOT support it anymore. |<

Curiosity Question: Is this tool still widely used by many people or do they use one of the alternates?

Eh what?

Windows® XP SP3 or above (32 or 64 bits) (tested on Windows® 10) how say no 32 bit support?
that is from

You must be registered to see the links

( that use cwebp as are backend)

 

[agregen]

Windows® XP SP3 or above (32 or 64 bits) (tested on Windows® 10) how say no 32 bit support?
that is from

You must be registered to see the links

( that use cwebp as are backend)

This repo is using

You must be registered to see the links

(…or rather, the repo itself hasn't been updated since 2016).
That being said, it's perfectly possible to download a WebP Utilities release for Win32 from

You must be registered to see the links

(the latest match is v1.0.3 from 2019). There's also

You must be registered to see the links

which (probably) can be compiled to 32 bits if you setup a proper compiler.

As for ffmpeg, I dunno about Windows but 32-bit builds are supported for Linux according to

You must be registered to see the links

.

Edit: there's a repo with

You must be registered to see the links

, maintained up till the end of May

 

[agregen]

This one should work a bit better on modern linux distros with ffmpeg n6.0
Cruncher.7z

• Why are you quoting his port when your modification is based on mine?
• Why not use the latest version as the base? The one you're using is about two releases older (it's from last year at least)
• When different versions of a utility have conflicting CLI, you should add a check to support both, instead of simply breaking the older one (this "modern linux distros" sounds like you excavated a script from Victorian era or something… but ffmpeg-6 hadn't even had stable status for long on Gentoo, which includes new versions of major packages pretty much as soon as they get released).
  incidentally, even though -vsync is deprecated since v5.1 in favour of new option -fps_mode which enforces keyword values, -vsync is still usable even in v6.0 while -fps_mode doesn't exist in versions before the switch
• Do not turn ACCEL on by default: it produces lower-quality output and has very specific hardware requirements (i.e. your version will fail on any AMD system, and some non-AMD as well, I believe); these are very good reasons to keep the feature opt-in (and not opt-out). Those who want to use this option at all times(yourself included) can simply add export ACCEL=true (or alias Cruncher='Cruncher -a') to their ~/.bashrc; although I'd say VPARALLEL is a better alternative in most cases (and the only usable one for most users).
  • If you feel the need to change script behaviour, reflect the change in printed information; the version that you made claims to have ACCED turned off by default, but it's actually turned on, and the option -a does the opposite of what it says in printed description!

 

[mpekas]

• Why are you quoting his port when your modification is based on mine?
• Why not use the latest version as the base? The one you're using is about two releases older (it's from last year at least)
• When different versions of a utility have conflicting CLI, you should add a check to support both, instead of simply breaking the older one (this "modern linux distros" sounds like you excavated a script from Victorian era or something… but ffmpeg-6 hadn't even had stable status for long on Gentoo, which includes new versions of major packages pretty much as soon as they get released).
  incidentally, even though -vsync is deprecated since v5.1 in favour of new option -fps_mode which enforces keyword values, -vsync is still usable even in v6.0 while -fps_mode doesn't exist in versions before the switch
• Do not turn ACCEL on by default: it produces lower-quality output and has very specific hardware requirements (i.e. your version will fail on any AMD system, and some non-AMD as well, I believe); these are very good reasons to keep the feature opt-in (and not opt-out). Those who want to use this option at all times(yourself included) can simply add export ACCEL=true (or alias Cruncher='Cruncher -a') to their ~/.bashrc; although I'd say VPARALLEL is a better alternative in most cases (and the only usable one for most users).
  • If you feel the need to change script behaviour, reflect the change in printed information; the version that you made claims to have ACCED turned off by default, but it's actually turned on, and the option -a does the opposite of what it says in printed description!

You are 100% correct, I'm just very absentminded and stupid sometimes.

My actual issue was that ACCEL was turned on while i wasn't using '-a' and ffmpeg kept failing on AMD

 

[agregen]

You are 100% correct, I'm just very absentminded and stupid sometimes.

My actual issue was that ACCEL was turned on while i wasn't using '-a' and ffmpeg kept failing on AMD

Well, it happens… Though double-checking usually helps in such cases, I believe

…Incidentally, I just finished making a new release; it fixes a bug I seem to have missed in the previous one, and improves OPACITY support (…which admittedly affects only Ace mode). Still, if you were using that old version, then you probably haven't seen the [optional] GUI yet (…Though I don't know if anyone actually considers it useful )

 

[mpekas]

Well, it happens… Though double-checking usually helps in such cases, I believe

…Incidentally, I just finished making a new release; it fixes a bug I seem to have missed in the previous one, and improves OPACITY support (…which admittedly affects only Ace mode). Still, if you were using that old version, then you probably haven't seen the [optional] GUI yet (…Though I don't know if anyone actually considers it useful )

Fyi:
Found 23161 webp, 63 jpg, 0 jpeg, 0 bmp, 153 png, and 0 gif image files.

Looking for webp image files to process...
./Cruncher/RenCruncher: line 447: /usr/bin/parallel: Argument list too long
Done - processed 23161 webp image files (in 0.1 seconds).

[user@host game]$ ls **/*.webp
-bash: /usr/bin/ls: Argument list too long

It's working with '-1' but it just takes too long and uses only one core.

Maybe a combination of find and xargs will work better instead of parallel(this kinda works, but my bash skills are rusty and i'm not sure how to make it work properly):

find . -name "*.$EXT" -print0 | xargs -P$(nproc) -n1 -0 -I {} bash -c 'apply-conversion '$TYPE' '$EXT' "$@" '${3:-$TYPE}'' _ {}

 

[agregen]

Maybe a combination of find and xargs will work better instead of parallel(this kinda works, but my bash skills are rusty and i'm not sure how to make it work properly):

find . -name "*.$EXT" -print0 | xargs -P$(nproc) -n1 -0 -I {} bash -c 'apply-conversion '$TYPE' '$EXT' "$@" '${3:-$TYPE}'' _ {}

parallel can accept parameters from stdin as well; and it actually supports displaying progress and stuff. So it's a better idea to try adjusting its usage first.

Found 23161 webp, 63 jpg, 0 jpeg, 0 bmp, 153 png, and 0 gif image files.

…What game is this, anyway?

 

[mpekas]

parallel can accept parameters from stdin as well; and it actually supports displaying progress and stuff. So it's a better idea to try adjusting its usage first.


…What game is this, anyway?

I did try to make it work with parallel, i just couldn't and i suspect the progress would be compromised if the files came to it in chunks anyway.

The VN is Light of my Life, one of the few i have uncompressed atm.

 

[agregen]

I did try to make it work with parallel, i just couldn't and i suspect the progress would be compromised if the files came to it in chunks anyway.

The VN is Light of my Life, one of the few i have uncompressed atm.

WDYM by "if the files came to it in chunks"? It receives a list in stdin and it processes the list (pretty sure the limit on the number of arguments is imposed by the shell itself); likely only reading a new line once it has a free slot in the thread pool.

…I'll try to reproduce and fix the issue; whether or not it'd work with parallel should become clear in the process