Handling Data
Blitz3D Forums/Blitz3D Beginners Area/Handling Data
| ||
| Hi everyone, What is the best way to handle data for all meshes in my level/map? My simple level only consists of a small amount of meshes which so far I am placed by hard coding there x, y, z. I know this isn't ideal for lots of meshes/objects in games but data handling is not my strong point. How does world editors or game engines handle the placment of meshes and can someone show me a simple example of whether its an array or another technique. Thanks. |
| ||
| Maybe you could look into these 'dropper' applications? I found a thread about this here: http://blitzbasic.com/Community/posts.php?topic=80635 Gile[s] is mentioned, which is now freeware: http://www.frecle.net/index.php?show=giles.download There is a blitz3d sample further down the page, under 'extras'. |
| ||
| Hi thanks for your post however I don't think my original question was clear enough. I am aware of Giles and programs similar I would like to know how Giles and other world editors handle the data. So how does it store the data of the meshes coordinates on screen and other information it may need? What technique is used and can someone show a simple example? |
| ||
| I see. Well, positional data, such as location, orientation and scale could be stored into the Entity itself. Accessible via EntityX, EntityY, EntityZ etc. Having said that, a user type should be a good way to store information. A Type could be used when you need to store a certain set of structured data (struct) for each object, and the number of these objects is not predetermined. Here is an example of a dropper: You could also use an array, a Blitz array or a Bank, but I think it is more of a hassle to do so. |
| ||
| Do you mean how that data is saved to disk? If so, other than "it's written to a file", there is no standard way to store it. You have several options; the easiest is probably to have all the actual media (textures, images, meshes and whatnot) in separate files, as it would have been before (arranged however you like), and then store your level as a file containing references to these and instructions for setting it up. You'd then pass the level filename to a "level builder" function, which opens the file, reads the names of media to load, and positions them according to the data it finds in the level file associated with that object. There are several possible ways to store data in a file. You could just dump the data in a very linear way (write the name of each mesh and dump the floats for its position and rotation), but that's really inflexible and will also make it very hard to spot errors. Several formats are listed here: http://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats The section on human-readable formats has some examples that might give you some ideas, but you'll have to either write, or find, parsers for the different formats. In my opinion, the absolute simplest way to store data is with an INI file ( http://en.wikipedia.org/wiki/INI_file ). It doesn't let you nest data blocks, but it's unbelievably simple, having only three rules (one of which is comments!). Then you can do something like this (hypothetical example): ; Blah blah blah [LevelMain] baseMesh = \Meshes\Areas\Level5.b3d gravity = 0.98 enemyCount = 2 enemies = Dave, Mitchell ;Just faces forwards [Dave] mesh = \Meshes\Enemies\Dave.b3d texture = \Texs\Enemies\Dave.png position = 10, 5, 10.2 ; Doesn't have a texture yet [Mitchell] mesh = \Meshes\Enemies\Mitchell.b3d position = 5, 6, 22.1 rotation = 0, 45, 0 The data for each "thing" is put into a named block, and each piece of data is associated with a named key. This makes it easy to search, and also really easy to see what's going on if you choose to edit or examine the file by hand. The loose structure also means you can potentially make up and add new sections or properties, or leave them out, without affecting the structure of the whole data file (e.g. Dave in the example has no rotation, because it faces forwards, while Mitchell has no texture yet so doesn't bother to store it). You can parse INI files like the one above with the following code snippet: I'm sure there are much better (and faster!) functions for this in the archives, I just cranked those out quickly. The ReadINIValue function accepts a file handle (obviously), property name and optional section (if you don't include the section it just searches from the top for the first matching key, ignoring sections); the StrToVec function grabs a substring from a comma-separated list. So then you could do something like... levelFileName$ = ReadINIValue (level, "baseMesh", "LevelMain")
If levelFileName <> "" Then LevelMesh = LoadMesh(levelFileName)
noEnemies = Int(ReadINIValue (level, "enemyCount", LevelMain"))
allEnemies$ = ReadINIValue(level, "enemies", "LevelMain")
For e = 0 to noEnemies - 1
enemy.Enemy = New Enemy
enemy\Name = StrToVec(allEnemies, e)
enemy\Mesh = LoadAnimMesh(ReadINIValue(level, "mesh", enemy\Name))
positionStr$ = ReadINIValue(level, "position", enemy\Name)
If positionStr <> "" Then PositionEntity enemy\Mesh, StrToVec(positionStr, 0), StrToVec(positionStr, 1), StrToVec(positionStr, 2)
;DO the same for rotation... you get the idea
Next
;etc.
...and you'd be setting up a level based on data read from a file. |
| ||
| hi i developed a wordl assembler and use a file format not so good, but not so bad. Probably you can watch the Loader and see if it work for you. I changed the file format recently to a completely new one but haven't updated already. Now i'm using the Chunk's method of the .b3d file formtat itself b3d file specs: http://blitzbasic.com/sdkspecs/sdkspecs/b3dfile_specs.txt b3d sample code: http://blitzbasic.com/sdkspecs/sdkspecs/b3dfile_utils.zip AWC is distributed with many .bb files see: "awc loader.bb" http://blitzbasic.com/toolbox/toolbox.php?tool=247 Juan |
   |