nesdev.com
http://forums.nesdev.com/

pipeline clarification
http://forums.nesdev.com/viewtopic.php?f=3&t=39
Page 2 of 2

Author:  Disch [ Fri Nov 19, 2004 9:42 pm ]
Post subject: 

I don't see why that would be advantagous. A scanline rendering enging is not only less accurate but potentially slower than a properly written cycle/pixel based renderer. In a cycle-based renderer, you can only catch up the PPU when needed (which will only occur in games which do mid-scanline or mid-frame writes). Whereas scanline-based renderers constantly catch up the PPU every HBlank, even if it isn't needed.

Such an auto-detect mechanism seems like it wouldn't serve a purpose other than bloat your exe and slow the thing down.

Author:  Hyde [ Fri Nov 19, 2004 10:58 pm ]
Post subject: 

Regarding Tepples' question, the emulator does not automatically switch from one core to another. It does, however, give the user the choice of switching cores in the middle of a game or prior to the beginning of one. This way, things are less CPU intensive. Now, as for Disch's comments, I still don't see how keeping track of various timestamps is any faster than rendering things scanline by scanline. Either way, you still must render things. The .exe's size is close to the 800 KB mark, mostly due to the fact that I am now using wxWidgets for GUI purposes.

Author:  Nessie [ Sat Nov 20, 2004 12:01 am ]
Post subject: 

The catch-up approach can be optimized beyond any scanline engine, I just haven't bothered doing it with mine.

If the PPU is a whole frame behind when it's catching up, you can render a whole frame at once a lot faster than rendering 240 scanlines. If it's more than 8 scanlines behind you can render those 8 scanlines very fast if they use the same tiles. Well, you get the idea...

This turns out to be pretty complex, since you'll need to pre-calculate when IRQs or sprite #0 hits will take place. We don't wanna run the catch-up sequence on every CPU instruction or every $2002 read.
So, I just gave it up and left my emu running one cc at a time... :) It's not fast, but wtf...

Author:  Zepper [ Sat Nov 20, 2004 7:07 am ]
Post subject: 

Disch wrote:
(...)In a cycle-based renderer, you can only catch up the PPU when needed (which will only occur in games which do mid-scanline or mid-frame writes).


...o_0;;
Unless I'm misunderstanding the things, but... doesn't the PPU render a single pixel at every clock? Currently, I parse the PPU values (of scrolling) and put the proper pixel. I believe the hardware does this way... No major problems with games.

Author:  Hyde [ Sat Nov 20, 2004 11:05 am ]
Post subject: 

Nessie wrote:
If the PPU is a whole frame behind when it's catching up, you can render a whole frame at once a lot faster than rendering 240 scanlines. If it's more than 8 scanlines behind you can render those 8 scanlines very fast if they use the same tiles. Well, you get the idea...


Hmm... I should try that sometime.

Page 2 of 2 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/