The above video goes away if you are a member and logged in, so log in now!
Sorry, been busy.
free() is enough.
And writing that to host: or anywhere else is a bad idea. Just use memory buffers – read the compressed file to one buffer and then uncompress it to another using zlib's uncompress() function http://www.zlib.net/manual.html#uncompress, and there is no need to modify gz_open().
I think that it should work that way – you call smth. like:
PakRead(IN "host:/Resources.pak", IN "Icon1.bmp", OUT BYTE** pUncompressedBuffer, OUT int* pBufferLen)
// read the header and get the offset to "Icon1.bmp"
pComprBuf = malloc(filelen = offset(file(n+1)) - offset(file(n)));
pUncomprBuf = malloc(it looks like there is no way to get that from zlib, so store that in the header too);
*pUncompressedBuffer = pUncomprBuf;
*pBufferLen = UncomprLen.
and then just free(pUncompressedBuffer).
So the header will be like:
The PC-side utility should compress these files using zlib's compress() instead of taking already gzipped files. And there is no need for any appending/removing - just add all the files in a folder (smth. like executing pak.exe Modules to add all the files from Modules folder to Modules.pak).
Any new versions? Maybe you'll keep me updated of any intermediate releases? And btw., does it require an updated ps2_host.irx?
Last edited by user112; 12-20-2006 at 08:11 AM.
@user112: ...just be patient, please. It will be available soon (quite busy at work). That smb.irx I've posted earlier doesn't work properly indeed as there're some real flaws in the code, but I'll fix them anyway. No, ps2host is unchanged...
Ok, and forgot to add that the posted version worked with Windows 2000 and Windows Server 2003 fine.
Btw., is there any SMS function to clear the VRAM (to avoid displaying garbage)?
Here is what I call:
// I have to call that to initialize smth. about the subtitles
// and we start seeing VRAM garbage on the screen
// some other lengthy inits
// here I can clear it
Last edited by user112; 12-20-2006 at 03:15 PM.
alright i finished it up, and pretty sure all the bugs are out, and memory leaks are gone (not 100% sure about memory leaks though)
is the link containing
1. the code for the pc side, and the visual studio solution/project
2. library for the ps2 side
3. sample elf to test stuff out
to use it in any elf just link the the library
then include the file
then you first use
pfj_open( [file] );
to open the [file], what it does it it builds an SMS_List containing all of the information to extract the files from [file]
void data* = pfj_extract("[folder\\\\file.jpg]") ; //yse u need the 4 \
then that extracts from the large [file] and decompresses it so its a memory buffer of the whole file
for the pc side its a bit easier, from the command line execute
it should show a help, but basically to create a new large file do
ps2filejoiner.exe -c largefile.extension folder\*.*, for all of the files in the folder
ps2filejoiner.exe -c largefile.extension folder\*.jpg, for only jpg files in the folder
ps2filejoiner.exe -c largefile.extension image.jpg image2.jpg, for individual files in the same folder as the .exe
then to extract files
ps2filejoiner.exe -e largefile.extension, extracts all of the files in the large file, however, if one of the files is in a subfolder it will not create the subfolder and will fail, but if the subfolder is already there is will be ok
for a list of the files and other info
ps2filejoiner.exe -l largefile.extension
edit: if you get an error about zlib1.dll missing, just move the zlib1.dll to the same folder as the .exe
btw what should we do with the source code, either
1. try ps2dev.org svn again
2. try the google code hosting
3. try sourceforge.net
Haven't seen it yet, but:
- Is there any way to get the uncompressed buffer size? Cause getting the buffer without knowing it size won't work.
- There is no way of taking advantage of calling pfj_open() and then a bunch of pfj_reads(). All these reads are happening at different places and even in different threads. It should work like that PakRead() from the previous post, and no memory leaks headaches too.
- The use of SMS_List worries me. Are you storing the files in a linked list? The reason why I have proposed to develop the fixed-header format is speed:
1. read the fixed size header – in one operation fioRead(HeaderSize);
2. seek to the file;
3. read the file.
Three file operations – that's all.
- There is no need for any subfolders. Is it possible to not use them? Like:
ps2filejoiner.exe -c Folder.pak Folder\File1.ext
- Why 1.7M? I wanted some extremely lightweight library. What is the size of libps2filejoiner.a?
Can you perform some speed tests over host:? Comparing reading some 100 files using gzopen(), gzread() and pfj_open(), pfj_extract(). And call that pfj_open() for every file, not just once.
However you can try adding HDD support:
In your test application load all these modules: iomanx.irx, filexio.irx, ps2poff.irx, ps2dev9.irx, ps2atad.irx, ps2hdd.irx, ps2fs.irx (some of them require some arguments – check SMS source).
In your library change fio() functions to fileXio().
Have you got any answer from SourceForge?
Last edited by user112; 12-21-2006 at 08:59 AM.
@user112: ...normally there's no need to clear VRAM (at least SMS never does it). Is the garbage you have related to Z-Buffer usage? You can look at volume control/scrollbar code to see how the portion of Z-Buffer is cleared. Otherwise, I know 2 methods to clear VRAM:
- disable all pixel tests and draw huge black sprite;
- use host -> local transfer to fill VRAM with zeros;
I think, there's also an API inside GS's stuff of SMS to clear the framebuffer (not the whole VRAM);
i start over host: the loading time for movies is ok - but for the Music is really slow
-yes you can get uncompressed buffer size(from within the library), m_uncompressed_size
-dont quite understand what your saying, but this is the general idea how it works
1. read the header, and store it in the SMS_List
2. search the list when we want to extract a file
3. close which deletes the list
-in pfj_open() the reading of the header consist of 4 parts
1. verify that the file is a valid file
2. read the total header length
3. read the complete header
4. parse the header
and stores it all in the SMS_List (O(1) for insert)
subfolders can be eliminated, just a simple string cutting
as for the 1.7mb i do not know if you had visual studio or what not so I included all the stuff for that, the library size is 21 kb, and the tester.elf was 69 kb
i'll do some speed test, with reading a lot of files of small size (from 5 kb, to 100kb), and measure the time it takes with both methods
when that is done i'll look at adding hdd support
and ya sourceforge.net is good to go, i've never used project management on it but i'll figure it out, and i'm assuming you want svn for code repository?
edit: i can double check for memory leaks by building the code for win32, and using _CrtDumpMemoryLeaks();
Originally Posted by user112