It is currently Wed Dec 13, 2017 2:26 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 20 posts ]  Go to page Previous  1, 2
Author Message
 Post subject:
PostPosted: Fri Nov 19, 2004 9:42 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
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.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Nov 19, 2004 10:58 pm 
Offline

Joined: Mon Sep 27, 2004 11:51 pm
Posts: 101
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.

_________________
http://hydesprojects.cjb.net/


Top
 Profile  
 
 Post subject:
PostPosted: Sat Nov 20, 2004 12:01 am 
Offline

Joined: Mon Sep 20, 2004 11:13 am
Posts: 134
Location: Sweden
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...


Top
 Profile  
 
 Post subject:
PostPosted: Sat Nov 20, 2004 7:07 am 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3076
Location: Brazil
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.

_________________
Zepper
RockNES developer


Top
 Profile  
 
 Post subject:
PostPosted: Sat Nov 20, 2004 11:05 am 
Offline

Joined: Mon Sep 27, 2004 11:51 pm
Posts: 101
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.

_________________
http://hydesprojects.cjb.net/


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 20 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 6 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