>Well, most NES games tend to be doing a lot of work "just off screen".What kind of work? Preparing code and loading it from the VRAM?

I mean that enemies/objects tend to appear and disappear just before they enter the screen, new tiles for scrolling backgrounds can be done long before or just before the edge of the screen. (In some cases, just after, like the attribute glitching you see in SMB3.) If you were to extend the background, you still don't know where to put the sprites at the edges.

Mr. Blah wrote:

>And as rainwarrior mentioned, sprites will pop in and out of visibility as they go through the extended background.Why's this? Imperfect extending?

If the game keeps track of enemies offscreen, whatever format that's in will have nothing to do with what's displayed onscreen, so there's no automatable way to pick up that information (presuming it even exists). Onscreen sprites have 8-bit values for their coordinates, there's no way to specify one that should be offscreen, so you can't get it from the PPU's sprite position data.

As I said, the only thing to do, really, is rewrite the game. Either rebuild it on some non-NES platform, or extend an NES emulator with new (fake) hardware capabilities and rewrite as much of the game as you need to do this.

Same tile and same Y coordinate could just be one or more moving platforms though...

But if there are 8 sprites immediately in sequence that have the same Y position and tile number very early in the sprite table (possibly excluding sprite 0), chances are good it's an intentional mask. I'm using this to detect masking, but it fails to detect Castlevania 2's swamp for now. I couldn't imagine making a moving platform 8 sprites wide with contiguous sprites that appear before any other sprite in the sprite table.

>Edit: NES hardware can be extended via mappers or whatever else, but there's no way I can think of to do this without hacking each individual game you want to extend. Reading again maybe that's what you want to do. I'd say good luck, hacking is a lot of work.

>All of these games would need to have their background rendering code heavily hacked. This would need to be done for each game individually, it can't be done at the emulator side.

Sooooo... it's an individual process that involves a lot of modifying and hacking. I figured as much.

>Even if you hacked game by game, there are certain things that would be hard to adapt. For example, what to about boss fights that happen in locked screens? Will there be invisible walls keeping sprites in the center of the screen or will they be able to use the extra space? What if the mechanics of the fights depend on the layout of the background?

Yup. I wouldn't know what to choose between those two options. Well, if it's like falling off a platform, for example, the space would need to be extended on each side to accompany the fixed background?

>Here is a thought. Is there any way to heuristically deduce that a sprite overflow is intentional or not? If its intentional then hide the sprites, if not, then show them. Obviously wouldn't work in all games, but is there a way that would work for many?

That would be fantastic if it were possible.

>I mean that enemies/objects tend to appear and disappear just before they enter the screen, new tiles for scrolling backgrounds can be done long before or just before the edge of the screen. (In some cases, just after, like the attribute glitching you see in SMB3.) If you were to extend the background, you still don't know where to put the sprites at the edges.

>If the game keeps track of enemies offscreen, whatever format that's in will have nothing to do with what's displayed onscreen, so there's no automatable way to pick up that information (presuming it even exists). Onscreen sprites have 8-bit values for their coordinates, there's no way to specify one that should be offscreen, so you can't get it from the PPU's sprite position data.

As I said, the only thing to do, really, is rewrite the game. Either rebuild it on some non-NES platform, or extend an NES emulator with new (fake) hardware capabilities and rewrite as much of the game as you need to do this.

Gotcha! I would love to take a go at doing this if I had the know-how to do so.

Gotcha! I would love to take a go at doing this if I had the know-how to do so.

If you wanna learn, this is not a bad starter project. There are plenty of game making tutorials out there!

Start by learning the game's map format. Figure out where the map data is in the ROM and how to decode it. If this is too daunting for you, then just fine maps online and duplicate them in a form that is useful to you. This is the first step in making your HD port. Once you have a map that you can put on the screen, you're now free to make your view as wide as you like (i.e. 16:9).

Now that you can view a level, start making the other things. Put in the main character. Give it gravity and collision with the world. Let the player move around in the game's natural way. Try to get the feel correct. If you're ambitious you can disassemble the game and try and duplicate its behaviour perfectly.

By the time you've made it that far, the rest of it should come easier. Make enemies. Add sound effects, music, level transitions, scoring, tile and ending, etc. It's a lot of work to get all the way finished, but it can be quite satisfying.

Who is online

Users browsing this forum: Google Adsense [Bot] and 6 guests

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