|
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... 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 so i can not access the array in a simple way like roomnumber[x+8*y] or whatever. they will be more like -=-=- 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. --- in a file, you'd have the data structured like.... (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... 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!''
|
|
|
| |||
|
| ||||