Hey, I have a small game with an isometric map and I would like to save it in a file. But how can i do this?I tried it with "toString()", but then I can't resolved it back to an int array. Any ideas how to solve the problem without using xml. Would be a very large xml file, if I do so.

// Give the compressor the data to compress compressor.setInput(input); compressor.finish();

// Create an expandable byte array to hold the compressed data.// You cannot use an array that's the same size as the orginal because// there is no guarantee that the compressed data will be smaller than// the uncompressed data. ByteArrayOutputStream bos = newByteArrayOutputStream(input.length);

The shifting you'll see there with the adding '0' to the String sometimes is so that I can save the byte data in a String without losing data. If you plan on saving to a file, you can write it straight as bytes and save a little bit of extra space. Try that out and see how it helps!

So essentially you can keep your XML structure, and just in one block have <Map>blah blah blah</Map> with all the compressed data inbetween. It should help a lot!

However, there might be other ways to manage it. For example, how are you creating the map? If you create a new Random() object and just crunch out numbers and you want to save the whole map set up you just randomly generated, instead you should keep track of the seed:

If they're made at random, save the generation seed. If they're made with a map editor, you could try saving the info as a gif. I've heard of that idea once. You have a .gif with the dimensions of your map, each pixel representing a tile, have a different color for each type. That'd be easy to save compressed because you'd let gif do the work there. Or you could use .png and tack on some of the PNGCrush functionality to compress them as much as you can.

At any rate, however you save, you can use that zipping code to compress what you have.

I think the absolutly simplest way to save game data is to use the XMLEncoder and XMLDecoder classes. It is no work at all. All you need to do is to make your data classes Java Bean compatible, which as you may know, in this case means your data classes only have to provide an empty costructor and get/set methods for all your variables.

right, you could use my Zip code I just gave you, and write it to anything you want. In your save file, if they open it, they'll find crap. Since the zip code above is nothing standard because of the shifts to make it work in String form, it's highly unlikely they'd ever make a "guess" to decode it. If they do, they'll see, <gamedata>moreZippedCrap</gamedata> and they'll have to deal with that too

You're right, radix is the base, and can also be thought of as a descriptor for the method of converting Bytes to numbers and letters. The higher the radix, the more letters will be included in the conversion, so that the max radix will enable you to store a byte in 1 or 2 characters. Converting with a radix of 10 instead of MAX_RADIX will result in a MUCH longer String of data. So say you set the radix to be 16, that would mean the byte would be converted into hexadecimal format. I set it to be the maximum possible radix so that the compression of space would be the highest. If the language ever somehow supports a higher radix, that code will compress even further

I might recommend doing something similiar, but using less memory. Just write out a binary file that maps to your tiles. Make byte 0 be the width, byte 1, be the height and the rest of the file the tiles to use. It would take potentially much less file space, unless the image is using indexed color, where it would then be a wash.

For a 3x4 map, you would have 2 + 3 * 4 bytes = 14 bytes for the map. You would have 256 differrent types of tiles using that format.

You could also use ints for the format, then you could mask the bytes to determine different things. Bytes one and two could hold state info such as: treasure here, trap, hidden/secret area, etc. The third byte could give you an index into a graphic to use for the floor or whatever. The fourth byte would be your base tile info.

@dranonymous:Yes my image load code works. And thanks for the idea with the binary file. But I am not that familar with retrieving byte informations from a file and convert them to their needed data types.

I took a look at the DataInput/OutputStream example in the java tutorial, but that wasn't that good. I got the informations stored, but retrieving failed in some manners.

Thx for replay.I got a workaround running, but have some problems left.My mapsize is an integer value, and iam not sure if i should save it with writeInt() or with writeByte(). I hope that there is no big deal with those to functions and i can use them to avoid dataloss from converting int to byte.

So i did my mapfileformat.I saved the mapnames characters each as byte in the file, but the name stands there in plaintext when i open the file. Is there a way to avoid this?

Well, it depends. This might be a bit confusing, unless you a comfortable with number formats.

If you ints don't go above 255, then you can store them as bytes. To store them just cast the int to a byte. Reading them back in won't be so straightforward. If the original number was greater than 127, you'll need to mask off the top 24 bits, to remove the sign change that will occur. You can do this by -

1

intrealInt = myByte & 0xff00;

On the other hand, if your ints are greater than 255, you're 'stuck' and have to write out 4 bytes per int. The only way around that would be to test for how large your numbers are and see if they will fit into a 2 byte short.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org