Printable View
I was wondering what's the easiest way to do an array that can be resized at runtime *and* saved to a file?
Or would I be better off using the binary object and multiplying to get the position I need? (It would be 3 dimensions, with the first and second dimensions being of variable size while the third is of a fixed size)
mmf's built-in array can be resized at runtime, is up to 3 dimensions and has save/load too.
to resize it, just use an out of bound index, it will be extended. To reduce it I think you'll have to recreate it...
Yeah, that's the thing... files have the potential to get huge QUICKLY, so they need to be shrinkable...
I didn't know it could auto-resize though, so I could probably if worst comes to the worst find a way to work with that (maybe copy into a second one that won't expand beyond the needed size, then save from that one?)
Yeah that's what you're suppost to do. ;) Just make sure you only copy non-zero values or the array size will stay the same.Quote:
Originally Posted by Namida
Thanks. =)
Although, I could easily find the size that's meant to be copied from other sources, so I'd just have to only read up to that point.
Yeah but an undefined value takes less file space and memeory than a value defined as 0. ;)
No, what I meant is... set the initial size of the new array to 1,1,4 (since the 3rd dimension will always have a size of 4), then, say, if it's meant to be up to 30 by 30 but at one point it was 40 by 40, it'll only copy the values up to 30 by 30. This 30 by 30 size can be found from other sources, of course.
I've decided to avoid all this trouble by using the Binary object. I've come up with algorithms for resizing and finding the right point to move to, and it has the added advantages of being able to store other data before and/or after the main level data (what the array would've stored), as well as using bytes rather than longs which reduces output filesize.
Keep in mind, the range of a byte is only 0 to 255. (Or -128 to +127)
Well aware of that, but thanks anyway. =) Considering my limited graphics ability, I don't think I'll need more than 255 tiles per layer, especially since it has 5 layers. While layer 3 is technical data (and thus won't be displayed at all during play, only in the editor) and layer 4 is active objects, the other 3 layers are for regular tiles, and having a different tileset on each one is fully supported - allowing for a potential 510 different tiles that will always appear behind objects, and 765 altogether.
Seems like you're limiting yourself for the sake of using bytes instead of shorts. (unless there is some extra overhead)
If each layer must have it's own tileset, then you have to waste tile space on tiles you want to appear in multiple layers. e.g. a destroyed building scrolling in the background, with similar ruined buildings in the foreground.
You'd also be amazed at how quickly tiles get used up on things, once you start adding detail.
e.g. 3 variations of ground to reduce repetition, details, such as flowers or broken bricks in a wall.
For example, a Forced Perspective, or Top-Down game can use lots of tiles for edges, such as waters edge, depending on what you need, uses lots of tiles. e.g.
top left corner water,
top water,
top right corner water,
side left water,
side right water,
full water,
bottom left corner water,
bottom water,
bottom right corner water,
edge on both sides vert water,
edge on both sides horiz water,
Then the inverse, i.e. land where the water was.
top left corner land,
top land,
top right corner land,
side left land,
side right land,
full land,
bottom left corner land,
bottom land,
bottom right corner land,
edge on both sides vert land,
edge on both sides horiz land,
then add the special tiles, e.g.
+ shape of water to allow connections
T shape of water to allow connections and it's rotations.
that's a lot of tiles. then add one or two variations to some of these (usually the straight edges, as they're used most)
And you're quickly over 25 tiles alone, just for the edge of water. Now do the same for different locations. e.g. Lava instead of water, sea with beaches instead of rivers.
Now, while the example may not fit if you're doing a side-on game, the message is the same. You'd be amazed at how quickly you use up tiles in a tileset.
If you use the Binary Array object (like Nifflas does in his games for map files) you can have multiple workspaces of binary data and save them all to one, compressed file.
ok, so that allows for multiple levels?
I'm presuming you can select the workspaces via name or something?
However, the Binary Array also allows intergers, shorts, bytes.
My point is that using bytes in the Binary Array limits you to a tileset which I would argue is too small for many tile based games.
I'd say use shorts in the Binary Array and it's all good.
(for me it's a moot point at the moment until I get the Binary Array working. I need to do a lot more tests into how it works as there is no documentation.)
Yes, it's a very useful extension but there is a need for a documentation to know how it works in the background. We are not all programmers by default. I don't really understand this extension but I would use it gladly...Quote:
Originally Posted by BREK
Maybe there is a chance to get a documentation for this extension?
I think Greyhill's (Ross') documentations are very exemplary. :)
Nifflas made a level editor example.. should be on the forums somewhere. I'd love to document all my old extensions, but I really don't have time. Maybe someone who knows how they work would like to document them on FusionWiki? I'd be glad to answer any questions..
It is indeed a side-on game (platformer). My graphics ability is quite limited, and I'm focused more on gameplay than graphics, so I don't see the need for more than 255 tiles per layer...
Interesting.
I'm actually working on a level editor that uses everything mentioned here in some degree.
The Level Editor uses an MMF CNC Array for flexibility and expandability, then runs a "Conversion Loop" that copies all of the data to Nifflas Binary Array object to save it as a workspace file. Then when building the stage in the engine, it reconverts to CNC Array (for speed and flexibility).
It has 6 layers: Background, Foreground, Sprites Objects, Object Banks, Collisions, and HUD.
Since its saved as a Compressed Workspace File, all of the games levels are stored in one file.
I could share an example file if anyone is interested.
Have a look at this:Quote:
Originally Posted by JimJam
Speed comparison of data storage objects.
Somebody knows how about the Binary Array according this overview?
Yes please!Quote:
Originally Posted by JimJam
As well as the "background" and "foreground" layer, mine also has an extra tiles layer *above* all else... which is mostly used for 2.5D-type effects.
Nifflas' editor is http://nifflas.ni2.se/?page=Multimedia+Fusion+2 listed under Simple Level Editor.
I havent had much time to work on my level maker. But just a quick note about the "Limit of bytes"
If you say a byte for tilesets is limited to only 255 tiles, thats not true. Just do what I did. Use two bytes for the value of each tile, add them together, and you now have 510 tiles per sheet to work with.
For more, increase number of bytes used.
The alternative method to use (which I use for my game objects) is to have one byte record which tileset image to use (a number of 255) and then use the next byte for number of the tile from that sheet (of 255).
Now any given tile on the map can be one of 1,375 different tiles in your game library. Again, use a 3rd byte and add it to the "Images" byte, and you have 130,050 tiles to work with.
...Seriously?
Multiply the second byte by 256, and then add it to the first. In only two bytes, you can now store 65535 possible tiles (plus blank).
Oops. Yeah I messed up my math. I meant to use pow2, but I pressed Times 2 on my calculator. Looking at that post again, I don't even know how I got those numbers.
Ahhh! Yup. that'd solve it. :)
You could just use a short instead!
Yes. =P
But that's so much stuff to replace, especially considering some formulas that determine the position in the file, based on it using bytes.
And as I said, in my case, I don't *need* more than 255 tiles. Especially when there's two layers that are both below everything else available, already allowing 510 background tiles.
So how is your multiplication method any better than just using a short in the first place? They're both two bytes..Quote:
Originally Posted by Namida
I'm not the one considering a two-byte system though, I'm perfectly happy with single-byte. =)