It is currently Wed Dec 13, 2017 9:54 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 43 posts ]  Go to page Previous  1, 2, 3
Author Message
 Post subject: Re: Map data formats
PostPosted: Wed Apr 08, 2015 11:59 am 
Offline

Joined: Sun Mar 08, 2015 12:23 pm
Posts: 251
Location: Croatia
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?


Top
 Profile  
 
 Post subject: Re: Map data formats
PostPosted: Wed Apr 08, 2015 12:04 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6513
Location: Seattle
Mapper 28 is tepples's multi-discrete mapper.


Top
 Profile  
 
 Post subject: Re: Map data formats
PostPosted: Wed Apr 08, 2015 12:24 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
 Post subject: Re: Map data formats
PostPosted: Wed Apr 08, 2015 12:54 pm 
Offline

Joined: Sun Mar 08, 2015 12:23 pm
Posts: 251
Location: Croatia
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?


Top
 Profile  
 
 Post subject: Re: Map data formats
PostPosted: Wed Apr 08, 2015 1:59 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
 Post subject: Re: Map data formats
PostPosted: Fri Apr 10, 2015 11:53 am 
Offline

Joined: Sun Mar 08, 2015 12:23 pm
Posts: 251
Location: Croatia
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;


Top
 Profile  
 
 Post subject: Re: Map data formats
PostPosted: Fri Apr 10, 2015 12:13 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
 Post subject: Re: Map data formats
PostPosted: Sat Apr 11, 2015 12:12 pm 
Offline

Joined: Sun Mar 08, 2015 12:23 pm
Posts: 251
Location: Croatia
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.


Top
 Profile  
 
 Post subject: Re: Map data formats
PostPosted: Sat Apr 11, 2015 7:28 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
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?


Top
 Profile  
 
 Post subject: Re: Map data formats
PostPosted: Mon Apr 13, 2015 2:58 pm 
Offline

Joined: Sun Mar 08, 2015 12:23 pm
Posts: 251
Location: Croatia
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).


Top
 Profile  
 
 Post subject: Re: Map data formats
PostPosted: Thu Apr 30, 2015 2:32 pm 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2142
Location: Minneapolis, Minnesota, United States
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.


Top
 Profile  
 
 Post subject: Re: Map data formats
PostPosted: Fri May 01, 2015 6:12 pm 
Offline

Joined: Sun Mar 08, 2015 12:23 pm
Posts: 251
Location: Croatia
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


Top
 Profile  
 
 Post subject: Re: Map data formats
PostPosted: Fri May 01, 2015 6:21 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 43 posts ]  Go to page Previous  1, 2, 3

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group