Arrays vs. Images - Which would better for "information" maps

[Chrille]

I've reached the point in the development of my game where I can start putting together the rooms/scenes. My initial thought was to use images as color masks to tell the game what's at a certain coordinate. The .png image files would be around 500x500 pixels max, at about 10kb each, with possibly 2-3 per room (although none of them would actually visible since I use the "Get RGB At" function). I could do this with arrays, but a 500x500 size array turns out bigger than the image. Editing the scene info would also be easier if I just edited the image.

Now, I've gotten the impression here that using too many images might be a bad idea if you intend to port a game to other platforms, like Android-machines. Will deleting active objects and active pictures free up the ram? How would using arrays compare to this? Any recommendations?



Finally, I also had the idea of using one big array to handle all the text in my game, such as descriptions and dialogue. This would make things very easy if I ever wanted to translate the game to a different language. Once again though, the worry of reading from array files that are too large is there.

[UltimateWalrus]

The reason the array file turns out bigger that the image file is because the image is compressed as a *.png, whereas array files have no compression. When you load the *.png into memory, it needs to be decompressed and will actually take almost as much memory as array, in fact it may take the same amount. An int value is 4 bytes, whereas color values are 3 bytes (1 each for R, G, and B), but may wind up using an int in memory anyway.

I would strongly suggest you use the most clean and straightforward method for your game. It depends on the game whether it would be easier to just use an array, or if you want the image-editing benefits that go with using an image. Pre-mature optimization always leads to horrible code.

As for using a big array to handle all the text in your game, unless you are having your characters recite War and Peace in its entirety, I'd be very surprised if the memory footprint was anything but negligible. Text data is very low bandwidth.

[Gustav]

I recommend to use one Array per level/location. Arrays are much faster accessible than images. But maybe images would consume less memory because they are compressed. Here is some info about the getRGB expression from today.

If you use a huge array containing all the text etc. it would consume a lot of memory for data you won't really need at this time. If you just have one array per level you would save a lot of memory. And you are much more flexible in placing the content in the array.

A Text array consums much more memory than a Number array even if you just save a value converted as string.
Because of this I would split the content of your level array in two arrays. One (Text!) array contains every Text (also better for more easy translation without the other data) and one (Number!) array contains only values like information maps.

To reduce the size on disc you can zip the arrays with the Archive object. Normally after zipping arrays getting much smaller. You also can "protect" them using a password.


An example:

Imagine the following bitmap represents your array.

Attachment 14956

All black pixel are information maps (just values) of the current level.
All red pixel are dialogue and other text or as text saved values.
All grey pixel are unused space inside the array.

To use strings and values in one array you have to use a Text array and convert values into text while saving and back into values while reading. And we know that Text arrays are much bigger than Number arrays. So this isn't a good idea. Another point is that the huge black data resizes the array dimensions so that on the right lower end behind the red pixel arises a gap. And all grey pixel are also stored in memory.
So the best way is to split the black part in an own Number array and arrange the red part in the Text array so that the grey area is as small as possible.

[Chrille]

Thanks for your advice guys, now I know better what to expect.

As a follow-up question regarding the large string arrays, if a large array did use quite a bit of memory. Would loading the file, reading the information needed, and then clearing it right after improve things, or would the process of loading it frequently affect performance more than if it was in memory all the time?

[Gustav]

It depends on the amount of data but I would prefer to leave the array in memory to have access and work with it all the time.

So if you need a specific text, read it directly when needed from the array. I wouldn't transfer text out of the array into strings and read from there...

[UltimateWalrus]

Gustav, the Archive object is a good suggestion and I agree that storing Values in a Text array is a bad idea all around. It was good to suggest that if you want values and strings, have two separate arrays.

However, I have to disagree on a couple of points. An image will not be compressed in memory; it has to be decompressed in memory to be used in the game. Otherwise a huge overhead would be wasted uncompressing the image onto the screen each game cycle.

Also, I disagree that text arrays inherently consume a huge amount of data. Maybe if you are abusing them by storing values as text, this will be the case. But if you are storing dialog, let's put things in perspective:

One 512x512 sprite:
512 * 512 * 3 = 786,432 bytes, or 768 KB.

A 500-word essay (assuming average English word length of 5.1 characters and a space between each word):
500 * 5.1 + 500 * 1 = 3050 bytes, or 3 KB.

Thanks for your advice guys, now I know better what to expect.

As a follow-up question regarding the large string arrays, if a large array did use quite a bit of memory. Would loading the file, reading the information needed, and then clearing it right after improve things, or would the process of loading it frequently affect performance more than if it was in memory all the time?

Again I am begging you, just use the cleanest and most straightforward method and only worry about performance if it becomes a problem :]

That having been said, Arrays expand to hold the data they need to hold, but they never get smaller. If you really have to free up the memory you have to restart the frame. I wouldn't worry about this though. In 16+ years of using Clickteam products I have never had to do this.

[Chrille]

I was planning on handling pretty much the entire game in one frame and hadn't thought about needing to restart it, but if that's the way to free up memory I'll have to.

Once again, excellent advice folks!

[Gustav]

An image will not be compressed in memory; it has to be decompressed in memory to be used in the game. Otherwise a huge overhead would be wasted uncompressing the image onto the screen each game cycle.

I understand what you mean. But I was referring to something said by Yves about images in memory here.

That having been said, Arrays expand to hold the data they need to hold, but they never get smaller.

That's right. If you later want to shrink an array you have to copy all data in a new array. For example if you resized it by fault with too high values.

If you really have to free up the memory you have to restart the frame.

That's wrong. If you load another (smaller) array file in the same Array object the existing (bigger) array will be completely erased.
Just tested it. The Debugger shows how the memory is decreasing again, the dimensions of the array too.


I found out something interesting while testing. It seems that an (Number) Array containing image data consumes less memory than a Active containing the same data as image.
This would be the answer to the original question of this topic.

But these are hugh decisions to make for the base of a game. So it's always a good idea to test everything and evaluate the results.
Means... Fill arrays with lots of example data and look at the Debugger memory display. Load and save them, erase them and watch the display.
And so on. This will help a lot to understand the behavior of the objects and you can make good decisions.

[UltimateWalrus]

Ah, I didn't know that about the image compression! I stand corrected :]

You're also correct about re-loading a smaller file, my mind was only on using the Array dynamically during runtime for some reason.

Perhaps your findings about image data consumption have something to do with the fact that they must be stored with power-of-two dimensions on the graphics card? (64, 128, 256, etc.)

[Gustav]

Perhaps your findings about image data consumption have something to do with the fact that they must be stored with power-of-two dimensions on the graphics card? (64, 128, 256, etc.)

Ah... I didn't thought about this!