NES Emulation without flickering?

zweitplatzierungsboy

Hey guys, I've been wondering if there's a NES Emualtor for the Mac, that doesn't have flickering sprites?
I'm aware that this is in the interest of accurately emulating the original hardware, but is there a way to avoid this?

I ask because when I screen-capture gameplay footage with Nestopia, instead of flickering the video simply doesn't show the graphics at all. In case of Mega Man 2's Metal Man stage, at the beginning you sometimes don't see Mega Man or the falling spike things on screen.

I've looked through the hardware preferences of Nestopia but couldn't find anything. At first I thought that "Enable Unlimited Sprites" would get rid of this, but it doesn't. Anyone who can explain what that option does?

Richard Bannister

Enable unlimited sprites is supposed to do that. I'll have to check the code again...

seanstar

Well, the thing to understand about the NES is that its graphics system is not just like OpenGL or Photoshop or anything where you can just overlay any old number of images on top of a background bound only by memory and CPU power. There are actually 64 hardware sprites on the NES, either 8x8 or 8x16 pixel blocks of graphic, depending on the mode you set, which can be placed/moved anywhere on the backround and will be drawn correctly 1-bit-masked (by palette color) onto the background assuming that during the scan of a given raster line you haven't hit the end of the 8-deep hardwired check-for-present-sprites logic (8 sprite per scanline limit). It is logically impossible for the NES to show more than 64 "sprites" at once, far fewer if you consider that very few of what are classically termed 'sprites' consist of only one hardware sprite. And because NES is entirely tile-driven, it is next to impossible for anything that isn't a sprite to move independently over a background (this would require direct writing to the tile bank every frame).
So I'm not entirely sure what the "unlimited sprites" option does in emulators that have it, save that there is no logical connection to anything that the hardware should ever be able to be even told to do. My guess is that it works around the per-scanline sprite limit by continuing evaluation as if the graphics chip had all the time in the world to locate and potentially overlap sprite pixels and was consequently built with a 64-deep evaluation. There's an ~off~ chance that the option might also hack the Direct-Memory-Access mode of sprite data updating (on the NES you can either write directly to the position/color/tile data of each sprite individually, or you can format it all in your own block of memory and make a single call to directly copy that whole array to all the sprites at once) to keep shoveling data past where the hardware would normally run out of sprites and allocate more virtual sprites for anything that "looks like" sprite data, which might allow more sprites on game that manage their own list of on-screen objects and dynamically allocate hardware sprites to objects each frame (the reason, I surmise, some games like the ones you mention can clearly have more objects than the NES has sprites for, and usually compensate by continually rotating through which objects don't get drawn), but that's a real stretch.

zweitplatzierungsboy

big thank you to both of you.

i knew about the 8x8 and 8x16pixel blocks and that the nes hardware has a limit on how much sprites it can put on screen at the same time, but certainly didn't know how emulator writers get around that limit or the more technical aspects you have mentioned.

you really learn something new every day :)

i asked because i know of people who record nes footage without the flickering through emulatos (lordkat, who makes the until-we-win videos for example), but i'm not sure which emulator he's using (but definitely a windows program).

Richard Bannister

My guess is that it works around the per-scanline sprite limit by continuing evaluation as if the graphics chip had all the time in the world to locate and potentially overlap sprite pixels and was consequently built with a 64-deep evaluation.

That's exactly what it does. The function is hooked up correctly on the Mac side and is passed to the Nestopia core, so it certainly should be working. (I have previously put out releases with preference items that didn't work, but not in this case). I can't really advise beyond that.

Pixelcade

There's gotta be a little flickering! A little color shift. These were all things you would have experienced using the NES on a tv from the time or an earlier TV. I find it adds to the charm of that generation. I don't know how many times I'd be fighting a boss and I'd get a flicker or v-scroll on the tv and loose health then die. Frustrating at the time but I look back and that's how it was. :laugh:

seanstar

Pixelcade wrote:

There's gotta be a little flickering! A little color shift. These were all things you would have experienced using the NES on a tv from the time or an earlier TV. I find it adds to the charm of that generation. I don't know how many times I'd be fighting a boss and I'd get a flicker or v-scroll on the tv and loose health then die. Frustrating at the time but I look back and that's how it was. :laugh:

And then there are games like Recca... So... many... sprites...