ZipFile

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • I am looking at ZipFile.h and it seems as if I can only read from it. Actually I also want to add files at runtime.

      Is adding files supported and I miss something. If not can someone hint me how to add this actually. I googled like crazy for this and didn't find any satisfying solution.

      Cheers,
      -Dirk
    • Well, that's just a little embarrassing....I never added the editor side of creating the zip file.

      I guess that's something for the 4th edition then, if one ever gets made!

      In the mean time, you can extend the ZipFlie class by looking into the Deflate API of ZLib. Here's a good start: zlib.net/zlib_how.html

      If you add this do the community a favor and post it!
      Mr.Mike
      Author, Programmer, Brewer, Patriot
    • 4th Edition? Let's do it, man! I already have ideas for what I want to do differently in the AI chapter!

      -Rez
    • Hey guys,

      I'm brand new here and just registered because of this thread actually. I'm kind of noobish with a year+ of C and C++ experience, and I'm working on a game for a small team(4 people). I've been trying to wrap my head around the Resource Manager and Cache out of the book, and I've grabbed the ResCache2.cpp .h and ZipFile.cpp .h files from the SVN at gamecode3.googlecode.com/svn/t…de3/Source/ResourceCache/

      I had to make a few changed to the ZipFile stuff because of problems with boost, and I didn't want to include anything else from the GameCode engine. (The changes were pretty minor, mostly involving removing optional return values) Anyways, I got the ZipFiles to compile, open a .zip and extract the contents into a directory. Now I've moved onto the cache and I'm having some issues with the code and am just looking for some help/direction.

      I think my first issue is that since I'm not familiar with the code I have a hard time discerning what from the book is psuedocode and what I have to write myself. Virtual functions are something I've only read about and this is my first time using shared_ptr. I changed ResCache2.cpp and .h to remove the optional returns. I also had to write the IResourceClass in ResCache2.h because it was not there, so I copied it out of the book.

      I then proceeded to copy this exert from the book and added a little so I could see some results.

      Source Code

      1. int main (void )
      2. {
      3. ResourceZipFile zip("test.zip");
      4. ResCache resCache(5, &zip);
      5. if (resCache.Init())
      6. {
      7. Resource resource("test.bmp");
      8. boost::shared_ptr<ResHandle>texture=resCache.GetHandle(&resource);
      9. int size = texture->Size();
      10. char *testBitmap = (char*) texture->Buffer();
      11. int len = zip.VGetResourceSize(resource);
      12. char dpath[1000];
      13. sprintf(dpath, "Data\\%s", resource.m_name.c_str());
      14. char *p = strrchr(dpath, '\\');
      15. if (p)
      16. {
      17. *p = '\0';
      18. MakePath(dpath);
      19. *p = '\\';
      20. }
      21. FILE *fo = fopen(dpath, "wb");
      22. if (fo)
      23. {
      24. fwrite(testBitmap, len, 1, fo);
      25. fclose(fo);
      26. }
      27. }
      28. }
      Display All


      So now when I run this with all 4 files it will open the zip, read a bmp and create a directory and place the bmp inside.

      The issues I'm running into are when the program ends, however. I crash when leaving ResCache::FreeOneResource()

      Source Code

      1. Unhandled exception at 0x5fb557aa (msvcr100d.dll) in zip_file_reader.exe: 0xC0000005: Access violation reading location 0x00500034.


      cradshing on line 52 of dbgdel.cpp

      Source Code

      1. _ASSERTE(_BLOCK_TYPE_IS_VALID(pHead->nBlockUse));


      There are some comments in the function that make me feel like I need to be writing some more code to get this to work right, but to be honest I have no clue what I'm really doing at this point and I'm pretty amazed I even got everything working this well. I think I'm just not cleaning up things correctly? I've read through the chapter a handful of times and I feel like I have a good grasp of the concept, but I'm mucking up the code.

      I was also wondering if anyone has some good examples of actually using this manager in a real situation. IE using different cache for various types of files as well as using multiple resource files with this? I apologize for a rather lengthy/wordy/confusing first post.

      The post was edited 1 time, last by Voxx ().

    • Looks like some funky memory thing but I can't really tell what's going on without more info. Can you post the full call stack you're getting? That will show where in the code it's dying.

      -Rez
    • Source Code

      1. >
      2. msvcr100d.dll!operator delete(void * pUserData) Line 52 + 0x51 bytes C++
      3. zip_file_reader.exe!ResourceZipFile::`scalar deleting destructor'() + 0x3c bytes C++
      4. zip_file_reader.exe!ResCache::~ResCache() Line 79 + 0x41 bytes C++
      5. zip_file_reader.exe!main() Line 245 + 0xc bytes C++
      6. zip_file_reader.exe!__tmainCRTStartup() Line 555 + 0x19 bytes C
      7. zip_file_reader.exe!mainCRTStartup() Line 371 C
      8. kernel32.dll!75aa33ca()
      9. [Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]
      10. ntdll.dll!77429ed2()
      11. ntdll.dll!77429ea5()
      Display All


      I'm positive I'm not cleaning up something correctly. It seems to be breaking in the deconstructor for the ResCache

      Source Code

      1. ResCache::~ResCache()
      2. {
      3. while (!m_lru.empty())
      4. {
      5. FreeOneResource();
      6. }
      7. SAFE_DELETE(m_file);
      8. }


      The call to safe delete triggers this assertion failure.

      Source Code

      1. Expression: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse)


      I think that means that I'm either trying to delete something that wasn't dynamically allocated, or has already been deleted? In all honesty the more I look at it the more odd it seems to even be calling delete on that pointer.

      Source Code

      1. IResourceFile *m_file;


      An IResourceFile is a class with just some virtual functions... Like I said though, I'm pretty clueless about some of this stuff. I commented out the line giving me trouble and everything appears to work fine, but that doesn't mean I don't have all sorts of memory problems, haha.

      I can post anything else you'd like to see, thanks for any help/tips/comments.
    • Well, you could be leaking memory now. ;)

      IResourceFile is an interface pointer. The pointer itself points to an object of one of the subclasses, in this case ResourceZipFile. As long as the base class destructor is marked as virtual, it'll call the subclass destructor properly.

      Set a breakpoint in that destructor and see if you're double-deleting memory. Also, check out the object that the pointer is pointing to. If you see something like 0xfeeefeee, it means the memory has been freed. In debug mode, programs built with visual studio will set memory to a special value depending on what it did.

      -Rez
    • Source Code

      1. int main (void)
      2. {
      3. ResourceZipFile zip("test.zip");
      4. ResCache resCache(3, &zip);
      5. resCache.Init();
      6. }


      So I took everything out of my code but this and I still get the same error. The deconstructor for ResCache is called, which calls the deconstructor for ResourceZipFile, which calls the decontructor for ZipFile.

      All of these use SAFE_DELETE which and I don't flag any error until after the call to the ZipFile Deconstructor. Stepping after this steps into Disassembly. I have a little assembly experience, but not much.

      Source Code

      1. 00A72A26 call ResourceZipFile::~ResourceZipFile (0A71492h)
      2. 00A72A2B mov eax,dword ptr [ebp+8]
      3. 00A72A2E and eax,1
      4. 00A72A31 je ResourceZipFile::`scalar deleting destructor'+3Fh (0A72A3Fh)
      5. 00A72A33 mov eax,dword ptr [this]
      6. 00A72A36 push eax
      7. 00A72A37 call operator delete (0A7137Fh)
      8. 00A72A3C add esp,4
      9. 00A72A3F mov eax,dword ptr [this]


      So the error actually triggers on

      Source Code

      1. 00A72A37 call operator delete (0A7137Fh)


      I'm not sure if that helps. I threw in some code to use <crtdbg.h> that I found in the debug chapter of GCC.

      I threw _CrtCheckMemory() in all of the constructors/deconstructors for each class, but none of them flagged anything. I'm not sure how it could be a double delete since I am using SAFE_DELETE, but I don't fully understand shared pointers ... but AFAIK It shouldn't be deleting if it is still pointing to something (isn't that the whole point?). I'm sure I'll get it figured out the more I understand the code.
    • I don't remember "ResourceZipFile " in the book, you know.

      Maybe it is being deleted twice as you are using

      ResourceZipFile zip("test.zip");
      ResCache resCache(3, &zip);


      Try

      ResourceZipFile* zip = new ResourceZipFile ("test.zip");
      ResCache resCache(3, zip);

      Edit:
      Yes this has to be it, you were supposed to allocate it, what happens is that on shut down the program automatically deletes the zip file and then the cache which tries to delete the zip file again.

      The post was edited 1 time, last by Shanee ().

    • Yea ResourceZipFile was from the code on SVN, I couldn't find anything in the book about it either. It inherits from IResourceFile, so I implemented them in my project though. It's basically just a wrapper around the ZipFile. Your fix seems to have worked. That explains why it seemed like I was deleting something that was never allocated, haha. Oh boy. I appreciate your help a ton!

      I'm a bit confused on how exactly this crash was happening (for lack of a better word). I guess it would be better to say I don't understand why this fixes my problem. I don't see where delete was being called on ResourceFile zip. I understand that zip object had a pointer to a ZipFile class and that the ZipFile class had some allocated stuff in it... but the ZipFile class cleans all of this up.

      Furthermore if I left main as such

      Source Code

      1. ResourseZipFile zip("test.zip");

      The project ran with no problems.

      Haha.. as I was typing this and working through the code I think I realized it. Registering the zip file with the cache points to the ResourceZipFile. Then when the deconstructor is called for the cache it tries to delete zip, which was never allocated? Yay for understanding something (hopefully?)

      Thanks again!
    • Source Code

      1. SAFE_DELETE(m_file);


      Remember this? Well m_file is your ResourseZipFile.

      Now do you know what's heap memory and normal memory? Normal memory gets deallocated automatically as it goes out of the scope, this means:

      Brainfuck Source Code

      1. void main()
      2. {
      3. ResourseZipFile zip("test.zip");
      4. } <--------------- zip will be automatically deallocated as the program reaches here.


      But heap memory (allocated with the "new" command) needs to be manually deleted and survives the end of the scope:

      Brainfuck Source Code

      1. void main()
      2. {
      3. ResourseZipFile* zip = new ResourseZipFile("test.zip");
      4. } <--------------- zip will *NOT* be automatically deallocated as the program reaches here.


      Ok, so what's the other problem we had?

      Source Code

      1. ResCache resCache(3, &zip);

      ResCache automatically got deallocated at the end of main too and it had a pointer to zip inside of it and was called SAFE_DELETE(zip) in its destructor. So zip was deleted twice, once when main() ended and once inside the destructor of the ResCache.

      That is all there is to it, once you changed it to be dynamic heap memory it was only deleted once.
    • Lol yea, I didn't mean to make it seem like I didn't know the difference between the heap.. I just didn't realize that delete was being called on the zip I allocated in main(). It's funny because I stepped over that line of code plenty of times without connecting the dots as to what m_File was actually pointing to.

      Thanks again.