I still think VirtuaNES is the best NES emulator

And the last release was a little over five years ago.

The reason being is that the sprites stay solid in all the games (or at least most) compared to every other emulator I've tried.

That's cool. Nobody cares here, though, as we need real results and not blind belief.

Use NEStopia with sprite limit turned off then. (This disables the sprite overflow flag, which it should not, but whatever.)

A lot of NES emulators have this option.

I admit that I've often disabled sprite limit in whatever emulator I'm using when the flickering was getting annoying. Nostalgia has its limits

Be aware that disabling the sprite limit option will cause some "visual artefacts" in some games. If you want a list and/or want to see some examples of what happens, I can happily provide such. Otherwise yes it's a convenient option, but if you aren't sure if it'll cause issues, don't use the feature.

And some games flicker anyway.. Super Dodge Ball.

I use VirtuaNES whenever I need an emulator for playing, because it has really the nicest setup and all, and is small and quick.

I'd never use this for any testing or debugging, of course, as it is very inaccurate - still 100 times more accurate then nesticle though.

It's probably worthwhile to put together a list. I'll start. Here's a couple off the top of my head:

Castlevania II - Simon's legs are visible while standing in the marsh
Gimmick - When starting a level, the character is visible before he drops out of the "window"
Majou Densetsu II - Character isn't masked properly when going through doors

FWIW, I disable sprite limiting by default since it looks better and, for the vast majority of games, there are no consequences.

You'd want to add to your list :
- Many cutscenes in Nija Gaiden games
- The legend of Zelda when you go through top and bottom doors in dungeons

Solstice: The main character's face shown in the cutscenes contains a bunch of stray sprites for no good reason. If the sprite limit is disabled, you will see them, otherwise they are hidden by the 8-sprite limit.

Okay, NEStopia with sprite limit off seems to do the trick. Excuse the ignorance. With that, I'll use NEStopia from now on.

Is this some kind of hack or something? Because it's not enabled by default and I personally think the games are better with it on. TMNT II: The Arcade Game is one game where I need it on.

I presume real hardware flickers a lot more, which is why it isn't. I haven't actually had an actual physical NES since it was active.

>Nostalgia has its limits

Yup.

>If you want a list and/or want to see some examples of what happens, I can happily provide such.

Yes, please.

The above-mentioned are welcomed. Thanks.

Yes, it is a hack.

OAM in the PPU has room for 72 sprites: the ordinary 64 sprites plus 8 more to hold the results of a search for sprites on the next scanline. This extra area can be called "next line OAM" or "secondary OAM". Here's what the sprite unit does on each of the 341 dots of an OAM:

