Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / Problems opening and reading data from .ini files (using Matrix1 Utils)

Author
Message
Miscreant Software
16
Years of Service
User Offline
Joined: 5th Mar 2010
Location: Australia (where the kangaroos are)
Posted: 3rd Jun 2012 09:16
Hi everyone,
I'm still relatively new to Dbpro, so please excuse me if I'm asking stupid questions =)
For my game I am going to need to use level files of some description, for storing the positions of enemies, powerups and the like. I read somewhere that a .ini file would be a good way of storing this kind of information. I had used some of IanM's Matrix1 Utility scripts in other parts of my program, and was wondering whether his 'Make Lookup From INI' command would help me read data from this kind of file? If so, can anyone give me a code snippet that loads an .ini file and loads the object id and coordinates of an object(from data contained within)?
If this isn't possible, or there's a better way of reading and making level files that doesn't entail my spending any money, how would you suggest that I do this?

Thanks in advance,
Miscreant
Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 4th Jun 2012 11:12
General Idea:
Make a program that is capable of building the level. An editor. Then start writing all the variables and arrays into a file. In your game open the file, read the information and have it rebuild the level from the information.

Starting Off:
Start small, one step at a time. Make the ground. Make the editor be able to chose the position and texture of the ground. Then save those variables into a file and have your game programmed to open the file, read the variables and make the ground.

Then start adding blocks and things.

Miscreant Software
16
Years of Service
User Offline
Joined: 5th Mar 2010
Location: Australia (where the kangaroos are)
Posted: 5th Jun 2012 08:52
Hey Mage,
Thanks heaps for a prompt reply =)
That sounds like a pretty good way to approach the problem; initially I was just planning on working out the positions of the enemies and just writing the level files in Notepad. Probably not the most effective of methods =)
I understand the principle behind what you're saying, however, I'm not quite sure how to physically code it.
I'm trying to figure out how to use the Matrix1 Utils to open and read another file, but I can't work out how to get it working.
Do you know a code snippet or something that would allow me to open and read from a .ini file (or equivalent)?
Cheers,
Miscreant
zeroSlave
17
Years of Service
User Offline
Joined: 13th Jun 2009
Location: Springfield
Posted: 5th Jun 2012 09:26 Edited at: 5th Jun 2012 10:37
Hi. You don't really need to use Matrix1 Utils to read and write files. You can just use DBP's internal commands. Here is an example snippit for a settings file from something I have open:


If you open the help file ind DBP, goto Commands>File Commands, you can find all the info you should need.

Edit: It also "encrypts" it. Not really, but it does make it hard for someone else to just open it up and edit/view the information inside without knowing the data structure. This is what the file in the above code looks like when opened with notepad:


Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid.
Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 6th Jun 2012 05:46 Edited at: 6th Jun 2012 05:52
I agree with zeroSlave, and IanM's Matrix1 Utils are fatastic. You don't need Matrix1 Utils, the internal commands are pretty much all you need.

I'll give you a few examples of both loading and saving data to a level file. I use some specific naming conventions which are a very good idea. For example, placable objects like furniture are called Props. Players and Enemies are called Actors. Entities that control things like the operation of explosions, particles, opening of doors, etc. are called Effects. And so on...


The general idea shown below is that we take all the Props in the game and save the needed information into a file and later reload to rebuild the whole list.

All prop types have a file where all the details about what they do or look like are stored. That includes pathnames to all textures and 3D Objects.

The level file does not store this information. It stores the path to this file, where the prop is positioned, and 2 extra strings so the level editor can link doors and etc.


Saving All Props Here:


Now Loading All Props Here:


Edit:
I should mention that you need to use the "Open File" command in either situation.

Miscreant Software
16
Years of Service
User Offline
Joined: 5th Mar 2010
Location: Australia (where the kangaroos are)
Posted: 6th Jun 2012 09:27
Hey Mage and zeroSlave,
Wow, thanks heaps guys. I wasn't expecting such an indepth reply =)
I wasn't aware that you can do all that with the inbuilt command set, but its great that you can.
Now I understand what I have to do, so it shouldn't be too much of a step to implement it in my game.
Thanks guys, I wouldn't have had the foggiest without your help =)

Daniel
Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 6th Jun 2012 14:53 Edited at: 6th Jun 2012 15:22
All of what has been said is valid, but I prefer your original idea personally.

Using Matrix1 Utils Lookup feature is a good idea for writing and reading data files, because it handles grouping, sorting, searching, appending and combining information.

A good reason to not use native commands is to avoid time consuming alterations to your file format. What happens if you decide to change the structure of your file format? You will also need to rewrite your file parser. At least with the lookup tables, the only alteration required is the name of the lookup field.

Examples
Code to print the names of all characters:

INI FILE:




Link to extra lookup functions

Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 6th Jun 2012 21:55 Edited at: 6th Jun 2012 22:03
Quote: "A good reason to not use native commands is to avoid time consuming alterations to your file format. What happens if you decide to change the structure of your file format? You will also need to rewrite your file parser. At least with the lookup tables, the only alteration required is the name of the lookup field."


