It is currently Sat Jul 21, 2018 3:16 am

 All times are UTC - 7 hours

 Page 2 of 2 [ 21 posts ] Go to page Previous  1, 2
 Print view Previous topic | Next topic
Author Message
 Post subject: Posted: Wed Nov 30, 2005 10:25 pm

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20280
Location: NE Indiana, USA (NTSC)
Lloyd Gordon wrote:
How come I've never seen this on commercial games?

Because you were probably a lot younger when you played them.

Top

 Post subject: Posted: Thu Dec 01, 2005 12:03 pm

Joined: Mon Nov 07, 2005 11:32 am
Posts: 150
Location: Toronto
I was thinking about fractional movements and I realized my code is already moving the sprites at 1 pixel distance per 2 frames or an average of 0.5 pixels per frame. This is already fractional movement. I must be missing something. Are there certain fractions that should be avoided such as 0.5, 1.5, 2.5 etc? Are other fractions, such as 1/3, 2/3, 4/3, or 1/5, 2/5, 3/5, 4/5, 6/5 etc. better? Is it the NES PPU that creates the problems or is it the NTSC TV receiver? Does anyone know of any games that have any similar effects? Thanks.

Top

 Post subject: Posted: Thu Dec 01, 2005 6:03 pm

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20280
Location: NE Indiana, USA (NTSC)
Lloyd Gordon wrote:
I was thinking about fractional movements and I realized my code is already moving the sprites at 1 pixel distance per 2 frames or an average of 0.5 pixels per frame. This is already fractional movement. I must be missing something. Are there certain fractions that should be avoided such as 0.5, 1.5, 2.5 etc? Are other fractions, such as 1/3, 2/3, 4/3, or 1/5, 2/5, 3/5, 4/5, 6/5 etc. better?

The point is to have fixed-point displacement and velocity on all objects so that they will spend a lot of their time at speeds that have no obvious fractional relationship to the color burst.

Quote:
Is it the NES PPU that creates the problems or is it the NTSC TV receiver?

It's the NES PPU's attempt at outputting a signal that an NTSC TV understands. In theory it would have been better to output the chroma and luma on separate pins so that they could be filtered to the precise NTSC specification, but Nintendo took shortcuts to save costs back in 1984 when the proper analog filters to perform NTSC color encoding were much more expensive than they are now.

Top

 Post subject: Posted: Thu Jan 05, 2006 11:08 am

Joined: Mon Nov 07, 2005 11:32 am
Posts: 150
Location: Toronto
I tried varying the speed of my sprites and the weird patterns still persist. It certainly seems like dot crawl. I changed the speed from 1 pixel per 2 frames to 4 pixels per 10 frames (I only moved the sprite 1 pixel when the frame counter was 0, 3, 5 or 8 modulo 10) and it still had horrible weird flickering, like before. I noticed that it was mainly when a sprite had certain combinations of colours and when the sprite was moving right or down (the direction of the scan?). I avoided colours that had the same upper nibble and different lower nibbles in the same sprite and it actually made it worse. Should I have used colours that have the same upper nibble instead? (I may have misunderstood an earlier post.) It looks to me like certain colours within the sprite somehow interact with other colours within the same sprite when it is moving in a certain direction. I have no idea why my code is so bad in this respect.

Top

 Post subject: Posted: Thu Jan 05, 2006 12:18 pm

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20280
Location: NE Indiana, USA (NTSC)
Write an NES program that lets you change the speed and color of the sprite using the controller. Then you will quickly learn what combinations work.

Top

 Post subject: Dot crawl test NESROMPosted: Wed Feb 22, 2006 8:54 am

Joined: Mon Nov 07, 2005 11:32 am
Posts: 150
Location: Toronto
After much fiddling around I finished a nesrom that tests palette combinations and speeds so you can see on your TV how they look. It allows you to pick any two palette choices \$00-\$3F. These two colours are combined in two sets of four checkerboards coarse to fine which move back and forth either vertically or horizontally. The speed is variable in increments of 1/256 pixels per frame from \$00-\$FF. You can multiply the speed by 0 (stop) to 5 to see faster movement.
I was surprised to see some of the effects:
-the finest checkerboard pattern always had weird diagonal lines
-colours really bleed over to the next colour on the same scan line
-it's futile to try really fine pixel by pixel transitions as they just smear
-the movement artifact wasn't too bad and the actual speed didn't matter much, although you could adjust the "beat" to minimize it
If you want to try it, look for Test.nes at:
http://www3.sympatico.ca/lloyd.gordon3/my_nes_stuff.htm

Top

 Display posts from previous: All posts1 day7 days2 weeks1 month3 months6 months1 year Sort by AuthorPost timeSubject AscendingDescending
 Page 2 of 2 [ 21 posts ] Go to page Previous  1, 2

 All times are UTC - 7 hours