nesdev.org

I think it comes from people making older hacks/homebrews on slow emulators and misinterpreting it as a hardware limitation. Same thing with the myth that 32x32 sprites inherently take 4x the CPU power as 16x16 sprites, or that updating an entire tile map to animate a boss is inherently faster than moving a couple 32x32 sprites together to make a larger sprite.

Were any of these myths ever particularly prevalent? Seems a bit random to make a thread just to debunk something I don't think I've ever heard anyone claim a single time.

If anything: Decompressing tile data for a 32x32 pixel sprite takes more CPU power than for a 16x16 pixel sprite. Similarly, copying the decompressed tile data to VRAM takes four times as much vblank time.

@Revenant I think the myth might be related to posts like this

In [url=https://forums.nesdev.com/viewtopic.php?p=196086#p196086]this post[/url], Bitbeam wrote:Standard game resolution: Most games were 256x224. Higher resolutions up to 512x448 were possible but since higher resolutions caused slowdown, flicker, and/or had increased limitations on layers and colors (due to memory bandwidth constraints)

Hires and interlace mode require more pixels, which incurs slowdown when loading these pixels into VRAM. Hires and 8-bit modes have fewer layers, which may cause an engine to have to fall back to software compositing (like Bust-A-Move and Zoop, which use 8-bit), which incurs slowdown. Interlace has flicker if the even and odd scanlines in an area noticeably differ in luminance, as the S-PPU has no GameCube-style blending of adjacent scanlines.

I don't know who's making such claims **recently**, but:

In the late 90s, the claim of hires/interlaced modes taking more time was made because emulators at the time generally did not have good support for it. There were emulator-level "kludges" put in place to allow them to run, but the performance took a pretty big hit. Nobody would know this unless they were part of that whole scene at the time.

TMK, all of that has been redone/reworked, as all the major SNES emulators (I can think of 3) used today perform well with hires/interlaced modes. Things have improved since the late 90s in that regard.

tepples wrote:Hires and interlace mode require more pixels, which incurs slowdown when loading these pixels into VRAM. Hires and 8-bit modes have fewer layers, which may cause an engine to have to fall back to software compositing (like Bust-A-Move and Zoop, which use 8-bit), which incurs slowdown. Interlace has flicker if the even and odd scanlines in an area noticeably differ in luminance, as the S-PPU has no GameCube-style blending of adjacent scanlines.

R.P.M racing has 512x448, and is slow, but i always thought that it was by the same reason that the backgrounds were really simple (many reated tiles needlessly), that is to say, that the game was even near an experiment.

But reading to you, really that is the speed that we could to expect with games of that resolution?.

256x224:
https://youtu.be/kDVCDswQuWE?t=160

I think they made it slow to avoid interlacing artifacts.

psycopathicteen wrote:I think they made it slow to avoid interlacing artifacts.

What kind of artifacts can occasionate that interlacing?.

If an interlaced picture is scrolled vertically by a scanline per field (60 fps), then only the even scanlines or the odd scanlines of the picture will ever be visible. When SDTV was common, it was usual for viewers of basketball matches to see this sort of jagged artifact on the 3-point arc and the edges of the free throw lane when the camera panned up and down over one side. Sticking to 30 fps or lower avoids this, as does always changing the scroll position by a multiple of two scanlines.

tepples wrote:If an interlaced picture is scrolled vertically by a scanline per field (60 fps), then only the even scanlines or the odd scanlines of the picture will ever be visible. When SDTV was common, it was usual for viewers of basketball matches to see this sort of jagged artifact on the 3-point arc and the edges of the free throw lane when the camera panned up and down over one side. Sticking to 30 fps or lower avoids this, as does always changing the scroll position by a multiple of two scanlines.

I've found this image:



So, if the game were faster, this effect would be more noticeable, right?.

But technically a game using 512x448 could as faster as any other game of the console at 256x224... and then, at 512x224 should not be any problem with artifacts, is this correct?.

Señor Ventura wrote:So, if the game were faster, this effect would be more noticeable, right?.

That is a still image with 0Hz refresh rate. If it were faster than 0Hz, then you won't see the effect (*).

(*) and that's the problem, if you want to see such striped lines, then you can run into troubles when using interlace with moving/scrolling striped tiles.

You'd be able to see it, just not as much as in motion, or on a CRT screen.

In hires interlace mode, are the tiles 16x8 by default or always 16x16?

psycopathicteen wrote:You'd be able to see it, just not as much as in motion, or on a CRT screen.

In hires interlace mode, are the tiles 16x8 by default or always 16x16?

Interlaced mode doesn't automatically produce a vertical high-resolution effect by itself; simply turning it on without doing anything else would just make the screen flicker a bit more, and produce artifacts when things move.

To achieve a vertical high-resolution effect, you have to alternate between two images each field (60 Hz frame), one consisting of the even scanlines and one consisting of the odd scanlines. In other words, you'd probably have two 16x8 tilesets you switch between each field, so that the two fields merged appear as a 16x16 tileset.

Interlaced video on a CRT never shows deinterlacing artifacts, as your still insinuates.

A while ago, tepples made several animated GIFs that reasonably accurately show what 480i actually looks like on a CRT: 1, 2, 3

The only relevant failure mode of interlaced video is what tepples just pointed out: motion of a single 480i scanline (or half a 240p scanline) can work out to be judder-y.

Nicole wrote:To achieve a vertical high-resolution effect, you have to alternate between two images each field (60 Hz frame), one consisting of the even scanlines and one consisting of the odd scanlines. In other words, you'd probably have two 16x8 tilesets you switch between each field, so that the two fields merged appear as a 16x16 tileset.

Pretty sure Modes 5 and 6 do that automatically. I know sprites do, if you set the sprite interlace bit. Basically you just use higher-resolution graphics, and the PPU selects which scanlines to display for each field.

If you want interlace in any other BG mode, you do have to handle it manually. Same with pseudo-hires; if you're trying to get half-dot resolution outside of Mode 5 or 6, you have to set up the main and sub screens with alternating pixels.

93143 wrote:Pretty sure Modes 5 and 6 do that automatically. I know sprites do, if you set the sprite interlace bit. Basically you just use higher-resolution graphics, and the PPU selects which scanlines to display for each field.

If you want interlace in any other Mode, you do have to handle it manually. Same with pseudo-hires; if you're trying to get half-dot resolution outside of Mode 5 or 6, you have to set up the main and sub screens with alternating pixels.

Ah, yeah, you seem to be right about that. I said that because I had to do it manually myself, but now that I think about it I was using mode 0 (since I needed 8x8 tiles for what I was doing).

Mode 5 and 6 do handle the vertical resolution automatically, and it looks like tile size still works the same (either 16x8 or 16x16 depending on how $2105 is set), though naturally they're now displayed half as tall as without interlacing.