• 0-63: Refresh OAM 0-63 (because it's DRAM) and clear next line OAM
• 64-255: Scan through OAM and copy the first 8 sprites that are in range to next line OAM
• 256-319: Fetch pattern slivers for all sprites in next line OAM from CHR memory and load up the counters and shift registers that actually draw the sprites
• 320-340: Rest

Each pattern sliver fetch (2 bytes, 8x1 pixels) takes eight dots, though it could have been optimized to four by omitting the unused nametable fetch that occurs before each pattern sliver fetch. The real limiting factor is scanning time. It takes two dots to read the Y coordinate and determine whether a sprite is or is not "in range", that is, whether Y through Y+7 (or Y+15 depending on the size flag) stretches across the next scanline. If a sprite is in range, it takes six more dots to read the tile number, attributes, and X coordinate and copy them to next line OAM. In the theoretical worst case, where the eighth sprite is #63, the entire scan takes 2 * 64 + 6 * 8 = 176 dots, leaving 192 - 176 = 16 dots of idle time before pattern fetching. At this rate of scanning OAM, only two more in-range sprites could be fetched.

Why is it 99% of nesdev threads go off-topic by about post #4?

Edit: Spelling.

The games listed above (by multiple people) are the ones I know of, with the addition of one:

Castlevania - Simon's body is visible when walking through certain doors (such as at the entrance to the castle), rather than walking "into" (and thus "behind") the door

I can assure you 100% that there are many, many others.

Bottom line: feel free to use said feature, but if you encounter any oddities in the game with sprites, turn it back off (default). I say this based on my own experience with it (I used to rely heavily on said feature until I kept finding more and more games with "weird sprite-related problems" and eventually said f-it).

That's a sprite priority issue.

Yes, since Simon has to be maked "horizontally" when he enters the door, this trick can't be done by abusing 8-sprite per line limit.
Castlevania does it by placing high priority sprites in front of Simon, but behind the background, therefore the wall is still visible.
This technique could be called "sprite priority reversal" or something like that. Quite a few NES, SNES and GBA games uses this trick (not only Castlevania).

This technique uses only 2 sprites instead of 8 so I can only think it has advantages. I wonder why they didn't use this one in Simon's Quest instead - but then again the sequel is inferior to the original on almost every possible aspect.


Because it's full of active and passionate people. Forums who are dead and unfrequented does not go off topic, except when there is a spammer that comes post his shit that doesn't get removed because the mods don't even go there any longer.

The thread was entirely on-topic until this post. The OP directly brought up the sprite limit issue, and has since asked more questions about it which are being answered.

...sorry for continuing the off-topic discussion.

Ah you're right -- I just tested it. Chances are what I'm remembering is from the days of earlier/older emulators where the sprite priority stuff wasn't implemented (emulated) correctly. In these cases Simon always walked in front of the door. I really should just bow out and let you guys comment on things instead of opening my old, often incorrect, mouth. :-)

That's an in-depth description for a hack, tepples. Nevertheless, thanks for the insight, though I'm math retarded.

>The games listed above (by multiple people) are the ones I know of, with the addition of one:

Ah! That's okay. No doubt there are others, but I think I'll leave it on unaware of the anomalies it will cause. As long as it's few and not many.

I'll go off-topic here. I was wondering, all older games are 4:3 ratio and all modern games are 16:9, but the data to expand most older games to widescreen is available in-game. Isn't it possible to hack, say, Super Mario Bros. into a natural 16:9 game rather than stretching it? Like what modern HD ports of games are doing. They're able to naturally make the games 16:9 because the data is there, except for anything involving video. Or not, correct me if I'm wrong.

But if it's possible, how much effort would it take to do so?

Well, most NES games tend to be doing a lot of work "just off screen".

To make them 16:9 it's not like you can just display the background tiles that are sitting in VRAM currently. You'd need to reimplement the game (on a non-NES platform) and adjust everything that deals with whether the edges of the screen are. For instance, there's no way on an NES game to specify a sprite that is outside of the 4:3 screen.

The visible portion of the NTSC NES or Super NES picture is 256x224 with 8:7 pixel aspect ratio, or 256/224*8/7 = 1.31:1 display aspect ratio, close to the 4:3 of classic CRT SDTVs. I can think of two ways to get closer to the desired 1.77:1 DAR of HDTVs without compromising proportion: expand the visible area to 336x224 or crop to 256x164.

Zooming in
PocketNES, an NES emulator for Game Boy Advance, had to squeeze the screen into 240x160 pixels. It had a scaled mode that would compress 213 lines into 160, looking much like what you get when you stretch the standard NES picture to fill an HDTV. It also had an unscaled mode that would follow a location in the NES's RAM that stores the vertical coordinate of the player character and pan the entire emulated display up and down based on this position.

Ports of NES games to Game Boy use essentially the same technique, often with a rearrangement of the status bar to open more space for the action. These include Balloon Kid (GB port of Hello Kitty World for Famicom with all the Sanrio trademarks filed off) and Super Mario Bros. Deluxe. And in some cases, the status bar is made transparent and overlapping part of the playfield, as in Super Mario Advance 4 (GBA port of Super Mario Advance 3).

Zooming out
The NES background display can be set to 512x240 pixels ("horizontal arrangement" or "vertical mirroring") or 256x480 pixels ("vertical arrangement" or "horizontal mirroring"). Scrolling operates by updating the part of the background plane that's offscreen with tiles that will soon become visible.


Animation of updating in Super Mario Bros.

Games using vertical mirroring, such as Super Mario Bros. or Contra, may allow a cheap modification to support widescreen operation. Running the PPU at four pixels per CPU cycle instead of three would allow drawing an extra 40 pixels of background on each side totaling 336x224. Games that make their updates near the edge of the screen, rather than in the center of the offscreen part of the plane, will need to be modified. And as rainwarrior mentioned, sprites will pop in and out of visibility as they go through the extended background.

There is one slight inaccuracy in the animation above: Super Mario Bros. is actually well behaved in this respect, updating in the middle of the offscreen area rather than near the edge.

>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?

You're very knowledgeable with your consoles/handhelds, tepples. Expanding sounds like the better option, but that's probably an illusion.

In that case, you'd have to be desperate for portability when you're aware of that and still use PocketNES.

>Scrolling operates by updating the part of the background plane that's offscreen with tiles that will soon become visible.

Yes, that's why I was initially thinking it should be possible. The data for horizontal exists, but for some vertical and all stationary games it wouldn't be possible. Like racing games or puzzle games. Is this correct?

>And as rainwarrior mentioned, sprites will pop in and out of visibility as they go through the extended background.

Why's this? Imperfect extending?

Modifying the PPU is all it takes?

I wouldn't say that. In my game, I only update 8 pixels passed the border. And the leftmost eight pixels that ARE on the screen are hidden (because they're "wrong"), so the resolution is still only 256 pixels. Even if my game were capable of drawing more off screen horizontally (right now it has that ability vertically), you'd still only be able to extend by 8 or 16 pixels because I'd do things in roughly the same way. (If not clear, I only draw one tile past the border vertically even though I could technically do an entire screen. I would only do one tile horizontally even if I could technically do the entire screen horizontally.).

