Most of the time, a partially unrolled loop will do almost just as well as a fully unrolled loop, but without wasting a ridiculous amount of ROM. For example, in a "normal" loop you'd spend half the time doing increment/decrement and compare, and half the time actually transfering data, 50%/50%, this is the worst case. A partially unrolled loop can get you arround 20%/80%, while a fully unrolled loop would get you to 0%/100% ; the closer you get to fully unrolled, the more ROM you waste for a very marginal time gain.tokumaru wrote:I use completely unrolled code (i.e. no index increments or branches, which saves a lot of time)
Advice for artifact free 4-way scrolling
Moderator: Moderators
Re: Advice for artifact free 4-way scrolling
Re: Advice for artifact free 4-way scrolling
I can assure you I do need every cycle I can get. I have like, 6 or so cycles of vblank time left in the case I mentioned above, where both a column and a row of metatiles need to be updated.Bregalad wrote:Most of the time, a partially unrolled loop will do almost just as well as a fully unrolled loop
ROM is a cheap resource most of the time, so I'll gladly sacrifice it if that means improvements on aspects that are not as flexible (e.g. RAM and CPU time). Not all kinds of unrolled loops need "ridiculous amounts of ROM" though: 128 bytes (PLA + STA $2007 32 times) is hardly a ridiculous amount of space. I usually put my vblank handlers in a separate PRG bank anyway, so I have plenty of room for unrolled code that'll allow me to make the most out of the limited vblank time....without wasting a ridiculous amount of ROM.
Re: Advice for artifact free 4-way scrolling
Yeah, if you have to use fully unrolled loops because partially unrolled doesn't make it, then using the stack with PLA makes the most sense, because it uses much less ROM (even though it's the same speed as a LDA $xxxx,X).
I don't deny that fully unrolled makes sense in some cases, such as yours, but in the majority of cases where a fully rolled loop barely don't make it in time, a partially unrolled loop will. I was just pointing out that.
I don't deny that fully unrolled makes sense in some cases, such as yours, but in the majority of cases where a fully rolled loop barely don't make it in time, a partially unrolled loop will. I was just pointing out that.
Re: Advice for artifact free 4-way scrolling
Oh yeah, if what you have is a fully rolled loop, just partially unrolling it should result in a significant speed improvement.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Advice for artifact free 4-way scrolling
On the NES how many cycles does OAM DMA take? Are you doing any kind of dynamic animation?
- FrankenGraphics
- Formerly WheelInventor
- Posts: 2064
- Joined: Thu Apr 14, 2016 2:55 am
- Location: Gothenburg, Sweden
- Contact:
Re: Advice for artifact free 4-way scrolling
According to this wiki article, itself referring to Dischs' document:
And in the PPU OAM article, there's a more precise specification:On NTSC, count on being able to copy 160 bytes to nametables or the palette using a moderately unrolled loop, plus one 256-byte display list to OAM
Any dynamic updates are best done to the buffer, rather than individual edits to OAM. If you want to beat OAMDMA you must restrain yourself to update less than 16 sprites (or less than 64 OAM entries in any case) per average vblank.Not counting the OAMDMA write tick, the above procedure takes 513 CPU cycles (+1 on odd CPU cycles): first one (or two) idle cycles, and then 256 pairs of alternating read/write cycles. (For comparison, an unrolled LDA/STA loop would usually take four times as long.)
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Advice for artifact free 4-way scrolling
Dynamic updates as in CHR-RAM updates. Although if I was making an NES game, I'd probably use bankswitched CHR-ROM instead.
Re: Advice for artifact free 4-way scrolling
Hey guys.
Sorry to resurrect my own thread. I'm doing the black bars at the top and bottom.
Jurassic park does it by bank switching. One thing i overlooked is that they assume that every palette has a black color at the same location. I think this is a big constrain on colors, so I would like to avoid that. But id still like the bars to be black (having them the BG color is easy).
For the bottom one, its kind of easy. Receive and IRQ, wait until hblank, disable PPU and do a palette swap real quick and the bottom of the screen goes black. Done. If timed correctly its 100% clean.
The top is really hard. Almost impossible. Palette swaps are possible, but it messes the scrolling. It can be fixed, but it requires that weird 2006/2005/2005/2006 trick described in that skinny doc. But by the time you swapped the palette and fixed the scrolling, 1-2 lines of garbage will have time to draw. Am I missing something here?
The other way that was mentioned is with a sprite overflow. But i'm not sure it solves anything. Will I still have to do a palette swap in that case too i guess.
Is there a 3rd option I am missing?
Thanks!
-Mat
Sorry to resurrect my own thread. I'm doing the black bars at the top and bottom.
Jurassic park does it by bank switching. One thing i overlooked is that they assume that every palette has a black color at the same location. I think this is a big constrain on colors, so I would like to avoid that. But id still like the bars to be black (having them the BG color is easy).
For the bottom one, its kind of easy. Receive and IRQ, wait until hblank, disable PPU and do a palette swap real quick and the bottom of the screen goes black. Done. If timed correctly its 100% clean.
The top is really hard. Almost impossible. Palette swaps are possible, but it messes the scrolling. It can be fixed, but it requires that weird 2006/2005/2005/2006 trick described in that skinny doc. But by the time you swapped the palette and fixed the scrolling, 1-2 lines of garbage will have time to draw. Am I missing something here?
The other way that was mentioned is with a sprite overflow. But i'm not sure it solves anything. Will I still have to do a palette swap in that case too i guess.
Is there a 3rd option I am missing?
Thanks!
-Mat
Re: Advice for artifact free 4-way scrolling
What you're trying to do is way more complicated than what Jurassic Park does. Messing with the palette mid-screen is not for the faint of heart. Disabling/enabling rendering mid-screen can also corrupt sprites in certain cases.
If you're dead set on doing this the harder way just so you can have black borders, I suggest you figure out how "that weird 2006/2005/2005/2006 trick" actually works, otherwise you'll end up in a world of frustration.
Another tip that may help you out, is that when rendering is off and the PPU address register (the one you set via $2006) is pointing to the palette area, the color at that address gets displayed instead of the background color. Combine that with the fact that even though they're never displayed during rendering, color 0 of the last 3 background palettes ($3F04, $3F08 and $3F0C) still exist in memory, so you can have one of them set as black and simply point at it when rendering is off, eliminating the need to change the background color. For the top border, you still have to set the scroll, of course, since the address register will be pointing at the black palette entry. And you'll need to time the top border using something other than MMC3 IRQs if rendering is off.
A sprite overflow would only mask sprites, you'd still have to do something about the background.
Are you sure that the background color isn't good enough for the border? If you settle for that you can just do what JP does and use blank (i.e. color 0) tiles for the border.
You could also use the grayscale and/or color emphasis bits to make the border look different from the background color without much trouble, since those don't affect the scroll.
If you're dead set on doing this the harder way just so you can have black borders, I suggest you figure out how "that weird 2006/2005/2005/2006 trick" actually works, otherwise you'll end up in a world of frustration.
Another tip that may help you out, is that when rendering is off and the PPU address register (the one you set via $2006) is pointing to the palette area, the color at that address gets displayed instead of the background color. Combine that with the fact that even though they're never displayed during rendering, color 0 of the last 3 background palettes ($3F04, $3F08 and $3F0C) still exist in memory, so you can have one of them set as black and simply point at it when rendering is off, eliminating the need to change the background color. For the top border, you still have to set the scroll, of course, since the address register will be pointing at the black palette entry. And you'll need to time the top border using something other than MMC3 IRQs if rendering is off.
A sprite overflow would only mask sprites, you'd still have to do something about the background.
Are you sure that the background color isn't good enough for the border? If you settle for that you can just do what JP does and use blank (i.e. color 0) tiles for the border.
You could also use the grayscale and/or color emphasis bits to make the border look different from the background color without much trouble, since those don't affect the scroll.
Re: Advice for artifact free 4-way scrolling
Actually, I'm a moron. Never mind.
The top/bottom 8px that don't get rendered normally (or cropped by real CRTs) are enough to hide any attribute garbage.
No need for additional black bar, if you code it correctly. Which I am doing right now.
-Mat
The top/bottom 8px that don't get rendered normally (or cropped by real CRTs) are enough to hide any attribute garbage.
No need for additional black bar, if you code it correctly. Which I am doing right now.
-Mat
Re: Advice for artifact free 4-way scrolling
They absolutely ARE rendered normally.bleubleu wrote:The top/bottom 8px that don't get rendered normally
This is the case of most NTSC sets (although it's not a clean "8 at the top, 8 at the bottom", it can vary a lot depending on the TV), but I've heard that PAL TVs show everything.(or cropped by real CRTs)
Re: Advice for artifact free 4-way scrolling
Overscan is very close to a clean 8/8 on digital sets, but on analog sets, you're right that it varies. I've measured a couple TVs in the wild, and you can measure your own with a PowerPak and 240p Test Suite.
-
- Posts: 1510
- Joined: Thu May 19, 2005 11:30 am
Re: Advice for artifact free 4-way scrolling
I would recommend not assuming that the top and bottom eight scanlines are shown --- so don't put anything important there --- but not assuming that they are not shown either. If you can avoid showing garbage in any part of the screen, then by all means, do avoid it. As a PAL NES owner, I have always borne a grudge against game developers who just nonchalantly tolerate ugly scroll seams at the top and bottom screen edges.
Re: Advice for artifact free 4-way scrolling
Those extra 50 scanlines in the PAL PPU "vblank" are actually part of the active picture area in a PAL TV, so there's around 25 scanlines of black padding at the top and bottom of the picture. That's why the full 240 scanlines (well, actually 239 in the PAL PPU) are displayed despite most TVs hiding some of the scanlines.tokumaru wrote:but I've heard that PAL TVs show everything.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
Re: Advice for artifact free 4-way scrolling
I agree, and this is >95% of japanese-NTSC developed games.NewRisingSun wrote:I have always borne a grudge against game developers who just nonchalantly tolerate ugly scroll seams at the top and bottom screen edges.