FileForums

FileForums (https://fileforums.com/index.php)
-   Conversion Tutorials (https://fileforums.com/forumdisplay.php?f=55)
-   -   Best Compression Methods for 'Specific' Games. Q&A (https://fileforums.com/showthread.php?t=99554)

Edison007 19-11-2021 08:10

Quote:

How is actual memory usage calculated using for multi thread used An X value for dictionary (-d)?
[dictionary*~11 + (mtb*2) + (memory_for_models)] * threads

frankiedylan 19-11-2021 15:07

ZLib and LolZ are probably the best. I used them on my old projects back in the day and they performed well.

Cesar82 19-11-2021 17:42

Quote:

Originally Posted by Edison007 (Post 494977)
[dictionary*~11 + (mtb*2) + (memory_for_models)] * threads

Thanks for the info.
Don't understand about "memory_for_models"?
You used '"[' and "]", have the same meaning as parentheses for the calculation?
It depends on what parameters?

In these presets below what would the calculation be, give me an example so I can understand.
Code:

LOLZ_FAST  = lolz:d32m:mtt1:mt<thread>:fba4096:mc2;
LOLZ_NORMAL = lolz:d64m:mtt1:mt<thread>:mc1023;
LOLZ_HIGH  = lolz:dtb1:d128m:mtt1:mt<thread>:mc1023;
LOLZ_ULTRA  = lolz:dtb1:d256m:mtt1:mt<thread>:mc1023

Thread is detected by DSG.
Consider as an example on a 24 thead cpu (I think lolz trunc to 16).

-----------------
This calculation is correct (This without adding the use "memory_for_models" which I didn't understand)?
To CPU 5900x (24 threads) lolz trunc to 16 threads
lolz default mtb is 32m
Code:

lolz:dtb1:d256m:mtt1:mt16:mc1023;
calc: (256m*11 + (32m*2) + (?)) * 16
(2816m + 64m + ?) * 16
2880m * 16 = 46080m

Edison007 20-11-2021 05:08

Quote:

You used '"[' and "]", have the same meaning as parentheses for the calculation?
Yes, priority of math operations)

Quote:

calc: (256m*11 + (32m*2) + (?)) * 16
(2816m + 64m + ?) * 16
2880m * 16 = 46080m
Yep, but the block size will be - 256 mb.

Quotes translated with Google Translate.
Quote:

-mtb [2..512] - sets the block size in MB. When -mt1 -mtt0 also plays a role, but minimal. And more does not mean better. Usually, for -mtt0, the optimal value is about 32-64MB, so the size of the dictionary should be more than 2 times larger. For mtt1 mode, the dictionary size must be no more than the block size;
Quote:

lolz test19g
- in the -mtt1 mode, when compressing, the block and dictionary sizes are aligned with each other according to the larger of them;
I don’t remember the required memory for the models. But this is a trifle

Cesar82 20-11-2021 07:13

Thank you very much Edison007.
Quote:

Originally Posted by Edison007 (Post 494985)
-mtb [2..512] - sets the block size in MB. When -mt1 -mtt0 also plays a role, but minimal. And more does not mean better. Usually, for -mtt0, the optimal value is about 32-64MB, so the size of the dictionary should be more than 2 times larger. For mtt1 mode, the dictionary size must be no more than the block size;

I think the problem was this. I was using default value for block size and was using value greater than 512 for dictionary using mtt1.

PS: I noticed that if you compress as small as 300MB the value set for dictionary in console output during compression is smaller than if you compress as much as 30GB. Dictionary appears to be input size dependent.

I will run some tests and see the results.
Thanks!

Edison007 20-11-2021 07:50

Quote:

PS: I noticed that if you compress as small as 300MB the value set for dictionary in console output during compression is smaller than if you compress as much as 30GB. Dictionary appears to be input size dependent.
Another quote from changelog:
Quote:

lolz test19c
- added reduction of the dictionary and the block to an acceptable size if the input file is smaller than the sizes of these parameters;

kj911 21-11-2021 10:09

MSC Questions: Use frog=9 switches equal to --bestnew or any OFR switches??

Example: chimes.wav file in 216 364 byte

MSC with frog=9 switches: 36 455 byte (internally from ARC archive: 36 233 byte)
Directly packing OFR with use --maximumcompression switches: 35 608 byte

Edison007 21-11-2021 11:09

kj911
MSC version 0064 (ofr 4.910b)
ArrOfFROGParams:array [1..9]of PAnsiChar=('
--mode fast --experimental --seek min --optimize best',
'--mode normal --experimental --seek min --optimize best',
'--mode high --experimental --seek min --optimize best',
'--mode extra --experimental --seek min --optimize best',
'--mode best --experimental --seek min --optimize best',
'--mode highnew --experimental --seek min --optimize best',
'--mode extranew --experimental --seek min --optimize best',
'--mode bestnew --seek min --optimize best',
'--maximumcompression --experimental --seek min --optimize best');

+

https://krinkels.org/threads/msc-med...e-7#post-33503

dixen 22-11-2021 05:49

What about *.shapes from Farming Sim 2022? Encrypt files?

Masquerade 22-11-2021 10:47

Quote:

Originally Posted by dixen (Post 495002)
What about *.shapes from Farming Sim 2022? Encrypt files?

Likely: https://zenhax.com/viewtopic.php?t=4030

dixen 27-11-2021 11:45

Hi, my friends)
What about decrypt/decompress *.FF from CoD BO 2?)

KaktoR 04-12-2021 02:09

Chorus
Do not use binkpack on video files. Again bpk fails because of 4k resolution, used codec or something else. RIP

Masquerade 04-12-2021 08:48

Grand Theft Auto III Definitive Edition
 
Grab oo2core from game files and rename from oo2core_8_win64.dll to oo2core_7_win64.dll.

Code:

oo2reck+srep+lolz
4.2GB ----> 2.9GB

Masquerade 05-12-2021 01:03

Grand Theft Auto Vice City Definitive Edition
 
Grab oo2core from game files and rename from oo2core_8_win64.dll to oo2core_7_win64.dll.

Code:

oo2reck+srep+lolz/$mp4=srep
8.7GB ----> 6.2GB (no credits video) / 6.3GB (with credits video)

Masquerade 05-12-2021 12:46

Grand Theft Auto San Andreas Definitive Edition
 
Grab oo2core from game files and rename from oo2core_8_win64.dll to oo2core_7_win64.dll.

Code:

oo2reck+srep+lolz/$mp4=srep
17.8GB ----> 13GB (no credits video) / 13.1GB (with credits video)


All times are GMT -7. The time now is 02:16.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2026, vBulletin Solutions Inc.
FileForums @ https://fileforums.com