I'm not really interested in HD graphics, but to be able to play NES games with their original graphics and no flicker would be quite revolutionary.

Not that revolutionary. Nestopia, for example, has had this feature for ages: Machine => Options => No Sprite Limit. Nestopia's implementation is slightly questionable, though, because the setting also affects the sprite overflow flag which could cause some games to break.

I think FCEUX has a "disable 8 sprites limit" switch, which eliminates flicker due to overdraw limit. It might be one of the things that old vs. new PPU changes. It won't eliminate intentional flicker where a sprite isn't drawn at all in one or more frames, like injured Mario in SMB1 or the smoke and explosions in Thwaite; for that, you need a motion blur filter as seen in GBA emulators.

I'm not really interested in HD graphics, but to be able to play NES games with their original graphics and no flicker would be quite revolutionary.

Not that revolutionary. Nestopia, for example, has had this feature for ages: Machine => Options => No Sprite Limit. Nestopia's implementation is slightly questionable, though, because the setting also affects the sprite overflow flag which could cause some games to break.

I know some emulators have this option, but... maybe I'm being silly, but does it actually work?

I'm talking, off the top of my head, about games like Konami World 2, Super Dodge Ball (https://www.youtube.com/watch?v=ARmZjy2HF_4) and Guerilla War/Guevara, which are flickerfests I never could solve. Also, there is this effect with the tiles in the background, in which they blink distractingly when scrolling into the screen (You can see it here, right side of the screen: http://youtu.be/8BOv7GuhdB0 . Also, notice the UI permanently glitching on the lower left corner.)

Anyway, if HDNes could have a mode like I described and it brought any gains in the sense of more stability to the graphics, that would be awesome.

The effect at the right side of SMB3 is a consequence of the fact that the NES has enough video memory for two screens. Because SMB3 levels are two screens tall, it stacks the two screens on top of each other. This means a 16-pixel-wide color area straddles the scrolling seam between the left and right sides of the screen. And often this color area will end up discolored because making it correct for one side will make it incorrect for the other side.

Super Dodgeball looks like it flickers because there are too many sprites to display in a frame, and then it also might flickers due to the sprite scanline limit. Eliminating the scanline limit would reduce flicker only slightly. You'd need a specific emulator hack/feature on a per game basis that would allow the game to draw and display all characters every frame. It could be done.

I'm not sure if Guerrilla War is the same deal but it's likely.

The SMB3 glitches, the palette issues could be hidden by not drawing that edge of the screen. Some emulators allow this by an option menu. The glitch in the bottom status bar is related to IRQ and PPU timing. This can be fixed in emulation by changing the way the PPU behaves.

The flickering glitch can't be corrected by graphics pack function. This is because the function replaces graphics, so it only works on objects which are visible in the original. On the other hand, the palette glitch can be corrected by defining a default replacement for the tile regardless of the actual palette being used.

Super Dodgeball looks like it flickers because there are too many sprites to display in a frame, and then it also might flickers due to the sprite scanline limit. Eliminating the scanline limit would reduce flicker only slightly. You'd need a specific emulator hack/feature on a per game basis that would allow the game to draw and display all characters every frame. It could be done.

I'm not sure if Guerrilla War is the same deal but it's likely.

The SMB3 glitches, the palette issues could be hidden by not drawing that edge of the screen. Some emulators allow this by an option menu. The glitch in the bottom status bar is related to IRQ and PPU timing. This can be fixed in emulation by changing the way the PPU behaves.

That's why I gave that suggestion. I understand that HDNes, by overlaying the original rendering system with new graphics, also bypasses all these glitches.

If there was a mode in which the original graphics were automatically rendered in this new system, as if they were a graphics pack, like the one created for Super Mario Bros... see what I mean?

The flickering glitch can't be corrected by graphics pack function. This is because the function replaces graphics, so it only works on objects which are visible in the original. On the other hand, the palette glitch can be corrected by defining a default replacement for the tile regardless of the actual palette being used.

Wait... you mean that Super Dodge Ball with an HD graphics pack would glitch in the same way?

Edit: Let's be clear. If I create from scratch an HD graphics pack for a game like Super Dodge Ball, would these new graphics also glitch?

If not, wouldn't it be possible to create a function in the emu that extracts the original graphics, the tiles and such, organizes and allocate them on the fly in RAM, and displays them as if they were a graphics pack, to bypass these glitches?

It would have the same flickering because the game exceeds the amount of sprites that can exist on the screen at one time. You can place 64 sprites anywhere on the screen you want each frame. When a game has too many objects to drawn than will fit into this list, some don't get drawn. So it will cycle through these objects to draw them in a way where they all get a turn to be seen.

This means the game needs to have its programming changed so that when it goes to draw objects (building the Sprite RAM table) that it builds an even bigger table to send to the emulator's modified PPU which can draw all the objects. That's the basic idea.

The flickering isn't a "glitch". The flicker is the result of the hardware limitation of the NES PPU. It could be improved in emulation with per-game attention.

Oh, I get it now. I thought a rendering system that made the HD packs possible would be some sort of overlay that necessarily had the side effect of eliminating the glitches, but I was obviously wrong.

Just saw this video, and at 00:00:16, when Link gets close to the enemy and attacks, the sprite flickers.

Oh, I get it now. I thought a rendering system that made the HD packs possible would be some sort of overlay that necessarily had the side effect of eliminating the glitches, but I was obviously wrong.

Just saw this video, and at 00:00:16, when Link gets close to the enemy and attacks, the sprite flickers.

And I'm very surprised that he actually works out how to replace sound tracks. It requires in depth knowledge of the games.

Replacing music is the same skill set as ripping NSFs. In fact, if you have an NSF, you already know how where to look in the code to remove the game's own music player and replace it with writes to the "play track" register.

Replacing music is the same skill set as ripping NSFs. In fact, if you have an NSF, you already know how where to look in the code to remove the game's own music player and replace it with writes to the "play track" register.

Who is online

Users browsing this forum: No registered users and 2 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