How do I make my arrays smaller... I'm using a 16x16 grid based system for editing and saving levels. And say I want a frame that's 3000 x 3000 then 3000 / 16 = array dimensions right. But my arrays in this case are around half a mega byte. I know why this is (saving all gridspaces as 0 etc) but is there a way to get around huuuuuge level files? Like how the hell does pod do it in TU?
Assault Andy Administrator
I make other people create vaporware
Registered 29/07/2002
Points 5686
5th April, 2007 at 05:14:16 -
There's an example I made which shows you how to make levels with the binary object. The filesizes will be tiny. A map 3000x3000 (with gridsize 16x16) will be 35kb big (according to my calculations ), using my method. Each tile takes up 1 byte of space:
Assault Andy Administrator
I make other people create vaporware
Registered 29/07/2002
Points 5686
5th April, 2007 at 07:01:19 -
You can't improve the array object because of the way it saves data. It takes up heaps of room for each piece of data you write to it. Open in notepad, you can see there is heaps of wasted space. That's why my method is effective. I have created an array filetype of my own. It's more efficient. 1 byte = 1 piece of information in the array. It's not that complicated if you look at the example and read how it works. It's the same as the array object, it just has different actions and conditions for writing to\retrieving the data. I've already made the code for them, you just have to change them to match your game. Good luck.
If the array object is easier for you to use / understand, just use the thing! It's the end result most people will see, and not how efficient the coding or filesize is. Take all the arrays for maps and whatever- Once you include them in a folder with your finished game, and zip it, it'll reduce the filesize a bunch for downloading ease. And once the end user has it and unzips it? Who cares!? It won't be THAT big in the end, will it? Everybody will have a hard drive that can handle your game unless you plan on making a Morrowind-sized deal ( > 1 GB )
If you're making a game that constantly has to update the array somehow (changes in obstacles, destructable trees, etc- My game Equin Adventures does this A LOT during gameplay) then maybe you should try the binary method above.
--
"Del Duio has received 0 trophies. Click here to see them all."
"To be a true ninja you must first pick the most stealthy of our assorted combat suits. Might I suggest the bright neon orange?"
DXF Games, coming next: Hasslevania 2- This Space for Rent!
Also- you are wasting a ton of space with all the empty spaces that don't contain a tile (or you might be at least). If you have a ton of this, you can save each tile as 3 numbers- (tile, x, y). This adds information, but then the tiles can be saved in any order, and can be any (varying) size for that matter, and you dont worry about any wasted info. Or, if "plaforms" tend to appear all in a row, you can just save uninteruptted rows, with one start position.... ie.. (startx, starty, tile1, tile2, tile3, etc...)
All of my old map arrays contain a single text character for every tile of that map section (which was made up of a double-dimensional array), so that there were never any blank spaces. You would have something like this:
And when the game loaded these and went to display it, it'd go character by character, line by line from the actual position of the player and show a water tile for every ".", some grass for every "*", a cave for the "O" and etc. Maybe you could do something simple like that?
--
"Del Duio has received 0 trophies. Click here to see them all."
"To be a true ninja you must first pick the most stealthy of our assorted combat suits. Might I suggest the bright neon orange?"
DXF Games, coming next: Hasslevania 2- This Space for Rent!
Assault Andy Administrator
I make other people create vaporware
Registered 29/07/2002
Points 5686
5th April, 2007 at 18:58:51 -
Zipping the maps is a good idea. However there are a few problems with it. Firstly the zip objects are terrible and buggy. People have reported many random crashes from them, and functions that do not work properly. Secondly only one of the objects can extract a single file from a zip, and that doesn't come with working password support (even though you can use your own encryption method.)
If you want to try something strange, you could do something similar to what I had in my dead little Yoshi fangame.
The entire level was made up of pages (each one a screen of 20x15 tiles), and each level would be 16x16 screens across. For every space I stored the tile's visible data (what it looked like), its tile property (if it was empty/ground/platform/slope/etc.), its sprite data (what sprite went there), and the sprite's value (an extra variable to do extra stuff). Thus, I had 16x16x20x15x4 to each map, which ends up being quite a large number.
So what I did was store each page as a string inside one space of a 3-dimensional array. Thus space 0x0x0 would be 300 bytes, the visible data for the upper-left page, and 0x0x1 would be 300 bytes of the upper-left page's tile property data, and so on.
This meant, however, that every level had to be the full 16x16 pages, and would end up with some large files. So I had a system where I could close the unused pages, reducing the bytes it used from 1500 to 1 (or however small it can get in an array). Additionally, I could "block-in" a page with a single tile for solid parts, and save even more space.
If you look at this image of the old Yoshi fangame editor http://www.geocities.com/f4fth/yoshi-editor.jpg you can see on the minimap the pages that were used, closed, and blocked-in, and you can see on the main editing screen how a blocked-in page would only take up one tiles' worth of data. And when you load the level, you just send a fast loop through your array to turn the closed and blocked-in portions into usable data.
So there are certainly ways to shrink level size, you just have to get creative.
But I'm gonna learn Assault Andy's method someday with the binary object, I mean it would serve me greatly.. Shame I don't know much bout the binary object in the first place.
could you pack more than one value into each byte? If you only have 4 different types of tile, you can fit 4 tiles per byte (2 bits each) with a bit of maths.
also you could try coding some sort of run-length encoding (saving repeating data as one item with a 'length' stored)
zip extension sounds much better than both of those, though...
"Say you're hanging from a huge cliff at the top of mt. everest and a guy comes along and says he'll save you, and proceeds to throw religious pamphlets at you while simultaniously giving a sermon." - Dustin G
Advertisement
Post Reply
Edited by the Author.