My imperfect solution to this is three fold.

1. Using "File End()" Command:

Tack new stuff onto the end of the file. So if I have a level format and for example suddenly I want to add in storage for what type of sky the level uses, the editor saves the whole level and tacks the sky info at the end. Then the game loads the level, at the sky part, if its the end of file a default sky is used (none - indoors), otherwise the sky data is loaded (the data may even say no sky). And you can keep doing this over and over again for more and more things. Overhead is minimal, and it's backwards compatible.

2. Use A Version Header:

Sometimes the above trick doesn't work and existing data needs to be changed. Maybe you no longer need to save a huge block of information somewhere. Make the first line of the level file store the file version number. Then you can switch to the correct loader. This method sorta sucks since it increases code in the program. It's good for a level editor, but a game should load only the most recent file version.

3. When Saving Arrays Store The Size First:

Sometimes an array needs to be re-sized, maybe your levels are getting bigger and you need to store more information. Rather than switching to a new file format, build in scalability.



Quote: "Using Matrix1 Utils Lookup feature is a good idea for writing and reading data files, because it handles grouping, sorting, searching, appending and combining information."


This is a great feature to have. I highly recommend this add-on.

IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 7th Jun 2012 15:58
I find INI files with lookups are great for certain configuration, but not so good for higher volume or binary data.

Here are my suggestions:
1. Use my datafile commands
If you can use DBPro's commands, you can use mine, but mine are faster, allow you to amend existing file data (either in existing data or appending to the file), and you can write/read arrays directly to/from them too. I believe they're easier to use too, but that ay be because I wrote them

2. Use a version header
You can then modify your data format as you go along if you choose to. You can write a program that can read any of your existing versions and write out the latest - I wouldn't put that functionality into your program, but as a separate program you'd run as a part of the 'upgrade'. The main program itself would just refuse to run with the incorrect version.

3. Don't bother with array sizes
My array commands 'just work', no matter their size, even with typed arrays. The only downside is that the array type you load into has to have a binary-level match with the array type you saved, but that's what the version header is for.

4. Chunk identifiers.
Related to versions, this is a more comprehensive way to support updates to file formats.
First, don't rely on the order of sections within your file. Instead include an identifier that specifies the type of data in the chunk, a chunk size (so you can skip to the next chunk if you don't need/understand the current chunk), a version, then the actual data - An example of this type of file format specification is the IFF file format from the days of the Amiga.

Obviously, you can pick and choose from all of the above depending on the complexity of your data.

Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 8th Jun 2012 07:31
Quote: "1. Use my datafile commands
If you can use DBPro's commands, you can use mine, but mine are faster, allow you to amend existing file data (either in existing data or appending to the file), and you can write/read arrays directly to/from them too. I believe they're easier to use too, but that ay be because I wrote them "


That's hugely awesome.

Quote: "3. Don't bother with array sizes
My array commands 'just work', no matter their size, even with typed arrays. The only downside is that the array type you load into has to have a binary-level match with the array type you saved, but that's what the version header is for."


I wonder what your thoughts are with this. You mention that your commands are useful up to a certain point then suggest falling back to a totally new file version. I would submit the idea that changing file versions is a pain in the butt, and should be a last resort option since all files would need an update. An option I would avoid like the plague. I suggested simply storing the size of the array ahead of it in the file (a primitive version of your 4th suggestion). would that not be helpful, or could it be combined with your array commands?

Quote: "4. Chunk identifiers.
Related to versions, this is a more comprehensive way to support updates to file formats.
First, don't rely on the order of sections within your file. Instead include an identifier that specifies the type of data in the chunk, a chunk size (so you can skip to the next chunk if you don't need/understand the current chunk), a version, then the actual data - An example of this type of file format specification is the IFF file format from the days of the Amiga."


This is awesome particularly if you needed to store a file inside of the level file. Suppose you wanted to store a compressed height map, you just load it into a memblock and plop the whole thing into the level file, then reverse it all to recreate.

Miscreant Software
16
Years of Service
User Offline
Joined: 5th Mar 2010
Location: Australia (where the kangaroos are)
Posted: 11th Jun 2012 08:15
Hey guys,
Thanks heaps for your responses; you guys are awesome.
I've since got my level file to work using IanM's datafile commands, and it works perfectly.
Thanks again; I couldn't have done it without you all,
Miscreant

p.s. IanM, you are a bloody legend. Matrix1 is fantastic and you deserve a medal. =)
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 11th Jun 2012 15:28
Quote: "you deserve a medal"

I have one - it's the one labelled 'MOD'

Quote: "I wonder what your thoughts are with this."

It does add a little complexity, I admit, which is why I suggest having this in a different program.

For example, suppose you have a saved typed array:


To convert that to a new format would require you to do something like:


Then you could use this type in your main program:


This works because the final Obstacle_t and Obstacle_New_t have the same data storage at a binary level (Watch out for typos).

Login to post a reply

Server time is: 2026-07-07 17:09:12
Your offset time is: 2026-07-07 17:09:12