nesdev.org

Remembered an old trick, thought to share. Not very practical, although being tested for other platform(s) - just to give another view.

As emulators are free of any random, every game with the same exact input will always work the same - that's a fact that made TAS possible. But this also could be abused to increase graphics resolution and or color in a way that is a bit different for usually proposed to accomplish this - external resources that replace internal ones on-fly.

Like, we have four copies of emulator with the same game loaded, all emulators get the same input. But copies of the game could have different CHR ROM content, either allowing to get twice larger resolution (one copy - top left pixel of quad, another - top right, etc), or color depth (one copy has two bits, another next two bits, 8 bits total). Some glue logic is required to compose final picture out of raster buffers provided by the emulators. To avoid palette management the idea of the color flicker could be used, just mixed and displayed as static picture without actual flicker.

Clever; you just mod each copy of the game's graphics, then just assemble the output of the four emulator instances. Very clean approach. It could be completely automated so that a graphics editor gives you 4x the resolution, double the depth, etc. for CHR editing, and splits it up, then lets you play as if it were normal. This would work with music, allowing more channels. This stands out because it can use basically standard emulator modules and games with no code mods or ANY effect on how the game plays.

Sprite 0 begs to differ.

I believe SMB3 wouldn't like also.

Dwedit wrote:Sprite 0 begs to differ.

If you're using sprite 0 for timing then you probably took care of the transparent pixels issue already.

Zepper wrote:I believe SMB3 wouldn't like also.

I'd imagine all the instances are the same emulator, so timing should be the same for them all. Then again, why would you run SMB3 on this? Nowhere he said about playing existing games (which would need to be hacked anyway), this seems to make more sense for homebrew.

That said... doesn't this kind of defeat the point of making a game within the NES limitations, anyway? (besides if the emulator in question is accurate it's going to eat up CPU time really quickly)

Sik wrote:If you're using sprite 0 for timing then you probably took care of the transparent pixels issue already.

The problem is that a pixel might be transparent on one PPU but not on other PPUs, causing the emulators to desync. Perhaps you could allow only one of the parallel PPUs to have its status read.

Sik wrote:That said... doesn't this kind of defeat the point of making a game within the NES limitations, anyway?

Unless you're trying to make one game and publish a version for NES and a version for PC, Android tablets, Ouya consoles, and other more capable platforms. Having the game logic emulated ensures that the game logic will execute identically on all platforms.

I thought this actually was for existing games too. As for sprite hit, the split for 4x resolution could be interleaved, instead of each quadrant. The editor could have a constraint that ensured that the top pixels of each column and the left pixels of each row had the same number of transparent ones before the first non-transparent one. This would basically force you to keep those an even number of pixels from the edge of the sprite. Or more reliably, it could ensure that the "mask" of any sprites you designate matches for all four, which would force you to keep have each block of four pixels either all transparent or all non-transparent.

The best idea to accomplish this, that I've heard, was just to simply increase the resolution of the tiles themselves. For emulation purposes, the game would use the graphics data as stored in the rom, but the emulator would load a seperate CHR file which contains the tiles at a higher resolution, which would be displayed instead of the rom's content.

The external tiles could be 1:1 with the tiles in the rom, but if a game uses chr-ram, we agreed that a different approach (such as hashing) needs to be used. Basically, "if the tile looks like [this], use [this] graphic".

Increasing the color resolution would be a pretty hairy ordeal too, but an approach similar to the one for chr-ram can be used. At the very least, you can provide some "automatic" colors which are just colors generated from blending the existing 4 colors together. (For sprites, colors blended with the transparent color can just be semitransparent)

The biggest pro to this is that you only need to emulate the game once to do all of this.

tepples wrote:

Sik wrote:If you're using sprite 0 for timing then you probably took care of the transparent pixels issue already.

The problem is that a pixel might be transparent on one PPU but not on other PPUs, causing the emulators to desync. Perhaps you could allow only one of the parallel PPUs to have its status read.

My point was that if you're relying on sprite 0 then you probably made sure the silhouette of the sprite is exactly the same in all emulators =P (which would mean all emulated PPUs trigger the flag at the same time if they do)

This idea is not for homebrews, as it indeed would defeat any point to make them. It was attempted to be used to add more color in existing games for ZX Spectrum, worked more or less. Sure not the best idea, just an alternative to see, that may help to generate better original ideas.

I don't think sprite 0 hit is a huge problem, maybe because I didn't see internals of existing games too much. Pesonally I always used a special tile for sprite 0 that is not used anywhere else, so if it left unchanged, no problems introduced.

Games that use CHR RAM that use compresion are certainly a problem, as different graphics data would take different time to decompress, causing desyncs - so something is need to work around these cases.

Shiru wrote:It was attempted to be used to add more color in existing games for ZX Spectrum

I thought the biggest way to add color to a Speccy game was to port it to the MSX or SMS.

Shiru wrote:This idea is not for homebrews, as it indeed would defeat any point to make them. It was attempted to be used to add more color in existing games for ZX Spectrum, worked more or less. Sure not the best idea, just an alternative to see, that may help to generate better original ideas.

Yes, this was really outside the box for me. At first it seemed convoluted, but its elegance comes from how it uses existing building blocks with basically no modification, only working with their products in a novel way. The essence of the idea is planted well in mind at least as a valuable novel approach.

This is a really neat idea I think I might try this!

btw, sprite 0 hit is not a big deal. You have 2 CHR rom's in memory. The one you use for emulation, and the other you use for rendering. Fin.

I suppose you could do similar things for DMC and such. Playing re-mastered higher frequency audio when a particular sequence is detected as about to be played.