Compressing data

Started by
6 comments, last by JohnyB 20 years, 7 months ago
Ok I''ve been working on a 2d fighter game lately but I don''t know what to do to compress all the images for each fighter...What would be the best method? Would it be a good idea using zip files? I don''t care much about size I just want to have all the images for each fighter in a single file so that the user can''t mess around with them...
Advertisement
if you dont want the users to edit them you should encrypt them (it''s easy to edit the images even with all of them in 1 file, tibia had it like that and i made a sprite editor for it ) Anyways even with encryption they can still edit the process''s memory and change the images, but the normal player wouldnt go though the trouble (if they even know how )
Yea that''s true but not many gamers out there would do any of that well at least not the average gamer...I also forgot to mention in my last post I want to do it anyway to keep my images organized and in the same file... But I''m mostly concerned about the users not being able to edit the file. An idea I had before was to store them in zip files with passwords n'' stuff but just about any application can crack those today anyway .
I can't say I know a great deal about this topic, but if you're looking for compression techniques, then I suggest taking a look at the following: http://www.gamedev.net/reference/list.asp?categoryid=25#25. Scroll further down and you will also find articles relating to encryption.

Also, I remember Doom used .wad and .pak files for this exact purpose. Many later games have followed suit as well, so it should be worth looking into those.

One final thing, remember that games prosper because of the communities that adopt them. Games such as Unreal Tournament, Half-Life and Quake 3, wouldn't be anywhere near as popular, if modding would have been more difficult. I know this probably doesn't matter so much if you're developing a small/personal game, but keep it in mind later on.

Good luck,

--hellz

[edited by - hellz on September 1, 2003 6:11:44 AM]
The usual way to keep users from messing with your graphics is to make them resources.
Resources are files (bitmap or whatever) that are inserted directly into the .exe file by the compiler. Then all your graphics are actually part of the executable. Windows has a set of functions to load resources somewhat like you would load files (actually resources are a little more convenient IMO).
This will make it very difficult for users to find the actual bitmap data because it is surrounded by all sorts of other machine stuff (you can even get rid of that little 'BM' marker to fool other programmers **taps nose twice**).
Maybe this is what you're looking for?

[edited by - GaulerTheGoat on September 1, 2003 6:28:12 AM]
The latest issue of Game Developer has an rticle on this. Try to pick it up if you can.

Scott Simontis
e-mail:ageofscott@comcast.net
AIM:ssimontis
Scott SimontisMy political blog
libtar

Microsoft Cabinet SDK

I don''t recommend resource files for sprites in a game. If you or your artists want to change them it requires a rebuild each time they want to change them.

Also, bitmap files have no alpha channels. Look up libpng. IIRC, DirectX8 has the ability to load png files as textures. If you use OpenGL, you will need libpng.

Note: Tar and Cabinet files don''t compress. Well, Cabinets may, but not very much. If you want to also compress the textures for distrobution, look up zlib. It comes with libpng (since libpng uses it to compress the image data) so I won''t bother linking to it.

If you need a program to make png files, look up the gimp. When saving, deselect "save background" and anything transparent will be transparent in your game.

If you want to make users not read your files, tack headers onto the files (like a few junk bits) and then when reading the file, remember to rip the junk bits off before attempting to load it as anything else.

Most people trying to open your tar or zip file will not be able to load it, not open it as text and recognize the header for either tar or gzip AFTER the junk bits and will not know to rip those bits.
gl hf
Why not making them Header files. Convert the images into large arrays of data, and then you can read them directly from your code. that will save time for loading and reading the images from a file in runtime. This method is used in Cart games such as consoles. you will need a tool that could read bmps and convert them into .h files. you can write a tool youeself by putting the code for loading files and decompressing them in a standalone program and then add code for creating a header file containing the actual image data plus the palette. you can even make the tool load several images(Sprite frames) into 1 .h file and then you just include it in your code.

this will increase the code sise though

This topic is closed to new replies.

Advertisement