Skip to main content
GameDev.net gamedev.net
🔒 Locked

Data storage

Started by Weston Oct 26, 2004 at 3:22 PM 3 replies 1.4k views
Original Post
Weston
Weston
For a few weeks, I've been planning out a way to contain my data for a tile based game. I've decided that I'm going to design a world editor using Visual C++ that will create binary files to hold my data. One file I have in mind is a binary file that contains information about sprites. Here's a simplified version of how data would be stored: - Number of bitmaps for textures - Bitmap information (Filename for example) - Bitmap Width - Bitmap Height - Number of sprites - Texture coordinates for sprites - Repeat bitmaps and info as needed The only thing I don't like about it is the bitmap filenames. It would be a little more complicated to use resources that way, and it also depends on all the files being located in the right directories. My next idea is to stuff all the image and sprite information into one large binary file. I've seen this done for games such as Descent. If I do it this way, I can make this file a resource so all my information is right where the program expects it to be. To load bitmap data in whenever I want, I just need a variable that stores the offset in bytes that sends the file read pointer to the beginning to the bitmap information. Is this a good practical idea? As a bonus question, I'm using DirectX and want my textures to be in managed memory. I know I can do this easily with D3DXCreateTextureFromFileEX(), but that requires a filename to make a texture. I know I can copy image data to a surface and create a texture from that, but I don't see how I can put that into managed memory. Any ideas?
---Will DDR for food.
ekrax
ekrax
hey, well i'm not sure about the D3D things you want, but i think you can make your level editor a little easier. if it's tile based you dont need the co-ordinates for each sprite. just a 2D Array, either your own or using Vectors. i think if you are planning on making a 'world' editor for a 2d tile based game all you would need is ...
-2D array containing tiles
-Size of each tile
-Size of the map
then for any free moving objcts save their initial positions, but i do not reccomend saving the coordinates of tiles (pixel coordinates that is).
Weston
Weston
Well, the way I have it planned is that I'm using textured quads, so I would need texture coordinates.

Each texture is a "sheet" and each sprite on a sheet is made by 4 vertices with texture coordinates. So if I want to draw sprite number 0 from sheet number 0, I would set texture number 0 first, then I would render a triangle strip starting at vertex number 0. Since each set of 4 vertices contain texture coordinates, it renders the correct portion of the sheet which makes it appear as a sprite.

For the tile map, it would look something like this:

001 001 001
022 002 003
022 002 003

Where each number is a reference to a certain sprite sheet and sprite number. 001 for example would tell the program to use sheet number 0 and sprite number 1. Of course I would batch calls to set texture to keep it running faster.

what i really wanted to get out of this thread is if cramming all my image data into a binary file is a practical idea. I like how it would keep all my image data in one spot, and it would be much harder to hack bitmaps from it.
---Will DDR for food.
C-Junkie
C-Junkie
The easy way is to keep it out of the file, the not so easy way would be to zip up all the files (look around for threads on containers), and the hard way would probably be to do it yourself.

Quote:

One of these days, I'm going to lose my mind and draw nothing but yiff.
no. no no no No NO!
Solias
Solias
Quote:
Original post by Weston
The only thing I don't like about it is the bitmap filenames. It would be a little more complicated to use resources that way, and it also depends on all the files being located in the right directories.


You could just create an "art" subdirectory and require that the textures be located there. This seems like the simplest approach.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.