Level storage?/Forum (SoCoder)

Forum Home

C/C++/C#/Other

Level storage?

User

Message

Posted : Sunday, 27 June 2010, 12:14 | Permalink | Mark Here

spinal

OK, currently I am storing my test levels in an array like so...

unsigned char LevelMaps[16*14 * 2] = {
1,0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
1,0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
1,0,0,0,0,0,1,1,1,1,1,1,1,1,1,1,
1,0,0,0,0,0,1,1,1,1,1,1,1,1,1,1,
1,0,0,0,0,0,1,1,1,1,1,1,1,1,1,1,
1,0,0,0,0,0,1,1,1,1,1,1,1,1,1,1,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,0,1,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,1,1,0,0,0,0,0,0,0,0,0,0,1,
1,0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,6,
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
1,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,

1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,0,0,0,1,0,1,0,1,1,1,1,1,1,
1,0,0,0,0,1,0,0,1,0,0,0,0,0,0,1,
1,0,0,0,1,0,0,0,1,0,0,0,0,0,0,1,
1,0,0,1,0,0,1,0,1,0,0,0,0,0,0,1,
1,0,1,0,0,0,0,0,1,0,0,0,0,0,0,1,
6,0,0,0,0,0,1,0,0,0,0,0,0,0,0,1,
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,1,
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
};

-->

However, this is way less than ideal. My game is [hopefully] going to be a room based game, rather than scrolling, so I will require a method of storing these rooms and loading them back. Now, if I were using a modern machine, I would simply create a binary file for each room and name it depending on its location, e.g. room_x_y.bin and then load it when the character wanted to enter that room. However I am doing this on a SNES

Anyone got any ideas for how I can store my rooms?

-----

3DS - 1762-2660-3218

Posted : Sunday, 27 June 2010, 12:21 | Permalink | Mark Here

JL235

WW Entries : 7

My personal recommendation is to use XML compressed to a .zip. As it's textual (and very repetative) it should compress to a very high degree. You can find a library to use for decompressing the rooms on the fly when they are loaded. Compression should also improve space for text based non-XML formats.

If your storing rooms as seperate files then I'd recommend concatonating them into one file with an index at the beginning listing where the room is contained in that file. You can then seek to that section and read on to load. The reason why I recommend this is because it should use less disk sectors and so should use the disk more efficiently.

-----
PlayMyCode.com - build and play in your browser, Blog, Twitter.

Posted : Sunday, 27 June 2010, 12:23 | Permalink | Mark Here

spinal

SNES = almost no tools. Zip and xml ain't going to happen, for one, no file system to store them on, for two, the SNES is like 3mhz, it would take forever to unzip something. ----- 3DS - 1762-2660-3218

Posted : Sunday, 27 June 2010, 13:28 | Permalink | Mark Here

shroom_monk

WW Entries : 8

But if you don't have a file system, surely storing them in an array like that is the only way of doing it? Sorry, I'm slightly confused... what are the limitations of the SNES, and why is your given method unsuitable? ----- A mushroom a day keeps the doctor away... Keep It Simple, Shroom!

Posted : Sunday, 27 June 2010, 13:37 | Permalink | Mark Here

spinal

my rooms will not be set out in a grid like this 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 etc. --> so i can not access the array in a simple way like roomnumber[x+8*y] or whatever. they will be more like 1 2 3 10 11 4 9 5 6 7 8 14 12 13 15 etc. --> ----- 3DS - 1762-2660-3218

Posted : Sunday, 27 June 2010, 14:26 | Permalink | Mark Here

Jayenkai

WW Entries : 103

That's ok, don't worry, it's all happily doable.

Just flatfile the sucker.

RoomWidth=32;
RoomHeight=24;
Rooms=100;
RoomX[Rooms];
RoomY[Rooms];
RoomData[Rooms*RoomHeight*RoomWidth];



RoomX[1]=10;RoomY[1]=10;
// Room 1 is at 10,10

RoomX[2]=11;RoomY[2]=10;
// Room 2 is to the right

RoomX[3]=11;RoomY[3]=11;
// Room 3 is below room 2.



for (room=0;r<Rooms;r++) {
for (x=0;x<RoomWidth;x++) {
for (y=0;y<RoomHeight;y++) {
   RoomData[((room-1)*RoomHeight*RoomWidth)+(y*RoomWidth)+x]=whatever
}
}
}

PlayerRoomX=10;PlayerRoomY=10;
PlayerRoom=0;
for (n=0;n<rooms;n++) {if (RoomX[n]==PlayerRoomX && RoomY[n]==PlayerRoomY) {PlayerRoom=n;}}

-->

---

in a file, you'd have the data structured like....

10,10
0,0,0,0,0
0,1,1,1,1
0,1,0,0,0
0,1,1,1,1
0,0,0,0,0
11,10
0,0,0,0,0
1,1,1,1,0
0,0,0,1,0
1,1,0,1,0
0,1,0,1,0
11,11
0,1,0,1,0
1,1,0,1,1
1,0,0,0,1
1,0,0,0,1
1,1,1,1,1

-->
(but, you know, less ascii-comma-ish, and more raw data!)
and so on..

