It is currently Wed Dec 12, 2018 8:45 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 93 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7  Next
Author Message
PostPosted: Sun Apr 08, 2018 11:19 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7604
Location: Chexbres, VD, Switzerland
tokumaru wrote:
I use completely unrolled code (i.e. no index increments or branches, which saves a lot of time)

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.


Top
 Profile  
 
PostPosted: Sun Apr 08, 2018 11:58 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11011
Location: Rio de Janeiro - Brazil
Bregalad wrote:
Most of the time, a partially unrolled loop will do almost just as well as a fully unrolled loop

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.

Quote:
...without wasting a ridiculous amount of ROM.

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.


Top
 Profile  
 
PostPosted: Mon Apr 09, 2018 12:57 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7604
Location: Chexbres, VD, Switzerland
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.


Top
 Profile  
 
PostPosted: Mon Apr 09, 2018 1:21 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11011
Location: Rio de Janeiro - Brazil
Oh yeah, if what you have is a fully rolled loop, just partially unrolling it should result in a significant speed improvement.


Top
 Profile  
 
PostPosted: Mon Apr 09, 2018 4:30 am 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2777
On the NES how many cycles does OAM DMA take? Are you doing any kind of dynamic animation?


Top
 Profile  
 
PostPosted: Mon Apr 09, 2018 4:58 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1786
Location: Gothenburg, Sweden
According to this wiki article, itself referring to Dischs' document:
Quote:
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


And in the PPU OAM article, there's a more precise specification:
Quote:
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.)


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.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Mon Apr 09, 2018 5:41 am 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2777
Dynamic updates as in CHR-RAM updates. Although if I was making an NES game, I'd probably use bankswitched CHR-ROM instead.


Top
 Profile  
 
PostPosted: Wed Apr 11, 2018 6:00 pm 
Offline

Joined: Wed Apr 04, 2018 7:29 pm
Posts: 38
Location: Montreal, Canada
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


Top
 Profile  
 
PostPosted: Wed Apr 11, 2018 8:44 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11011
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Thu Apr 12, 2018 8:03 pm 
Offline

Joined: Wed Apr 04, 2018 7:29 pm
Posts: 38
Location: Montreal, Canada
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


Top
 Profile  
 
PostPosted: Thu Apr 12, 2018 8:49 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11011
Location: Rio de Janeiro - Brazil
bleubleu wrote:
The top/bottom 8px that don't get rendered normally

They absolutely ARE rendered normally.

Quote:
(or cropped by real CRTs)

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.


Top
 Profile  
 
PostPosted: Thu Apr 12, 2018 9:05 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20867
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Fri Apr 13, 2018 2:52 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 709
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.


Top
 Profile  
 
PostPosted: Fri Apr 13, 2018 2:57 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 3141
Location: Tampere, Finland
tokumaru wrote:
but I've heard that PAL TVs show everything.

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.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi


Top
 Profile  
 
PostPosted: Fri Apr 13, 2018 3:28 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7604
Location: Chexbres, VD, Switzerland
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.

I agree, and this is >95% of japanese-NTSC developed games.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 93 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Memblers, tepples and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group