nesdev.com
http://forums.nesdev.com/

Map data formats
http://forums.nesdev.com/viewtopic.php?f=2&t=12457
Page 3 of 3

Author:  8bitMicroGuy [ Wed Apr 08, 2015 11:59 am ]
Post subject:  Re: Map data formats

Can't open because the mapper isn't supported. Which emulator can run this?
tokumaru wrote:
Whatever the case, you should not be using the majority of the built-in RAM for levels, sacrificing other features, just because you're to lazy to come up with a more suitable compression format. Better go with WRAM in this case.

RAM compression!? You can't compress the RAM! If you can, you'd have to can decompress which would need more RAM. Also, my games are kind of SMB3 and Minecraft where blocks can be broken, opened, etc.

Do you think that loading level data from ROM only while treating the ? blocks as active objects would be a better idea? Then I'd have more space + ? blocks. Is it possible?

Author:  lidnariq [ Wed Apr 08, 2015 12:04 pm ]
Post subject:  Re: Map data formats

Mapper 28 is tepples's multi-discrete mapper.

Author:  tokumaru [ Wed Apr 08, 2015 12:24 pm ]
Post subject:  Re: Map data formats

8bitMicroGuy wrote:
RAM compression!?

I didn't mean compression in RAM (although that's also possible), I meant a compression scheme in ROM that can be decompressed on the fly.

Quote:
You can't compress the RAM! If you can, you'd have to can decompress which would need more RAM.

You most certainly can! You're thinking of compression schemes like RLE or LZ, which have to be decompressed in chunks before you can use the data, but there are other schemes that allow for random access, so you can decompress on the fly, without having to decode big blocks of data to RAM.

The Sonic games on the MD/Genesis are a good example of this: Levels are stored in the ROM using traditional LZ and Huffman schemes, but once decompressed to RAM this data is not a flat level, it's actually a map of 256x256-pixel chunks (in Sonic 1 and CD - 2, 3 and Knuckles use 128x128-pixel chunks), which are composed of 16x16-pixel metatiles. This means that levels are still compressed, in RAM, but this specific compression format is easily accessible in real-time.

Quote:
Also, my games are kind of SMB3 and Minecraft where blocks can be broken, opened, etc.

Levels can still be changed to a certain degree even when they are stored in ROM. In my engine, modifiable blocks are stored as objects, and they claim a few bytes of RAM to represent the states of each block in the object. For example, a breakable wall that's 2x8 blocks. The object has a pointer that indicates the first of the 2 bytes (16 bits) of RAM it needs to represent the state of its 16 blocks. I dedicate 128 bytes for this purpose, meaning I can have up to 1024 modifiable blocks in each level (or level section, if I prevent backtracking from a certain point), even though my levels are in ROM.

Quote:
Do you think that loading level data from ROM only while treating the ? blocks as active objects would be a better idea? Then I'd have more space + ? blocks. Is it possible?

That's how I go about it. Nearly everything that's not terrain in my engine is an active object, which can point to RAM locations where their state can be saved. This is also interesting because I can reuse screens and use objects to make them slightly different, by adding walls, platforms, and such.

Author:  8bitMicroGuy [ Wed Apr 08, 2015 12:54 pm ]
Post subject:  Re: Map data formats

So if I'd be making a quaddirectional Mario game without WRAM, but with ability for large levels with remembering ? blocks, all the unbreakable blocks, terrain and scenery would be in ROM while the ? blocks and enemies would be in RAM. Right?

Author:  tokumaru [ Wed Apr 08, 2015 1:59 pm ]
Post subject:  Re: Map data formats

8bitMicroGuy wrote:
So if I'd be making...

If you'd be making it, these decisions would be up to you, but I can tell you how I'd do it... :wink:

Quote:
...a quaddirectional Mario game without WRAM, but with ability for large levels with remembering ? blocks, all the unbreakable blocks, terrain and scenery would be in ROM while the ? blocks and enemies would be in RAM. Right?

Yeah, that's how I'd do it. Objects normally have bits in RAM indicating their existence anyway, and it would be the same for ? blocks. The only downside I can foresee is that enemies and other objects might need to collide with these special objects too (e.g. Goombas walking over ? blocks), so you'd have to do some extra collision detection.

The above is for reading everything directly from the ROM, but if you take the approach of maintaining 2 or so screens in RAM, which is also very common, you could just modify this temporary copy of the level based on the object's existence bit, and do collisions normally.

Author:  8bitMicroGuy [ Fri Apr 10, 2015 11:53 am ]
Post subject:  Re: Map data formats

Is collission detection in one frame for all of these objects possible?
How would the gameplay look like if I would skip every one of two frames because of the collissions?

I think the best method would be to compare everything with everything and then have a collission table of who collided with who.
In C, that would be bool collissions[MAX_OBJS][MAX_OBJS];
In C++, that would be vector<vector<bool>> collissions;

