Recommended saving method.
Recommended saving method.
Recommended saving method.
Recommended saving method.
Recommended saving method.
Recommended saving method. Recommended saving method. Recommended saving method. Recommended saving method. Recommended saving method. Recommended saving method. Recommended saving method. Recommended saving method.
Recommended saving method. Recommended saving method.
Recommended saving method.
Go Back  Xtreme Visual Basic Talk > > > Recommended saving method.


Reply
 
Thread Tools Display Modes
  #1  
Old 02-06-2011, 01:29 PM
WhatsMyUsername's Avatar
WhatsMyUsername WhatsMyUsername is offline
Regular
 
Join Date: Jan 2011
Location: Currently? Costa Rica
Posts: 52
Default Recommended saving method.


My (dead now) tile-based map project. Since it died I have decided to start over, but it shouldn't be very hard now.

On the old version, I never reached the point of saving my maps for later continue working on them.

The main thing my map needs to store is the tiles data, I believe 1250000000 Tile classes at most. A Tile class contains about 6 properties (integers, a string, a boolean..)

These tile classes are sorted into Lists(Of T), and then inside other Lists(Of T) as well.

Ultimately, what I need to save are a couple Lists(Of T) than contain others lists, containing at most 250000000 Tile classes.

What saving method do you recommend me? I want to save the data into one file, and then, be able to read that file and reconstruct all the variables I once had during the moment of saving.

Long time ago I did a test of creating a .dat file from a string, and reading it back. But the string was just that: one, small string. This time I will be saving a lot more.

Maybe a .dat file is still good?
Reply With Quote
  #2  
Old 02-06-2011, 04:03 PM
PlausiblyDamp's Avatar
PlausiblyDampRecommended saving method. PlausiblyDamp is offline
Ultimate Contributor

Forum Leader
* Expert *
 
Join Date: Nov 2003
Location: Newport, Wales
Posts: 2,058
Default

Just to clarify a couple of things....

I am assuming
Quote:
1250000000 Tile classes at most
means that many instances of tiles, not that many different types of tiles... What kind of information is stored against each tile and how often does this information vary for a particular tile on a given map? e.g. if one tile was to represent "sea" would each bit o "sea" be the same as the others or would these properties vary from "sea" tile to "sea" tile?

Also when you say you are storing these tiles as List(Of ...) within a List(Of ...) what is the reason for this particular structure?

Ideally you want a file format that doesn't require the entire structure to be loaded in memory at once but could be read incrementally, the List within a List approach might make this far more difficult.
__________________
Intellectuals solve problems; geniuses prevent them.
-- Albert Einstein

Posting Guidelines Forum Rules Use the code tags
Reply With Quote
  #3  
Old 02-06-2011, 04:59 PM
WhatsMyUsername's Avatar
WhatsMyUsername WhatsMyUsername is offline
Regular
 
Join Date: Jan 2011
Location: Currently? Costa Rica
Posts: 52
Default

Yes, 1250000000 instances of one class, Tile.

A difference in the properties from a tile to another? Hmmm.... Well, there are two properties that render almost every tile instance different from each other. However, I believe it is not necessary to save such properties, since I might be able to re-create them when I am loading back the tiles data (iterating through each tile) just fine.

So, considering we ignore the existence of these two properties, one instance of Tile will have the same properties as any other, as long as both represent the same tile graphic. So yeah, if you have two "grass" tiles anywhere on the map, the "important" properties are the same. Basically, this greatly depends on the user's map, and chances are that most of the tiles will be different than each other (different tile graphic).

As for the List(Of...) part, it is the way my Tiles are ordered to create the map ultimately: First I have a List called Layers. Layers has five Lists. Each of these contain another List representing the columns, and each element in the columns list represents a row. Finally, a Tile instance is stored there. This is how I order and locate tiles if they are clicked/changed etc.

That might sound messy, but actually, the performance is very good.
Reply With Quote
  #4  
Old 02-07-2011, 04:23 AM
PlausiblyDamp's Avatar
PlausiblyDampRecommended saving method. PlausiblyDamp is offline
Ultimate Contributor

Forum Leader
* Expert *
 
Join Date: Nov 2003
Location: Newport, Wales
Posts: 2,058
Default

So does that mean each cell in your map is effectively made up of 5 tiles layered on each other or am I misunderstanding the explanation?
__________________
Intellectuals solve problems; geniuses prevent them.
-- Albert Einstein

Posting Guidelines Forum Rules Use the code tags
Reply With Quote
  #5  
Old 02-07-2011, 06:49 AM
WhatsMyUsername's Avatar
WhatsMyUsername WhatsMyUsername is offline
Regular
 
Join Date: Jan 2011
Location: Currently? Costa Rica
Posts: 52
Default

