Enhancement: Difference between revisions

From NESdev Wiki
Jump to navigationJump to search
(→‎Overdraw: Clarify how expansion to 15 sprites per line would be implemented)
Line 6: Line 6:
There are two ways that this can interact with [[PPU sprite evaluation|sprite evaluation]].
There are two ways that this can interact with [[PPU sprite evaluation|sprite evaluation]].
One is to turn off the mapper side effects of sprite data fetching past the eighth sprite, which can't be realized with actual carts.
One is to turn off the mapper side effects of sprite data fetching past the eighth sprite, which can't be realized with actual carts.
The other way involves skipping seven of the dummy nametable fetches at x=272, 280, 288, ..., 312, allowing a total of 15 sprites' patterns to be fetched in one horizontal blank.
 
(The first dummy fetch is needed so that the [[MMC3]]'s scanline counter doesn't trigger four dots early.)
The other way involves rearranging the fetch sequence of the sprite unit to allow 15 sprites on a line.
This requires rearranging both in-range search and pattern fetch.
Cycles 1-64 are normally spent clearing secondary OAM.
Doubling the sprite count would make it take twice as long, but clearing only the Y coordinate would make it four times as fast, for a net result of cycles 1-30.
This would allow the actual evaluation, which takes 2 cycles per sprite and 6 more per in-range sprite, to be expanded from 176 cycles to 218 cycles.
For pattern fetch, skipping seven of the dummy nametable fetches at x=265, 273, 281, 289, 297, 305, and 313 would allow a total of 15 sprites' patterns to be fetched in one horizontal blank.
(The first dummy fetch at x=257 is needed so that the [[MMC3]]'s scanline counter doesn't trigger four dots early.)


== Control ==
== Control ==

Revision as of 17:28, 3 April 2013

Some emulators intentionally deviate from perfect accuracy in the interest of improving a game's appearance. Some of these can be realized in hardware; others cannot.

Overdraw

Some emulators have an option to ignore the 8 sprites per line limit. There are two ways that this can interact with sprite evaluation. One is to turn off the mapper side effects of sprite data fetching past the eighth sprite, which can't be realized with actual carts.

The other way involves rearranging the fetch sequence of the sprite unit to allow 15 sprites on a line. This requires rearranging both in-range search and pattern fetch. Cycles 1-64 are normally spent clearing secondary OAM. Doubling the sprite count would make it take twice as long, but clearing only the Y coordinate would make it four times as fast, for a net result of cycles 1-30. This would allow the actual evaluation, which takes 2 cycles per sprite and 6 more per in-range sprite, to be expanded from 176 cycles to 218 cycles. For pattern fetch, skipping seven of the dummy nametable fetches at x=265, 273, 281, 289, 297, 305, and 313 would allow a total of 15 sprites' patterns to be fetched in one horizontal blank. (The first dummy fetch at x=257 is needed so that the MMC3's scanline counter doesn't trigger four dots early.)

Control

An emulator designed for point-and-click games such as Videomation and Thwaite may support using a PC mouse, a touch screen, a Wii Remote, or a Kinect sensor to move a game object. This can take one of three forms:

  • The emulator can directly manipulate coordinates in RAM, as if a Pro Action Replay had a controller plugged into it.
  • The emulator can patch the game to read absolute coordinates from mapper ports or from the Arkanoid controller (if only one dimension is needed), Oeka Kids tablet, or Power Glove.
  • The emulator can patch the game to read mickeys (coordinate differences over time) from mapper ports or from the Super NES Mouse.

Resolution

The cheap way to upgrade a game's graphics from the NES's native 240p to something bigger is to apply pixel art resampling algorithms such as Super 2xSaI, Scale2x, or hq2x. A more powerful way involves creating a large graphic for each small graphic used by the game, as seen in some high-resolution texture packs for Nintendo 64 emulators. For CHR ROM games, this could be a CHR ROM with more pixels and more bit depth than the game's existing CHR ROM. Rendering would use the bigger one, while $2007 readback would still use the smaller one. Many CHR RAM games could use a hash table from 16-byte original tiles to larger tiles, though this would fail in games relying heavily on dynamic drawing to CHR RAM (e.g. Hatris, Qix, Videomation, and the second level of Battletoads).

Sound

Pop reduction

Some games make harsh popping noises when they begin to play sampled sound on APU DMC. This is caused by a write to $4011 to set the center line of the sample. A few emulators support "pop reduction", which ignores all writes to $4011, but this fails when games intentionally cause pops by using timed writes to $4011, such as Big Bird's Hide and Speak, Joshua, and even a few games that use $4011 pops as a crude kick drum.

One way to accommodate both of these cases without using CRC to detect game-specific settings involves a sixth audio channel and a heuristic to distinguish sample start pops from intentional changes. If $4011 is written, and it is a sample start pop, take the difference (new $4011 value - old $4011 value) and subtract that from the sixth channel. This way, the pop is exactly canceled out by the sixth channel, which decays exponentially over the course of a few frames. An emulator might guess that a $4011 write is a sample start pop if either it occurred near the same time as a sample start or $4011 hasn't been written in the past few frames.

Recorded music playback through the mapper

The Japanese version of Bases Loaded uses the JF-13 board, which has a sampled audio playback chip. Write a value, and a sound begins to play through the mapper sound channel of the authentic Famicom console. Likewise, the TurboGrafx-16 and Sega Genesis consoles supported CD peripherals allowing playback of Red Book audio during game play. Emulators could support adding a virtual chip that plays higher quality sound. Each such game would come with .mp3 or .ogg files and a cue sheet to tell what sounds to play when what values are written. Games could be patched to allow the use of, say, OCRemix versions of songs.