Then, onto compression...

---

A quick and easy compression is the "How many, Of What" format. Doesn't work with Hello World...

HELLO WORLD
1H1E2L1O1 1W1O1R1L1D

But does work nicely with walls..

0000000
0111110
0122210
0122210
0111110
0000000
or
000000001111100122210012221001111100000000
becomes
80512011321120113211205180
Which is a wee bit smaller..

If you're using raw data, and have a maximum 15 objects, you can go...

     v-- Of What
0000|0000
^-- How many..

-->

So, if there's 15 of object #1
11110001 = 241
if there's 3 of object #0
00110000 = 48
and so on..

It's small and neat, and really quick to flick through, in order to temporarily copy that room into a "RoomUsing[]" array, especially if you know where the data is, in memory..

Your main problem with compression, though, is that you need to then have a seperate array with WhereRoomDataStarts[], because all the rooms data chunks aren't going to be an exact size..

-----

Posted : Sunday, 27 June 2010, 16:41 | Permalink | Mark Here

mindstorm8191

Well spinal, how about this: create a level editor of your own, to work on the PC. From there you can create your levels, adding whatever detail and depth that you desire. Once you're finished, your editor will output array contents, instead of a file of some form, which you can then copy and paste into your SNES development tools. You may end up with really large pieces of text to paste, but there shouldn't be any limits to what you can do.

Think that will work?

-----
Vesuvius web game

Posted : Monday, 28 June 2010, 01:16 | Permalink | Mark Here

JL235

WW Entries : 7

For the record, Jay's alorithm is Run Length Encoding which is used in fax machines and JPEG.

You could also take a look at Huffman Coding. Bit codes are generated to replace each number. No bit code starts with another existing bit code (so they read as being unique from left to right) and get longer over time as you generate more. The idea is that the popular numbers in your file (like 0) will be replaced with the very short bit codes that you generate, whilst less common numbers get the longer bit codes.

-----
PlayMyCode.com - build and play in your browser, Blog, Twitter.

Posted : Monday, 28 June 2010, 07:41 | Permalink | Mark Here

Afr0

WW Entries : 3

You could also take a look at the DBPF (DataBase Packed Format) compression scheme, which is based on Huffman, and presumably (marginally) better. The downside is that it's a complete bitch to implement and maintain. ----- Afr0 Games Project Dollhouse on Github - Please fork!

Posted : Monday, 28 June 2010, 08:09 | Permalink | Mark Here

Jayenkai

WW Entries : 103

Again with the file formats!

No need to get complicated. The memory used by storage, I'd imagine, isn't an issue.. The main difficulty will be getting it from "compressed chaotic data" to "Usable array" in a short amount of time.

Remember, this is a SNES we're talking about.
It can't do a whole lot, and if you try to make it do a whole lot, you end up with those nasty loading screens between rooms.
Eugh!!

Remember how long Lemmings took to load a level! Horrible stuff..
Lovely game, but.. took AGES!

-----

Posted : Monday, 28 June 2010, 08:14 | Permalink | Mark Here

Afr0

WW Entries : 3

Tis not a fileformat, it's just a compression scheme.. ----- Afr0 Games Project Dollhouse on Github - Please fork!

Posted : Monday, 28 June 2010, 11:21 | Permalink | Mark Here

spinal

I'm going for a similar level format to jays suggestion, however, rather than storing the room location, I will have 4 bytes representing the room number above, below, left and right of that room. Each room will be given a new number when it is added to the array to be accessed like so...

roomdata[roomnumber*(roomsize+4)] or similar.
Compression really isn't an issue as the data will be stored in rom space, rather than ram, so I have a few mb to play with and if thats not enough i will just change the size of the output rom.

-----

3DS - 1762-2660-3218

Posted : Thursday, 01 July 2010, 12:14 | Permalink | Mark Here

Andy_A

Why not store your values (0-15) as eight 4-bit values per unsigned long? To encode or decode would be rather trivial using the "<<", ">>", "&" operators in C, and would reduce storage requirements to only 12.5% of original.

Posted : Thursday, 01 July 2010, 12:36 | Permalink | Mark Here

Mog

@Andy_A: I've ran into a project that used a similar approach ("Nybbles") and it worked fairly well to be honest. only issue is the limited amount of information you can portray, but if it's just a simple game that keeps under 15 tiles, then that approach is amazing for obscurity and compression (since i don't think a "nybble" is exactly the most well-known container...)

-----
I am Busy Mongoose - My Website

Dev PC: AMD 8150-FX, 16gb Ram, GeForce GTX 680 2gb

Current Project: Pyroxene

Posted : Thursday, 01 July 2010, 12:43 | Permalink | Mark Here

Andy_A

@Mog: Yeah, in the good ol' days (c64 era) everything was stored in nybbles and bytes. The worst part was that if you didn't write some type of editor, you had to do the binary translating yourself.

Posted : Thursday, 01 July 2010, 12:56 | Permalink | Mark Here

Jayenkai

WW Entries : 103

Nothing wrong with that.. That's'a codin'!!!! So long as you can keep your tiles small, you can do all manner of neat binary tricks! -----