I finally thought our game was ready for the NES console so I burned the EPROM chips and put it in the NES. Much to my surprise it actually worked. There are some weird effects which you couldn't see on either FCEUD or Nintendulator. First of all, some background tiles seemed to be missing some colours on the lateral screen edges. Also the sprites were definitely different on the console as opposed to the emulator. Some sprites lacked good contrast so certain features such as the faces were very blurred. I think that certain palette combinations just don't show up well. Also when the sprites were moving there was a weird shimmering effect almost like a moire pattern. Not all the sprites had it which made me wonder if it is my sprite cycling routine to avoid flicker when there are more than 8 sprites per scanline. I also put #$FF into all sprite RAM that isn't being used so that any unused sprites will be in the #$FF line which is invisible. (I reverse the sprite ram every second frame.) I wonder if somehow I'm putting "garbage" into the sprite RAM which is there just long enough to make the weird shimmering. If anybody has any ideas why it only shows on the console let me know. At least the game worked pretty well.
It's certainly possible that it's a problem with your NES or your television set, or just a bad video connection. Are you using a front loader, top loader, or Famiclone?
Or it could be that you chose colors that just won't show up right on NTSC. The NES PPU's color encoder doesn't like colors of the same value (upper digit) but different hues (lower digit $1 through $C) next to each other on the same scanline. You'll get shimmering and muddiness if a lot of your scene uses colors this way. Could you post a screen shot from Nintendulator showing what the image is supposed to look like?
I'm using the front loading NES. I just put all the files for the game and a Nintendulator screen shot on my website. The FCEUD emulation actually looks closer to the actual console/TV combination with the colours looking brighter and less muddy than the Nintendulator output. I'm going to play around with the palette. I had no idea you had to watch out for transitions where the colours shared the same high nibble and had a different lower nibble. I'm also going to try and output the video card to play the emulator on a TV to see if the sprite problem shows up that way.
http://www3.sympatico.ca/lloyd.gordon3/
I just hooked the TV/OUT of my video card and watched the game on the TV with FCEUD playing. The colours of the background were the same all over the screen so I'll have to move the NES upstairs to try the other TV and see if it's a NES/code problem or just a specific TV. The sprite colour contrast shows the same muddiness so I guess I'll have to adjust the palette to avoid the NTSC palette upper/lower nibble contrast effect. The wierd movement artifact was definitely not showing so it must have something to do with my code as it plays on the NES. Certainly no commercial game ever had the movement artifact so maybe it's the way I set up my sprite DMA memory. Anybody ever seen this kind of movement artifact?
Lloyd Gordon wrote:
The wierd movement artifact was definitely not showing so it must have something to do with my code as it plays on the NES. Certainly no commercial game ever had the movement artifact
Fire up Super Mario Bros. and start World 1-2. Move forward at various speeds and notice the edges of the blue bricks.
Quote:
so maybe it's the way I set up my sprite DMA memory. Anybody ever seen this kind of movement artifact?
Unless you show us a picture, possibly with screen shots taken through TV-input or a digital camera, we can't really know what kind of artifact you're talking about.
Thanks for your thoughts. I tried SMB and didn't really notice any weird effects but I probably didn't know what I was looking for. Certainly I've never seen anything like the weird Moire like pattern before. I'm going to try and get a video posted soon. Or if anybody is ambitious they could put my game into a devcart and play it. (Just kidding).
I finally got a video clip on my website. My camcorder and digital camera couldn't really show any details and my video capture card isn't working so I finally recorded through the AV output of the NES directly into my camcorder and then recorded it on the computer using firewire. It's still not ideal but it does show a weird rippling effect on the moving sprites almost if there were something else "behind" them. It looks more like a moire effect on the actual TV when it's played on the NES console. If anybody has any ideas, please let me know. I move the sprites 1 pixel per frame for the player sprites and 1 pixel per 2 frames for the enemy sprites. I reverse the sprite DMA order on every second frame to lessen the "8 sprites per scanline blanking effect". I have no idea why it makes the weird rippling or moire effect for the moving sprites. Thanks for any help.
http://www3.sympatico.ca/lloyd.gordon3/
Lloyd Gordon wrote:
It's still not ideal but it does show a weird rippling effect on the moving sprites almost if there were something else "behind" them.
There is something else "behind" the sprites; it's the NTSC color subcarrier. If the edges of your sprites are saturated colors, then they may have shimmering artifacts when they move at certain speeds. It's just the nature of cheap NTSC encoders used during the NES era (and to a lesser extent during the Super NES era, which can be demonstrated in
Mario Paint). Even the PlayStation isn't immune; try firing up a PS1 game and looking closely at the left side of the big "P" on the black screen to see
dot crawl.
Quote:
It looks more like a moire effect on the actual TV when it's played on the NES console.
It depends on how cheap your TV's comb filter is.
Quote:
I move the sprites 1 pixel per frame for the player sprites and 1 pixel per 2 frames for the enemy sprites.
Perhaps your sprites are moving at speeds that beat with the NTSC color subcarrier. You don't notice this as much in
Super Mario Bros. because at least some objects have a proper fixed-point displacement and velocity, which causes the sprite positions not to line up on any particular pattern of color subcarrier positions.
Thanks very much, Tepples. The people on this messageboard are certainly full of expert information. How does "saturated colours" correspond to the NES palette colour choices? Would having a coloured background or a tiled background make the NTSC effects less annoying? How can I adjust my sprite movement to minimize NTSC effects? Even with lots of searching around I've never seen anything like the information about the subtle video (NTSC) colour and video effects that people here know about. Are there any good references that would help me with these effects? Thanks again.
I've never seen anything like that either, so I'm at a loss to explain what the deal is. I notice it a little bit in games usually (especially with scrolling backgrounds and stuff), but not as much with sprites or to the degree in the video you posted.
How are you doing the movement now, just by pixels per frame? If you use fixed-point stuff you could have a lot more variations in speed (and if it helps with the shimmering effect, bonus). You'd do that by making the sprite position and velocity 16-bit numbers. Then for displaying the actual sprite position, just use the upper 8-bits.
You might try this, which causes a different dot crawl pattern than the usual (I think this one repeats every 3/60 second, rather than 2/60 second). It keeps PPU rendering disabled until after the even/odd frame length difference would take effect. I was able to use a delay from 2368 to 2440 (70 clock variance). Larger delays missed important events on scanline 21. Presumably you'd have code in place of the delay which did something useful during that time, but didn't vary by more than 70 clocks.
Code:
nmi: lda #$00 ; disable bg+obj
sta $2001
ldy #215 ; 2368 delay
ldx #1
delay:
dex
bne delay
ldx #1
dey
bne delay
lda #$18 ; enable bg+obj
sta $2001 ; write at NMI+2379
wait: jmp wait
Hi Memblers and Blargg,
I sort of see (or maybe I don't) what you mean but I had no idea you had to be so careful about sprite movement and position. I thought that sprite position was changed by writing to the X and Y coordinates. Near the beginning of the NMI I write to sprite RAM with the DMA. After that I run the code that alters the various sprite positions. As I said the "player" sprite moves according to the joystick at up to one pixel in the X and Y axes per NMI. I made the "enemy" sprites move 1 pixel in the X/Y axes every second NMI so the player would be able to get away or attack them easier. Then on the next NMI the updated X,Y sprite coordinates are written again with by sprite DMA. This is all new to me and I guess I will have to rewrite all my sprite movement code. I knew I was doing it in a simplistic way but I didn't realize how strange it would look. If you have any more pointers, please let me know.
Thanks
There is essentially a grid-like pattern overlayed over areas that have lots of different colored pixels. This pattern is constantly moving smoothly so that it's not that visible since you see the average of the pattern. But when you move an object in sync with it, you are able to "capture" the pattern and avoid having it average out. If you are able to move the object at a slightly different rate, you'll get some of the averaging effect (since the pattern will still be moving in relation to the object). You can see the pattern if you carefully scan your eyes smoothly across a normal television picture (but not a modern computer monitor).
If you keep some fractional precision to your sprite positions, you can easily move them at non-integral velocities, i.e. 1.3 pixels per frame rather than just 1 or 2 or 3 pixels per frame. The NES has no knowledge of fractional pixels, so you keep this internally and use the whole part when setting the actual sprite position. Since the pattern moves at an integral velocity (1 pixel per frame), you can use this to avoid falling exactly in sync.
I think I actually (maybe) understand what you mean. I'm going to try and modify my code to use the fractional velocity. Thanks again. How come I've never seen this on commercial games? Although I think I can recall a slight but similar effect on some games. Did the commercial programmers know about these effects and avoid them? I guess I unknowingly coded my enemy sprites to maximize the distortion.
Lloyd Gordon wrote:
How come I've never seen this on commercial games?
Because you were probably a lot younger when you played them.
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.
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.
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.
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.
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