FRIHOST FORUMS SEARCH FAQ TOS BLOGS COMPETITIONS
You are invited to Log in or Register a free Frihost Account!


World Database





Flakky
Hi,

I'm designing files for my project. The next step of my project is a file database of the world. It needs to contain certain data but I don't know what is the best approach. I work with tiles which fill my 2d world with a certain texture. For this I need to store the X and Y location, the scale of the tile, the texture ID (up to 256 textures, so it needs one byte) and blend (optional, this contains RGB codes for the blending).

I thought of partitioning the world so X and Y don't need to be huge numbers. It could be one byte unless the partitions are too small. The scale could do with one byte, texture ID is one byte and blend are three. How would you do this?

I thought of maybe using an INI file for storage. INI's will be much bigger unless I decide to put all blocks of data (block of data is one tile with all variables) in one row and making files like 1A,2A,1B and 2B if I have four partitions.

I can't pick one, what do you think is best or have you got any other ideas?

Thanks!
Fire Boar
That sounds like you're just number crunching. In that case, wouldn't it be more efficient to simply use a binary file format of your own design? It could be extremely simple: have a fixed-length header that gives some meta-data about what you're after... for example, giving the number of rows and length of rows. You could actually stick anything you like in the header, as long as it's fixed-length or you provide an offset to a dynamic length block for more variable-length metadata.

If you want to use partitions, just take a bunch of those and you can encapsulate them into one file by a similar method, but with this method it probably wouldn't be necessary.

This way, if you code it right, you can jump very quickly to the right location in the file and grab the necessary data, instead of spending ages parsing ini files constantly.


Example (without partitions):

Header:
4 bytes: "wmap" (Some fixed characters to ensure that the file is of the right type.)
4 bytes: "V1.0" (Maybe you'd want a version number? Often better safe than sorry, that way if you change the format later you can ensure you're parsing the right kind of file.)
4 bytes: DWORD (Number of columns)
4 bytes: DWORD (Number of rows)

Main body:
This would consist of a bunch of 4 byte combinations all strung together. The first byte would be the texture ID, the second third and fourth used to store RGB values. Very convenient.

To access the row/column (x,y), here is how a program would do it:

- Read the header.
- Check that the first 4 bytes say "wmap" or else bail.
- Check the second 4 bytes. It's "V1.0" so use the rules for parsing "V1.0" world map files.
- Read the third 4 bytes and store it in a variable xmax.
- Read the fourth 4 bytes and store it in a variable ymax.
- Check that x < xmax and y < ymax (assuming your rows/columns start at (0,0)).
- Jump to byte 16 + ((y*xmax + x) * 4) and read 4 bytes.

The reasoning behind the last step is as follows. The header is 16 bytes long, so we skip past that. Each cell is 4 bytes of data, so we multiply what we're after by 4. We're enforcing that the coordinates are stored in a logical order, i.e. (0,0), (1,0), (2,0), (3,0), ... , (xmax-1,0), (0,1), (1,1), ... , (xmax-1,ymax-1); so that means that we need to skip past xmax y times, then seek another x cells along to get to where we are after.

Hope that makes sense.
Flakky
Fire Boar wrote:
That sounds like you're just number crunching. In that case, wouldn't it be more efficient to simply use a binary file format of your own design? It could be extremely simple: have a fixed-length header that gives some meta-data about what you're after... for example, giving the number of rows and length of rows. You could actually stick anything you like in the header, as long as it's fixed-length or you provide an offset to a dynamic length block for more variable-length metadata.

If you want to use partitions, just take a bunch of those and you can encapsulate them into one file by a similar method, but with this method it probably wouldn't be necessary.

This way, if you code it right, you can jump very quickly to the right location in the file and grab the necessary data, instead of spending ages parsing ini files constantly.


Example (without partitions):

Header:
4 bytes: "wmap" (Some fixed characters to ensure that the file is of the right type.)
4 bytes: "V1.0" (Maybe you'd want a version number? Often better safe than sorry, that way if you change the format later you can ensure you're parsing the right kind of file.)
4 bytes: DWORD (Number of columns)
4 bytes: DWORD (Number of rows)

Main body:
This would consist of a bunch of 4 byte combinations all strung together. The first byte would be the texture ID, the second third and fourth used to store RGB values. Very convenient.

To access the row/column (x,y), here is how a program would do it:

- Read the header.
- Check that the first 4 bytes say "wmap" or else bail.
- Check the second 4 bytes. It's "V1.0" so use the rules for parsing "V1.0" world map files.
- Read the third 4 bytes and store it in a variable xmax.
- Read the fourth 4 bytes and store it in a variable ymax.
- Check that x < xmax and y < ymax (assuming your rows/columns start at (0,0)).
- Jump to byte 16 + ((y*xmax + x) * 4) and read 4 bytes.

The reasoning behind the last step is as follows. The header is 16 bytes long, so we skip past that. Each cell is 4 bytes of data, so we multiply what we're after by 4. We're enforcing that the coordinates are stored in a logical order, i.e. (0,0), (1,0), (2,0), (3,0), ... , (xmax-1,0), (0,1), (1,1), ... , (xmax-1,ymax-1); so that means that we need to skip past xmax y times, then seek another x cells along to get to where we are after.

Hope that makes sense.


It makes a lot of sense. Thanks for the reply. The X and Y can change although. So this means I can't have rows and columns. I would have done it your way if that was the case. All tiles have an X and Y. Because of this I thought of partitioning and sorting all tiles by storing all tiles between two x and y coordinates to a single file and load the entire file as one but I could also store it in the same file. I'm just wondering what would be fast?

I think I am going to try something out. If I'm done I'll show the results Wink
Thanks for the reply.
Related topics
WTF! A strange database just appeared lol
script backup database
world war2 design?
Cheaper to patch--Windows or open source?
Google in your scripts
Argentina tops Brazil for World Cup spot
What do you think about WAR of the WORLD?
BG Xmail The World's First 10GB Email Service
How much database
World of Warcraft - itemstats database
Setting up a database
The World Without Computers!
Multivalue Database
An open letter to the world (important stuff)
Reply to topic    Frihost Forum Index -> Scripting -> Others

FRIHOST HOME | FAQ | TOS | ABOUT US | CONTACT US | SITE MAP
© 2005-2011 Frihost, forums powered by phpBB.