Most games do it like this. It's pretty rare to draw far enough passed the border to do what you're asking.

Even in a game that does draw more as far as background tiles, you still run into an issue with sprites.

They can't be drawn offscreen horizontally. A value of 0 for a hardware sprite's X position is pixel aligned with the left border. A value of 255 is 1 pixel on the right of the screen. You can't do more or less than that. So if the screen is longer than 256 pixels, all the space is inaccessible with the way sprites are mapped. Making a hardware sprite have two bytes for horizontal position could be done, but no existing game would make use of it. They all expect and use one byte.

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.

It's also worth noting that the PAL NES and Dendy native aspect ratio already stretches the screen to look like a letterboxed ≈3:2 DAR. (precisely 1.478613̅)

Increasing the horizontal resolution of NES games is much, much harder than getting rid of sprite flicker. Only a handful of games counted on sprites being dropped, but ALL of them counted on the screen being 256 pixels wide.

Like has been said, sprite coordinates are 8-bit, so the highest possible X coordinate of a sprite is 255. If you extend the screen past that, no sprites could ever be in the extended area, unless the emulator was modified to support 9-bit sprite coordinates, and the ROM was hacked to use this feature.

Concerning the background, even though horizontally scrolling games have data to show in the extended area, most games weren't coded to keep more than 1 screen worth of backgrounds active in the PPU. Some games didn't even have that option, because they arranged the VRAM available for backgrounds as a 256x480-pixel area (as opposed to 512x240, which is the other possible configuration), so they didn't have any extra space horizontally. Super Mario Bros. 3 is a good example of such game. 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.

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?

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?

I'd guess 8 blank sprites in a row/behind background with the same Y+X coord would work. I put all 8 sprites in my projects right on top of each other.

If there are a bunch of sprites using the same tile index and the same Y coordinate, I'd say the chances of them being used to cause an overflow are pretty high.

Gremlins 2 uses sprite overflow masking in a cutscene, and doesn't put them at the same X position, but they do use the same tile and Y coordinate.

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

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.

Well if they're in a small x coord or the same, chances are they're not a platform.

But in practice, making the IPS for this method would probably take less effort than convincing the publisher to make an official port to a new platform.

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.

I agree that a good emus should detect automatically whenever sprites are clipped (with 8 intentional higher priority sprites) or are supposed to be visible, but can't because of the limitation.

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.

I may try it, but I'm not sure if I'll have the patience for it. I should get a better idea after checking out the tutorials.