Level storage? - Socoder

-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0\|624\|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
Socoder -> C/C++/C#/Other -> Level storage?
Sun, 27 Jun 2010, 13:14
spinal	OK, currently I am storing my test levels in an array like so... unsigned char LevelMaps[1614 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 }; --v 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? -=-=- Check out my excellent homepage!
Sun, 27 Jun 2010, 13:21
JL235	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.
Sun, 27 Jun 2010, 13:23
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. -=-=- Check out my excellent homepage!
Sun, 27 Jun 2010, 14:28
shroom_monk	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!
Sun, 27 Jun 2010, 14:37
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. --v 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. --v -=-=- Check out my excellent homepage!
Sun, 27 Jun 2010, 15:26
Jayenkai	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[RoomsRoomHeightRoomWidth]; 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)RoomHeightRoomWidth)+(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;}} --v --- 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 --v (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.. --v 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.. -=-=- ''Load, Next List!''
Sun, 27 Jun 2010, 17:41
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
Mon, 28 Jun 2010, 02:16
JL235	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.
Mon, 28 Jun 2010, 08:41
Afr0	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!
Mon, 28 Jun 2010, 09:09
Jayenkai	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! -=-=- ''Load, Next List!''
Mon, 28 Jun 2010, 09:14
Afr0	Tis not a fileformat, it's just a compression scheme.. -=-=- Afr0 Games Project Dollhouse on Github - Please fork!
Mon, 28 Jun 2010, 12:21
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. -=-=- Check out my excellent homepage!
Thu, 01 Jul 2010, 13:14
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.
Thu, 01 Jul 2010, 13:36
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
Thu, 01 Jul 2010, 13:43
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.
Thu, 01 Jul 2010, 13:56
Jayenkai	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! -=-=- ''Load, Next List!''