This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Extra blanking time, again

Extra blanking time, again
by on (#47959)
Hey everyone, I just had an idea for that whole issue of blanking the top scanlines that I'd like to validate with you guys. Should I decide to actually disable rendering during the first few scanlines of a frame, what would the procedure be to not mess with the 341/340 cycles pattern of the pre-render scanline?

If I keep only sprites enabled as the frame starts, will the 340/341 pattern still occur? If so, would it be OK to then disable the sprites during the first rendered scanline (since they don't show up there anyway) and after the blank scanlines enable both sprites and background again?

Do you see anything wrong with this approach? What about that bug tepples discovered with his game that had something to do with the exact moment when sprites were disabled?

by on (#47979)
I made a test ROM and this technique seems to work the same across the emulators I tested without any timing discrepancies. I just have to test it on my NES to make sure it works. I'll do it tomorrow because the sun is already rising and I have to get some sleep.

I used the same sprite test I used on my previous test ROM, and all groups were correctly rendered. Only FCEUXD showed some glitches during the very first scanline, but based on previous experiments I know it does show sprite garbage up there quite often, even though it's impossible for sprites to actually show up there, so it's probably a bug of the emulator, which is quite dated.

I want to have rendering enabled by the time the frame starts because I don't want to alter the dot crawl pattern. I do not mind the different pattern on static pictures, in fact I think it even looks better in this case, but depending on the kind of movement the dot crawl can look pretty weird and not constant.

by on (#48009)
Yeah, all hell breaks loose if sprites are disabled during rendering, as discovered by tepples and blargg. Back to the drawing board, I guess. Maybe I should just consider sticking to the alternate dot crawl, as that would solve all my problems.

by on (#48019)
Being a total noob in NES programming I have a hard time following your explanations, could you possibly post your code example? :)

by on (#48044)
Heh, this is just one more try of my never ending quest for a nice clean bar at the top of the screen that will hide vertical scrolling glitches. The 2 possible approaches are:

1. Disable rendering during VBlank and enable it back a few scanlines (the bar's height) after the frame has started.

Strong points: since rendering is off, more data can be sent to VRAM; can be done with any mapper and it doesn't matter if CHR is ROM or RAM;

Weak points: will alter the dot crawl pattern; must use hacky $2005/$2006 writes to set the scroll; enabling/disabling sprites during rendering is very timing-sensitive, and glitches may happen; needs timed code or IRQs that don't rely on rendering;

2. Select transparent patterns for the whole pattern table, so that although rendering is enabled, only the background color will be rendered. After a few scanlines, the actual patterns to be used for the frame are switched in.

Strong points: doesn't mess with the regular PPU behavior; mapper IRQs can eliminate the need for timed code;

Weak points: requires a mapper with CHR bankswitching; wastes CHR by holding blank tiles; the time it takes to bankswitch patterns depends on the mapper, so the overall timing has to be adjusted accordingly;

So, I've played with both techniques but there is always a point where one of their flaws gets in my way. So I'm currently experimenting with a variation of the first technique. This variation is supposed to fix the dot crawl issue.

I don't know the details because I don't understand much about video signals, but if rendering is disabled by the time rendering starts, the image looks different than usual. It has something to do with an extra PPU cycle at the end of the pre-render scanline. This affects how jagged some lines look and things like that.

Some people don't mind the difference, but I'd prefer to have the normal type of dot crawl, which is why I was trying a variation of the first technique, where sprite rendering would be on at the start of the frame (the backgorund doesn't need to be enabled).

Thing is that disabling sprites during rendering can have very undesirable results, as tepples and blargg recently discovered. This topic was my attempt to get others' impressions on this technique, but it appears nobody was really interested. I don't blame them, I've been insisting on this border thing for too long already!

Anyway, if anyone wants to know the result, through tests on my NES I found out that if sprites are disabled and enabled at the very end of the scanlines, no sprite corruption seems to happen. So it appears I will be able to have the border I always wanted with no side effects. But I'm too tired of this already, and if eventually side effects do show up I'll just accept the different dot crawl.

by on (#48045)
I don't understand most of your monologue, but my pesonal advice would be to avoid artificial VBlank for a part of the screen if you can.
"Normal" PPU updates of up to 2 rows or 2 colomns or one row + one columns, with corresponding attributes updates and sprite DMA are possible with completely rolled loops, and more is possible with unrolled loops.

The only way this really won't be enough is if you want to do a lot of CHR-RAM updates. If you use CHR-ROM you definitely want to use blank pattern instead.

by on (#48046)
Bregalad wrote:
my pesonal advice would be to avoid artificial VBlank for a part of the screen if you can.

I understand why that's advisable. Playing by the rules surely is much safer than trying to bend them.

But balancing what we want is tough. If you want to animate parts of the pattern tables you either need a mapper that can switch it in small chunks or you have to use CHR-RAM. Since I want the carts for my games to be easy to make, I should avoid complex mappers, meaning that the only way is the Battletoads way.

Quote:
"Normal" PPU updates of up to 2 rows or 2 colomns or one row + one columns, with corresponding attributes updates and sprite DMA are possible with completely rolled loops, and more is possible with unrolled loops.

I agree that regular VBlank should be enough for the basic tasks, but if you want to update a significant chunk of the pattern tables you need extended VBlank.

by on (#48047)
If you do want to update a significant chunk of pattern tables, usually you could do it 4 tiles at a time and split the update in small parts. If you can't then go the Battletoads way, but only if you can't do something else. My opinion is that artificial VBlank is overrated on this forum, but that's just my opinion.

by on (#48048)
Small updates aren't enough when you want to animate your main character with them. The main character is usually the greatest tile user, so it is a big advantage to have his patterns be dynamic. That makes it possible for him to have many more frames than usually possible, and even makes room for other sprites.

I too have my reservations when it comes to forced blanking, but in this case I was thinking: since I'll spend quite a few scanlines doing nothing, I might as well use that time to update tiles.

by on (#48049)
Quote:

Small updates aren't enough when you want to animate your main character with them. The main character is usually the greatest tile user, so it is a big advantage to have his patterns be dynamic.

This is 100% correct. The player is more likely to notice details on the main character than on random enemies, so it must be designed with care.

However, by using double-buffering techniques, if updating the frame each odd frames is enough, you could go ahead without using Battletoads techniques. Or if you are writing a RPG where the main character is 16x16 pixels. Else, yeah go the battletoads way.
Again do like you wan't I just think personally that forced blanking is overrated and should be avoided unless absolutely necessary, but that don't mean you can't use it.

by on (#48053)
The NES with 8 KB CHR RAM has enough CHR RAM for 128 8x16 sprite tiles. This is in theory enough to double-buffer all 64 sprites on the screen. The limitation is VRAM bandwidth. Animate a main character slightly bigger than Super Mario (five 8x16 tiles, including extra space for oversized feet) at 12 fps (Disney cel animation frame rate), and that's 1 tile per frame. I've calculated that one can comfortably fit five 32-byte copies plus OAM DMA into NTSC vblank, so copying two rows, two columns, and 1/5 of the main character leaves no time left for copying anything else, like animated backgrounds or enemy sprite animations or the palette.

"Overrated"? That's what Nintendo fanboys said about Sega's "Blast Processing" engine that powered Sonic the Hedgehog 2 for Sega Genesis. But if you want to make a game that moves as fast as Sonic 2. you might have to extend vblank.

by on (#48069)
That's why they needed a mapper that could take unmapped CHR-RAM sections of VRAM (for patterns) and map it into CPU address range so you don't have to do everything in vblank. I guess large_rom+MMC3/5 was cheap enough not warrant it.

by on (#48107)
tepples wrote:
"Overrated"? That's what Nintendo fanboys said about Sega's "Blast Processing" engine that powered Sonic the Hedgehog 2 for Sega Genesis. But if you want to make a game that moves as fast as Sonic 2. you might have to extend vblank.

"Blast Processing" is DMA to VRAM, that's it.

by on (#48117)
LocalH wrote:
tepples wrote:
"Overrated"? That's what Nintendo fanboys said about Sega's "Blast Processing" engine that powered Sonic the Hedgehog 2 for Sega Genesis. But if you want to make a game that moves as fast as Sonic 2. you might have to extend vblank.

"Blast Processing" is DMA to VRAM, that's it.


What!? I've never heard Blast Processing referred to as that. That would mean the SNES has Blast Processing x8 ;) There's no hidden meaning. It was marketing term to tell people the system as a whole was pretty fast, instead of bogging down people with technical details. It's more effective that way. People buy into that shite all the time.

by on (#48123)
The more I investigated it, the more I thought "Blast Processing" was the name of Sonic 2's engine, like "Build" or "id Tech 3" or "RAGE" engines.