Author:  tokumaru [ Fri Apr 10, 2015 12:13 pm ]
Post subject:  Re: Map data formats

8bitMicroGuy wrote:
Is collission detection in one frame for all of these objects possible?

I don't know... do you plan on having a lot of objects active at once?

In my case, clusters of interactive blocks are treated as a single object, with bits specifying the existence of the individual blocks. This means that when objects aren't close to these clusters, a single collision check is enough to determine that the object isn't touching any of the blocks, so this doesn't become particularly CPU intensive.

Most of the time I try to keep enemies away from interactive blocks though, so I don't have to bother with that. For example, Bridges are treated as objects, and an enemy walking towards it will not be able to see the bridge or cross it, so it will simply bounce back and start walking the other way, since it found a ledge. I don't think anyone would find that particularly strange. Enemies simply don't do certain things, and that's normal.

Quote:
How would the gameplay look like if I would skip every one of two frames because of the collissions?

You mean skipping all updates or just collisions? Skipping everything would drop the frame rate down to 30 or 20fps, and that wouldn't be pleasant for people used to gaming at 60fps. If you mean collisions, as long as the objects don't move very fast, it should be OK to only test half the objects every other frame.

Quote:
I think the best method would be to compare everything with everything and then have a collission table of who collided with who.

Ideally yes, but everything against everything scales up fast and CPU time is precious. I'm sure that every game has objects that are not supposed to collide (such as enemies vs. items, or enemies vs. enemy projectiles), so it would be a waste of CPU time to test everything. The approach I usually suggest is creating lists for the different kinds of objects (e.g. a list of enemies, a list of items, a list of player bullets, a list of enemy bullets, etc.), and when processing each object, testing only for collisions against the types of objects that affect the object being processed.

Author:  8bitMicroGuy [ Sat Apr 11, 2015 12:12 pm ]
Post subject:  Re: Map data formats

What if a Goomba and a Koopa both have their colission codes for colission between each other and I'm at the maximum of the allowed colission checks? Or how about a fireball? Mario fires a fireball and it is overlapping an enemy, but the code of the enemy coliding with Mario gets run before that? I think I'm going for the frame skipping option. It's more stable and just.

Author:  tokumaru [ Sat Apr 11, 2015 7:28 pm ]
Post subject:  Re: Map data formats

8bitMicroGuy wrote:
What if a Goomba and a Koopa both have their colission codes for colission between each other and I'm at the maximum of the allowed colission checks?

What do you mean "maximum allowed collision checks"? I don't think such a thing exists... if you have too many objects and the engine ends up doing too many collision checks the game will lag (i.e. take longer than a frame to finish the frame calculations), that's all...

Quote:
Or how about a fireball? Mario fires a fireball and it is overlapping an enemy, but the code of the enemy coliding with Mario gets run before that?

I don't see a problem with Mario taking damage and the enemy dying at the same time... is that the issue?

Quote:
I think I'm going for the frame skipping option. It's more stable and just.

I don't see how that solves anything (not that I saw a problem to begin with)... care to give an example?

Author:  8bitMicroGuy [ Mon Apr 13, 2015 2:58 pm ]
Post subject:  Re: Map data formats

If I have special objects all over the map and enemies and Mario on the same screen, I'll surely have to frame skip in order to check all collissions and do all code. You just reminded me of SMB3 where on too many enemies, the game lags, but the music plays seamlessly. Now, a laggy game won't be nice so a 30fps game would be better. It would be something like Game Maker (where games run by default at 30fps).

Author:  Celius [ Thu Apr 30, 2015 2:32 pm ]
Post subject:  Re: Map data formats

tokumaru wrote:
I don't see a problem with Mario taking damage and the enemy dying at the same time...


Funny story: the first time I got to the end of Megaman X, both the final boss and I had 1 sliver of health left. We both hit each other at the exact same frame, and the game froze. I had to replay about an hour's worth of stages to get back to that point.

So, you just need to program accordingly so that this scenario doesn't break the engine.

Author:  8bitMicroGuy [ Fri May 01, 2015 6:12 pm ]
Post subject:  Re: Map data formats

Celius wrote:
tokumaru wrote:
I don't see a problem with Mario taking damage and the enemy dying at the same time...


Funny story: the first time I got to the end of Megaman X, both the final boss and I had 1 sliver of health left. We both hit each other at the exact same frame, and the game froze. I had to replay about an hour's worth of stages to get back to that point.

So, you just need to program accordingly so that this scenario doesn't break the engine.

LOOOOOL XDDDD

Author:  Sik [ Fri May 01, 2015 6:21 pm ]
Post subject:  Re: Map data formats

Boss: "fuck you, I'm taking you with me!" *crashes the game*

OK OK back on the original discussion. That must have been rage worthy though =P

Page 3 of 3 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/