Yes. The space where one tile would fit on the map (32x32) is, essentially, one Tile instance. But, since the editor provides functionality for using five layers, it is actually five Tile instances on that space.
Reply With Quote
  #6  
Old 02-09-2011, 10:36 AM
AtmaWeapon's Avatar
AtmaWeaponRecommended saving method. AtmaWeapon is offline
Fabulous Florist

Forum Leader
* Guru *
 
Join Date: Feb 2004
Location: Austin, TX
Posts: 9,500
Default

PD I hope you don't mind me jumping in, there's some discussion in another thread that's pretty relevant since the in-memory structure usually influences the file structure.

This is mostly just some ideas as to how you *could* structure the file and what effects it might have. I don't know that there's a *best* solution.

Right now I think your data structures probably look (or looked) like this:
Code:
Dim _layer1 As List(Of List(Of Integer))
...
Dim _layer5 As List(Of List(Of Integer))
That leads itself to a file format that looks like this (the line break is for illustration only):
Code:
(map width)(map height)(layer1 tile 0)...(layer1 tile 511)(layer2 tile0)...
(layer5 tile 511)
This file format is inherently serial; if I were to write code to read it it'd look like this:
Code:
* Read rows and columns
* For i = 1 To n:
    * For each row:
        * For each column:
            * Read layer n(row, column)
For a really large file, this will obviously take some time. This is what made me think chunks would be necessary. You could sort of optimize it; with clever tricks you could jump to the right index in another layer, but all that seeking probably won't help.

What if you had a TileStack class that represented all five layers in one spot? Then your file might look like this:
Code:
(map width)(map height)(layer1 tile0)(layer2 tile0)...(layer5 tile0)
(layer1 tile1)...(layer5 tile511)
This is still a more or less serial layout; without doing some trickery with random access you have to load the entire file before you can start rendering. If you use random access, you can do neat things like loading the first screen's worth of tiles, starting the rendering loop, then loading the rest of the tiles on a background thread.

The chunked data format kind of runs with that theme; rather than storing the entire array as a serial structure, it stores "chunks" which are more or less viewport regions. Let's say you decide on 50x50 chunks:
Code:
(map width)(map height)(chunk 0)(chunk1)...(chunk 49)

Chunk 0 might look like:
(layer1 tile0)(layer2 tile0)...(layer5 tile0)...(layer5 tile49)
In this case, you use random access to jump to the right chunk for the viewport location and start loading that chunk.

What about saving the file? That's half the battle too. I'll switch to bullet list format to discuss the pros and cons:
  • The initial serial approach lends itself best to saving the file all in one go. With some clever random access trickery you could save just the changed portions, but it'd require some extra mechanisms to figure out exactly what tiles had been changed. Not to mention since the layers are dispersed saving one "stack" involves 5 seeks. It's probably cheaper to just write the whole file.
  • This is still a serial approach. Saving only changes still involves some external mechanism that would more or less amount to a new 2D array of booleans. However, saving a stack involves 1 seek to get to the right spot then 5 writes; much more efficient. It might be worth the effort.
  • This approach is by definition a random access approach. Since you might decide to not load the entire file in-memory, you always know any changes *must* be in the loaded chunks. If you're discarding chunks that aren't visible, you can choose to auto-save them to the file as they're discarded.

The best approach is the one with the simplest code and adequate performance. To that end, I think the "tile stack" approach that saves/loads the entire file at once is probably a good first attempt. If that's too slow, try an optimization like using random access to load the first visible screen and loading the rest of the tiles asynchronously (async code is one of my specialties, so feel free to ask!) If that's *still* too slow for you, then the chunked approach might be something to try.
__________________
.NET Resources
My FAQ threads | Tutor's Corner | Code Library
I would bet money 2/3 of .NET questions are already answered in one of these three places.
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Forum Jump

Advertisement:





Free Publications
The ASP.NET 2.0 Anthology
101 Essential Tips, Tricks & Hacks - Free 156 Page Preview. Learn the most practical features and best approaches for ASP.NET.
subscribe
Programmers Heaven C# School Book -Free 338 Page eBook
The Programmers Heaven C# School book covers the .NET framework and the C# language.
subscribe
Build Your Own ASP.NET 3.5 Web Site Using C# & VB, 3rd Edition - Free 219 Page Preview!
This comprehensive step-by-step guide will help get your database-driven ASP.NET web site up and running in no time..
subscribe
Recommended saving method.
Recommended saving method.
Recommended saving method. Recommended saving method.
Recommended saving method.
Recommended saving method.
Recommended saving method. Recommended saving method. Recommended saving method. Recommended saving method. Recommended saving method. Recommended saving method. Recommended saving method.
Recommended saving method.
Recommended saving method.
 
Recommended saving method.
Recommended saving method.
 
-->