It is currently Thu Nov 23, 2017 12:36 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 10 posts ] 
Author Message
PostPosted: Thu Dec 03, 2015 12:38 am 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3484
Location: Indianapolis
I know this isn't too useful, but for the fun of it, I ran a random FamiTracker-generated NSF through my NSF benchmark app, and got this:

Code:
Individual Features
DJ Tepples
2015 Damian Yerrick

NSF init finished.  719 instructions.  CPU: 2490 cycles  PPU: 21.9 lines
NSF playing... (ESC to quit)
NSF play stopped.

Max CPU: 5561 cycles  Max PPU: 48.92 lines
Average CPU: 1464 cycles  Average PPU: 12.88 lines
1550043 frames played - 430 minute(s), 3 second(s)


Here another rendition of the same test song by tepples, in his Pently 0.05wip version.
http://forums.nesdev.com/viewtopic.php?f=6&t=13589

Code:
Pently demo
DJ Tepples
2015 Damian Yerrick

NSF init finished.  177 instructions.  CPU: 639 cycles  PPU: 5.6 lines
NSF playing... (ESC to quit)
NSF play stopped.

Max CPU: 2649 cycles  Max PPU: 23.31 lines
Average CPU: 825 cycles  Average PPU: 7.26 lines
2072561 frames played - 575 minute(s), 41 second(s)



GGSound by Gradual Games. The song benchmarked is the 3rd track in the included demo, because it uses 4 channels.
http://forums.nesdev.com/viewtopic.php?f=6&t=11655
Code:
NSF init finished.  477 instructions.  CPU: 1662 cycles  PPU: 14.6 lines
NSF playing... (ESC to quit)
NSF play stopped.

Max CPU: 5361 cycles  Max PPU: 47.16 lines
Average CPU: 1577 cycles  Average PPU: 13.87 lines
1236767 frames played - 343 minute(s), 47 second(s)


Top
 Profile  
 
PostPosted: Thu Dec 03, 2015 9:37 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5830
Location: Canada
Is your NSF benchmark app publicly available?


Top
 Profile  
 
PostPosted: Thu Dec 03, 2015 11:03 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2981
Location: Tampere, Finland
(OT: NDX can also be used for NSF benchmarking -- it will display cur/avg/max in the Debugger window (Timers) when an NSF is playing.)

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


Top
 Profile  
 
PostPosted: Thu Dec 03, 2015 11:41 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5830
Location: Canada
That's useful. Thanks.


Top
 Profile  
 
PostPosted: Thu Dec 03, 2015 12:51 pm 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2981
Location: Tampere, Finland
(Maybe this NSF benchmarking discussion should be split off?)

Here's something I always found interesting: Solstice, with one of the more technically complex tunes you can find on NES, only averages around 500-600 cycles in its play routine. Same seems to be true for most other Follin tunes (Silver Surfer, ...).

I find most other games to be in the 1000-2000 cycle range.

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


Top
 Profile  
 
PostPosted: Thu Dec 03, 2015 9:39 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3484
Location: Indianapolis
rainwarrior wrote:
Is your NSF benchmark app publicly available?


Sort-of, it's put together sloppily but my post in this thread has it attached:
http://forums.nesdev.com/viewtopic.php?f=3&t=13322

To use it, the NSF file has to be renamed to "guardian.nsf".. yeah, I know how to use argc and argv since then.
(edit: also, it only plays the starting track #)

I'm sure Nintendulator DX is a better option, but there it is anyways.

Since this is a new thread now, one of the things I was wondering about, is if Famitracker's engine is anything like NT2, the big CPU usage spike is at the beginning of a new pattern. If so, it makes me wondering if staggering the channel processing over a couple frames would help it much. Like having pulse #2 and noise always lag by one frame. Just a thought, maybe it'd be noticeable in some cases, but detrimental, I kinda doubt it.

Long ago when I was writing my SNES NSF player, I was using the background color to see CPU usage of various NSFs, I seem to remember that Jeroen Tel stuff (Robocop 3 in particular) had very consistent CPU usage, like the color bar was barely moving.


Top
 Profile  
 
PostPosted: Thu Dec 03, 2015 10:16 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5830
Location: Canada
Memblers wrote:
Since this is a new thread now, one of the things I was wondering about, is if Famitracker's engine is anything like NT2, the big CPU usage spike is at the beginning of a new pattern.

Changing a pattern isn't really that expensive by itself. I think Famitracker tends to peak on frames with a lot of active effects, and/or a new note on every row. A lot of patterns happen to begin with a set of new notes across all channels and a bunch of effects on the first row, which would tend to put a spike there (but not specifically because of the pattern change itself).

Memblers wrote:
If so, it makes me wondering if staggering the channel processing over a couple frames would help it much. Like having pulse #2 and noise always lag by one frame. Just a thought, maybe it'd be noticeable in some cases, but detrimental, I kinda doubt it.

There are a lot of cases where this would be very noticeable.


Top
 Profile  
 
PostPosted: Fri Dec 04, 2015 10:43 pm 
Offline
User avatar

Joined: Fri Aug 23, 2013 2:14 am
Posts: 264
Hmm, I always assumed that FT produced music was not very optimized for actual game use, guess this benchmarking tool sorta proves that. I reckon the more advanced FT songs (Extends Levant/HertzDevil, anything by Chibi-Tech) would be impossible to work in an NES game scenario, right?


Top
 Profile  
 
PostPosted: Fri Dec 04, 2015 11:34 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5830
Location: Canada
Just because something sounds busy doesn't mean it's impossible or impractical in a game, or even that it's using too much CPU.

Other than technical problems like nonstandard playback rates (e.g. 240Hz NSFs), or expansion audio, or PCM samples, for the most part the music people are making now could get into a game.

There are a number of constraints that real games have (especially ROM space, RAM space) that commercial-era NES game composers had to make strong sacrifices to meet. People making music in Famitracker aren't trying to meet any of these constraints, which gives them a much wider palette of expression than most game composers had available to them.

The CPU speed of Famitracker isn't really that big an issue. Its RAM usage is a little bit high, but with WRAM it'd be a non-issue. ROM usage of the kind of detailed music a lot of people write now is a concern if you're making a game, but this is a question of how much space you're willing to dedicate to music. There were 2 or 3 NES games with very large soundtracks (64k was about as big as they ever got), but people routinely write much larger single songs in Famitracker. They might actually be able to write something similar in smaller spaces if they were forced to deal with space constraints (they simply haven't had to deal with it via Famitracker), or it might even be sensible to just use larger ROM sizes now. Depends on the game and your project goals.


Top
 Profile  
 
PostPosted: Fri Dec 25, 2015 9:51 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3484
Location: Indianapolis
Coming back the 'staggered channel update' idea, I thought of a variation that should be less noticeable by moving the audible delay to the end of a note. So if the channels are updated in 2 phases, the first phase channels would have (beforehand) added a dummy entry to all the envelopes (at volume 0), and the second phase channels would be processed normally in the next frame. So in the tracker when you have every channel hitting on the same line, the note/instrument/pattern initialization could happen on different frames, while the actual sound of both channels would start on the same frame. You would just have a forced cut-off right before a new note, but only the first phase channels. The more percussive the instrument used, the less noticeable the early cut-off would be.

If anyone wondered why all this, it's to get a lower worst-case CPU usage.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google [Bot], RPMX 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