Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.
I just improved my 400+ color palette demo to not shake (well, it shakes by two pixels, but at 30 Hz, so it's much less noticeable). Cleaner, easier-to-follow code is included, rather than the super-optimized code like in the previous version. NTSC-only at the moment:
blargg wrote:I just improved my 400+ color palette demo to not shake (well, it shakes by two pixels, but at 30 Hz, so it's much less noticeable). Cleaner, easier-to-follow code is included, rather than the super-optimized code like in the previous version. NTSC-only at the moment:
I find it funny that the first image is full of harmony and looks very clean, while the second one looks like a TV with really bad interference, even though they are composed by the same rows, just arranged differently (the JPEG artifacts don't help, but both images have them)...
Yeah, the left image looks more vibrant and clean, but doesn't really show how smooth a gradient you get. You are left wondering whether some colors are repeated. The right one makes it very clear that this isn't just showing 52 colors or something puny.
Sure, but unless I can make the inner loops similar enough to be switched based on a variable, it would involve having both loops in the code, and thus more complexity. It's already complex enough to follow as it is. I'll take a look though, since it would be nice to have one ROM.
I came across your vertical stretch demo where you blend lines via flickering. I realized that this would benefit the smooth gradient version of this palette demo. Since it already shakes horizontally at 30 Hz, effectively blending the vertical edges, I could have it shake vertically as well, blending it all together more.
blargg wrote:Sure, but unless I can make the inner loops similar enough to be switched based on a variable, it would involve having both loops in the code, and thus more complexity. It's already complex enough to follow as it is.
For each mode, make a 32-entry table of tints and a 32-entry table of starting colors. Order them in ROM as normal_tints, smooth_tints, normal_startcolors, smooth_startcolors. Then display entries 0-31 or 32-63 of each table.
I put up a nice page on the Wiki describing how this demo works, and updated the source code to be cleaner and easier to follow. Unfortunately, I didn't put in controller control of alternating between two palettes, as it would have complicated the code more than it was worth.
Well Blargg, congratulation for this demo which was implemented in an incredibly clever way.
If I understand way, you managed to get completely rid of all jittering (or get only 1 pixel jitter I haven't understood exacly).
How did you manage this exploit ? I always got ~9 pixels (3 CPU clock) jittering at best (NTSC).