Large arrays

Hi experts.

I'm creating a game in C++ and I want to make a level editor for it in VB.net, because of the UI.
It's a 2D platformer, which means it has a lot of "screens" one after another, 256x240 resolution.

The entire workspace is around 7000x6000 but because that paints very slowly I've divided that in 5x5 sections, 25 "screens" of 256x240, so a total of 1280x1200 that is visible with the ability to go to the next section of that resolution. Every screen is divided in squares of 16x16, the size of a tile so every screen can have 240 tiles.

When the user paints a tile I have to store some information about that tile, it's location, type and path of the bitmap which is already a threedimensional array. If the user were to fill the visible screen with tiles, that would mean 240 times 25 = 6000 tiles which all need to be stored.
Problem number 2, there are a total of 4 layers on top of each other which would mean 4 threedimensional layers 6000 large.

Sorry lots of text.I assume this would put a strain on the program's memory usage so I was wondering what would be a good way to hold all this data without lowering the performance too much?

Thanks in advance.
LVL 2
SnapplesAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

c0ldfyr3Commented:
Well arrays are the lowest common denominator here, classes or objects add a lot of overhead so maybe arrays are the quickest, as long as you're not doing a lot of looping through 'looking' for things?
0
Jeff CertainCommented:
Classes and objects really don't add much overhead in .NET.

I'd consider an object to store the tile information -- location, type, and bitmap path information. I'd probably consider transitioning the bitmaps to be loaded from classes that use the flyweight pattern so you only keep each one in memory once. (This is the same approach text editors use for the graphics for each letter, to avoid having 3 billion letter "T"s in memory).

This leaves the question of the actual storage mechanism. I'd look at using generics, since they are type-safe and perform well. They also give you baked in functionality for Find (although that can be somewhat tricky to implement, since it requires a delegate, and the base implementation in 2.0 was poorly considered... LINQ helps alleviate many of those issues).
0
SnapplesAuthor Commented:
Sorry if I wasn't very clear, it was late here and I was kinda tired when I posted that question.

I only know about flyweight classes but I've never used one before. It looks simple enough but I'm wondering, if I store bitmaps as flyweights and give them an id, each time when the user selects a tile in my texture library, then it would have to check if that tile is already stored or not. What if the user has already painted like 1000 different tiles, when he selects a tile from my texture library, wouldn't it take long for the program to check if the selected tile is already a flyweight object or not? Since it's a new tile, I can't think of anything else to compare but the path of the bitmap.
0
Jeff CertainCommented:
Well, you could do something like implementing the flyweight pattern using a Dictionary(Of Integer, Bitmap) or Dictionary(Of String, Bitmap), depending on how you want to reference the bitmap (by name/path or ID).

Then, it becomes as simple as checking Dictionary.Contains to see if the key already exists (i.e. the bitmap is already loaded.)

However, assuming that you have a finite and reasonable number of bitmaps, you could well load them all into memory when you initialize the application. This avoids repetitive (and redundant) checks to see if the bitmap is loaded. Since your bitmaps are stored in the Tile object as a pointer, very little memory is consumed.

In addition, since Dictionary(Of T, K) requires unique keys, you're actually going to be able to do a binary tree search. I've benchmarked this using up to a million records, and it's essentially flat as it scales. (Finding the correct element in a 100-element Dictionary takes ~60ms; finding the correct element in a 1,000,000-element Dictionary takes <100ms.)
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
SnapplesAuthor Commented:
I'm really sorry, real life issues caused me to forget all about this question.
I won't be able to work on this project for a while.

Sorry again for leaving this open for so long.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Visual Basic.NET

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.