It is currently Tue Dec 18, 2018 5:02 pm

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 15 posts ] 
Author Message
PostPosted: Tue Nov 20, 2018 12:52 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2779
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.


Top
 Profile  
 
PostPosted: Tue Nov 20, 2018 12:58 pm 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 428
Location: FL
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.


Top
 Profile  
 
PostPosted: Tue Nov 20, 2018 1:05 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20898
Location: NE Indiana, USA (NTSC)
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 this post, 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.


Top
 Profile  
 
PostPosted: Tue Nov 20, 2018 1:08 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3732
Location: A world gone mad
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.


Top
 Profile  
 
PostPosted: Tue Nov 20, 2018 3:46 pm 
Offline
User avatar

Joined: Sat Aug 20, 2016 3:58 am
Posts: 77
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


Top
 Profile  
 
PostPosted: Tue Nov 20, 2018 4:56 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2779
I think they made it slow to avoid interlacing artifacts.


Top
 Profile  
 
PostPosted: Tue Nov 20, 2018 6:02 pm 
Offline
User avatar

Joined: Sat Aug 20, 2016 3:58 am
Posts: 77
psycopathicteen wrote:
I think they made it slow to avoid interlacing artifacts.


What kind of artifacts can occasionate that interlacing?.


Top
 Profile  
 
PostPosted: Tue Nov 20, 2018 6:22 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20898
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Wed Nov 21, 2018 3:34 am 
Offline
User avatar

Joined: Sat Aug 20, 2016 3:58 am
Posts: 77
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:

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?.


Top
 Profile  
 
PostPosted: Wed Nov 21, 2018 9:03 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 734
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.


Top
 Profile  
 
PostPosted: Wed Nov 21, 2018 11:17 am 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2779
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?


Top
 Profile  
 
PostPosted: Wed Nov 21, 2018 11:49 am 
Offline

Joined: Sun Mar 27, 2016 7:56 pm
Posts: 183
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.


Top
 Profile  
 
PostPosted: Wed Nov 21, 2018 11:53 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7845
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Wed Nov 21, 2018 11:57 am 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 998
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.


Top
 Profile  
 
PostPosted: Wed Nov 21, 2018 12:12 pm 
Offline

Joined: Sun Mar 27, 2016 7:56 pm
Posts: 183
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 15 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group