Originally Posted by SekraSoft
I will check you changes under Windows.
I think it is good idea. But I can only make programs and do not know what should I do. So you should publish sources in G.C.
I saw your changes. All have started to work (MSVS) when I replace "#include <dir.h>" to "#include <direct.h>"
And I don't find whre you define "uint". I see only my "#define uint unsigned __int32" for Windows & MSVS and your "#define __int64 int64_t" for Linux. I think it is magic.
+ All is OK under Win32. New sysdata.bin is good.
What should we change (places where we can optimize)
1. Packer: int read_dir(uint parent); I think we can rewrite code and it will work without uint str_offset;
(for people who count every byte in stack and have veeeeeery fast acces to files)
2. Unpacker: archive (packed file) is being loaded in memory entirely so we may rewrite it. (for people who thinks that 30+ Mb for sysdata.bin is very bad or for very big files) But program may work slowly (I think I read every byte olny one time so we should read file only one time and file don't need to be loaded in memory. But I use random acces so some of bytes will be read twice or more times (because we have HDD). But we have a cache. But it can "forget" something and read again... And we have a swap... So I stop to think and say "I don't know".)
3. Packer & unpacker are work with 32b sizes of file (because all offsets is 32b) So it can't unpack archive whitch size is more 2GB.
4. We can don't define "LOG_ALL" or disable logging
5. We can rewrite packer and set buf_size=(2^N) or change last number in pack.ini to (2^N). "2^N" is not expression "2^N", it is requirenemt for number. This magic is for best memory allocating, fastest working of fread & fwrite, for best interaction with cache. Because usually some buffers have size 2^N.
6..infinity. Somebody may find something to add to this list
But we should not change this because we will waste much time and not find visible changes of repacking time for sysdata.bin
I agree haha...seriously good ideas and good it works...
For the google code is not a problem...I can do it, have you got a gmail access? To become the main developer...
I'm quite new to C++ and I don't know really how is the best solution to manage files but with python i used to define a BUFFER (like 1 MB), then read this amount of data, do what you have to do, and then read this data again until EOF.
Then another idea is to add some error codes (like you previous said)
Before that, we need to test if the basics work really in the real device (I mean a new modified sysdata...like my soundmod)
Oh man I should also port the python aui modder to C++! (I'll do it when I'll got some free time to learn also some C++ tricks)
All in all, nice!