Is this normal? [8 sprites related]

Zepper · Post by **Zepper** » Thu Dec 22, 2011 5:28 pm

A guy has posted a few screenshots of RockNES in action. He noticed that some sprite tiles aren't being displayed. My answer is about the 8 sprites limitation. Well, could someone look the pics and tell me if this is normal? In short words, the missing sprites are related with the 8 sprites limitation.

http://rocknes.phpbbnow.com/viewtopic.php?t=285

Shiru · Post by **Shiru** » Thu Dec 22, 2011 5:33 pm

It is result of the 8 sprites per scanline limitation. It is normal.

MottZilla · Post by **MottZilla** » Thu Dec 22, 2011 6:14 pm

In Mega Man 2 at that point it flickers like crazy. Slowdown too if I recall correctly.

tokumaru · Post by **tokumaru** » Thu Dec 22, 2011 6:27 pm

You can tell him that flickering and slowdowns can be (and have been) circumvented in emulators, but there are downsides.

Many emulators offer the option to not drop sprites when more than 8 of them are in a row, but the problem is that some games actually rely on sprites being dropped, and in these games, some masking effects will be lost (for example, Felix will be in front of bags when entering them, instead of being properly masked).

As for slowdowns, it's also easy for an emulator to overclock the CPU, but that will break games that rely on timed code. This could affect status bars and other raster effects. Here's an example of a possible glitch (since the CPU is running faster, the code that "waits" for the status bar to finish in order to split the screen finishes too early).

MottZilla · Post by **MottZilla** » Thu Dec 22, 2011 6:36 pm

I think tepples suggested copying the Dendy's idea of adding more dead scanlines before VBlank as a way of helping with slowdown without resorting to overclocking. But to prevent pitch and audio problems you'd want to disable APU updates during this free cpu catch up time.

tokumaru · Post by **tokumaru** » Thu Dec 22, 2011 6:41 pm

Oh yeah, I forgot about that method. That should cause way less glitches than the other way.

Shiru · Post by **Shiru** » Thu Dec 22, 2011 6:44 pm

I recall there were some major problem with Super Spy Hunter (I think) when 8 sprites limit is disabled in an emulator. Something that affected to the gameplay - not allowed to shot when too many objects are on screen or something like that.

I once made an 'overclocked' build of NNNesterJ by someone's request. As I recall, I simply changed t-states table to make all the opcodes 1 cycle long, instead of actually overclocking the CPU with all the pitch etc related things. That removed slowdowns in Contra Force, but of course introduces bugs in some games.

Post by **tepples** » Thu Dec 22, 2011 6:46 pm

If you OC using a Dendy-style duplication of the post-render line, you'll want to disable OCing for the first couple seconds after power-on so that NTSC/PAL detection routines like those in Thwaite and some Codemasters games use a correct game speed and don't conclude "this is a Dendy; let's speed up the movement and music tempo". You may want to let the user specify after which line the cycles are to be inserted for a particular game, in case games time things based on a status bar scroll split at the bottom. You'll also want to disable OCing if the game has written to $4011 several times in the past frame, so that Caroll Spinney's voice in Big Bird's Hide and Speak doesn't screw up.

MottZilla · Post by **MottZilla** » Thu Dec 22, 2011 7:30 pm

You could always have as options different OverClocking Methods for the user to enable with descriptions for what games to use and not use them with. Ofcourse in the end the user can just quickly do trial and error.

3gengames · Post by **3gengames** » Thu Dec 22, 2011 7:59 pm

You could just have it run the frame normal, but then give the CPU more time at the END of the frame since I thought most games spun on the NMI as a NMI_Wait subroutine of some sort, I know I do all the time.

MottZilla · Post by **MottZilla** » Thu Dec 22, 2011 8:27 pm

That what is suggested, it's what the Dendy does I think. As tepples said, if the game doesn't turn off the display early somehow then this will work fine. You can eliminate all slowdown this way since you can have an unlimited amount of CPU time in emulation.

miker00lz · Post by **miker00lz** » Thu Dec 22, 2011 8:59 pm

i can say for sure the megaman 2 screenshot is totally normal. it happens on my real NES when i play and it happens in my emu.

Zepper · Post by **Zepper** » Fri Dec 23, 2011 5:57 am

The Playstation version, Complete Works, has no flickering or slowdowns. It's quite amazing.

Thanks for the feedback.

tokumaru · Post by **tokumaru** » Fri Dec 23, 2011 9:11 am

Zepper wrote:The Playstation version, Complete Works, has no flickering or slowdowns. It's quite amazing. Thanks for the feedback.

Maybe those were reprogrammed instead of being emulated.

MottZilla · Post by **MottZilla** » Fri Dec 23, 2011 3:47 pm

Someone said the Program ROM data exists on the disc. It may indeed be emulation and it seems likely given that the source was possibly lost and also some of the "enhancements" are things you could still do while still using emulation. The only way to really know is to replace the data on the disc and try to run it with some other game.