View unanswered posts | View active topics It is currently Mon Feb 18, 2019 6:30 pm



This topic is locked, you cannot edit posts or make further replies.  [ 234 posts ]  Go to page Previous  1 ... 6, 7, 8, 9, 10  Next
bsnes v0.037a released 
Author Message
Veteran

Joined: Wed Aug 04, 2004 5:43 pm
Posts: 861
Location: Sloop
Post 
creaothceann wrote:
The reason why internal recording options are so immensely great, why e.g. the TASers maintain their own emulator forks if necessary, is that nothing gets lost. You get frame-perfect results, no matter how long it takes to render a frame. External programs like Fraps are inherently flawed in that regard.


Are you talking about videos here, or the WAV option? Because I doubt there's any perceptible difference between bsnes output and some external program for WAVs. If there was a 1% loss of quality, you'd have to explain the applications demanding it because we already have archival quality SPCs for every game.

I understand the argument for emulator format videos, but I wasn't referring to that. I don't even know if such a thing is possible in bsnes or how often it would be used over an emulator that had savestates. Seems to me that TASers wouldn't use bsnes regardless, which makes FRAPS good enough.


Thu Dec 04, 2008 3:17 am
Profile
Inmate

Joined: Thu Jan 11, 2007 4:28 am
Posts: 1485
Location: Salem, Oregon
Post 
FitzRoy wrote:
because we already have archival quality SPCs for every game.


for the most part, but the archive is still expanding, no? it isn't really COMPLETE per se, I'm just saying.

_________________
byuu wrote:
Seriously, what kind of asshole makes an old-school 2D emulator that requires a Core 2 to get full speed? >:(


Thu Dec 04, 2008 3:40 am
Profile WWW
Hazed

Joined: Tue Jan 16, 2007 5:32 pm
Posts: 54
Post 
byuu wrote:
Do they make you drink it there? o.O

Nah, christmas times is just all about julmust here(sweden). :P

/random stuff in serious discussions.


Thu Dec 04, 2008 5:57 am
Profile
Lurker

Joined: Tue Apr 10, 2007 4:30 pm
Posts: 152
Location: Sweden
Post 
About TAS, why not give people the option to try and run recorded input? Sure, they can't create it since there are no savestates, but bsnes is hardware accurate as far as possible, right?


Thu Dec 04, 2008 7:22 am
Profile WWW
Veteran

Joined: Wed Aug 04, 2004 5:43 pm
Posts: 861
Location: Sloop
Post 
Panzer88 wrote:
FitzRoy wrote:
because we already have archival quality SPCs for every game.


for the most part, but the archive is still expanding, no? it isn't really COMPLETE per se, I'm just saying.


SPC ripping would be preferable to a wav recorder because of the filesize difference, track isolation, and lack of an external option. A wav just records the sound of gameplay. I'm not really sure why you'd want to do that or what you'd use it for. But it's a function that can be accomplished externally with ease. If one program can do it well for everything externally, there's no need to depend on each and every program adding some kind of custom internal support. Even if they did, just try and remember how to on all those different programs. You just can't avoid using an external program, it works and works the same way for everything.


Thu Dec 04, 2008 8:32 am
Profile
Inmate

Joined: Thu Jan 11, 2007 4:28 am
Posts: 1485
Location: Salem, Oregon
Post 
FitzRoy wrote:
Panzer88 wrote:
FitzRoy wrote:
because we already have archival quality SPCs for every game.


for the most part, but the archive is still expanding, no? it isn't really COMPLETE per se, I'm just saying.


SPC ripping would be preferable to a wav recorder because of the filesize difference, track isolation, and lack of an external option. A wav just records the sound of gameplay. I'm not really sure why you'd want to do that or what you'd use it for. But it's a function that can be accomplished externally with ease. If one program can do it well for everything externally, there's no need to depend on each and every program adding some kind of custom internal support. Even if they did, just try and remember how to on all those different programs. You just can't avoid using an external program, it works and works the same way for everything.


Oh I completely agree, you misunderstood, I mean we are still expanding our SPC database, they aren't all dumped yet.

_________________
byuu wrote:
Seriously, what kind of asshole makes an old-school 2D emulator that requires a Core 2 to get full speed? >:(


Thu Dec 04, 2008 8:42 am
Profile WWW
Veteran

Joined: Wed Aug 04, 2004 5:43 pm
Posts: 861
Location: Sloop
Post 
I should correct myself, SPC is not archival quality, it doesn't capture an infinitesimal amount at the beginning. And there are games that stream data and won't rip to it. It's the best we have though, a slightly better format might be possible, but a perfect one may not be.


Thu Dec 04, 2008 8:54 am
Profile
Buzzkill Gil

Joined: Wed Jan 12, 2005 7:14 pm
Posts: 4231
Post 
I thought someone HAD spec'ed a better format, and people just ignored it.

http://snsf.caitsith2.net/

Star Ocean and Tales of Phantasia rips, among other things.




And I'm sure this trips some drama with SOMEONE.


Thu Dec 04, 2008 9:45 am
Profile
Trooper
User avatar

Joined: Fri Aug 18, 2006 2:45 pm
Posts: 515
Post 
FitzRoy wrote:
because we already have archival quality SPCs for every game.
not quite.

since .SPCs was simply a snapshot or 'savestate' of SPC700,
with the way of sound being programmed, some game music just can't be SPC-ed properly *cough* FEDA *cough*

i would love if someone may managed to made the .SPC version of that game, from SPC700 activity logs...

i do prefer SPC over WAV or stuff..


Thu Dec 04, 2008 11:23 am
Profile
Seen it all
User avatar

Joined: Mon Jan 03, 2005 5:04 pm
Posts: 2302
Location: Germany
Post 
FitzRoy wrote:
Are you talking about videos here, or the WAV option? Because I doubt there's any perceptible difference between bsnes output and some external program for WAVs.

I'm referring to both (WAV recording is a part of video recording). With external programs you get what you hear which can include audible clicks, especially if the PC is not fast enough to do both emulation and recording (maybe with compression) at the same time.

The standard scenario for an emulator is "one user, emulation at realtime, synchronization to the video and audio devices". That's a very restricted model though, and removing these restrictions can be worthwhile.

_________________
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list


Thu Dec 04, 2008 12:12 pm
Profile WWW
Regular
User avatar

Joined: Tue Mar 07, 2006 10:32 am
Posts: 347
Location: The Netherlands
Post 
henke37 wrote:
About TAS, why not give people the option to try and run recorded input? Sure, they can't create it since there are no savestates, but bsnes is hardware accurate as far as possible, right?

This idea has crossed my mind before, but there's really not much point without being able to record. (you could record without savestates, but that's not very useful for a good TASer) The reason being that all it would accomplish is casting into doubt the validity of current TASes - despite the fact that it may not even be impossible for such a TAS to work on a SNES simply due to timing fluctuations in its components. bsnes -is- a lot closer to the mean, of course.

creaothceann wrote:
I'm referring to both (WAV recording is a part of video recording). With external programs you get what you hear which can include audible clicks, especially if the PC is not fast enough to do both emulation and recording (maybe with compression) at the same time.

This is a true advantage, though don't forget that bsnes is already forced to resample all sound due to the odd frequency of the SNES. Even if it didn't, I'm not sure you can make a 32040Hz/16-bit wave or play it back correctly, in which case bsnes' resampling is better anyway since it can tell the SMP to produce more samples.. oh, I don't know.


Thu Dec 04, 2008 1:44 pm
Profile
Seen it all
User avatar

Joined: Mon Jan 03, 2005 5:04 pm
Posts: 2302
Location: Germany
Post 
Verdauga Greeneyes wrote:
I'm not sure you can make a 32040Hz/16-bit wave or play it back correctly

You can - the WAV standard specifies the frequency as a 32-bit unsigned number. Playback would be handled by the audio driver.

_________________
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list


Thu Dec 04, 2008 2:29 pm
Profile WWW
Regular
User avatar

Joined: Tue Mar 07, 2006 10:32 am
Posts: 347
Location: The Netherlands
Post 
creaothceann wrote:
You can - the WAV standard specifies the frequency as a 32-bit unsigned number. Playback would be handled by the audio driver.

Fair enough. I guess that just leaves the question whether bsnes' resampling or the audio driver's resampling is the preferred choice.


Thu Dec 04, 2008 2:47 pm
Profile
Hazed

Joined: Tue Jan 16, 2007 5:32 pm
Posts: 54
Post 
Gil_Hamilton wrote:
I thought someone HAD spec'ed a better format, and people just ignored it.

http://snsf.caitsith2.net/

I have tried the snsf's for blackthorne and lost vikings before. I observed that the tempo is too fast on some tracks, and one instrument even misses a part in a lost vikings track. Is the snsf player unfinished?


Thu Dec 04, 2008 6:16 pm
Profile
Buzzkill Gil

Joined: Wed Jan 12, 2005 7:14 pm
Posts: 4231
Post 
Heck if I know.
You'd have to ask Cait Sith about that.


Thu Dec 04, 2008 9:40 pm
Profile
Veteran

Joined: Wed Aug 04, 2004 5:43 pm
Posts: 861
Location: Sloop
Post 
The problem with SNSF is it isn't easy to create. If the game didn't have a sound test, and most don't, you need to be able to hack the rom AND isolate the music from the sound. Conversely, my grandmother could capture an SPC. An archival quality format is interesting, but useless if it doesn't beget an archive. WAV can be recorded with ease, unlike SNSF, but you still have to hack the rom to isolate the music and the filesize is much larger. They all have their drawbacks, but SPC is clearly the best. If a perfect format was possible, it would have been done already.


Fri Dec 05, 2008 1:10 am
Profile
ZSNES Shake Shake Prinny
User avatar

Joined: Wed Jul 28, 2004 4:15 pm
Posts: 5613
Location: PAL50, dood !
Post 
SNSF shouldn't be harder to rip than say, USF. But the main trouble is that SPC is a 'quick and dirty' alternative that's enough for most people, so the new superior format doesn't quite shine as much as it could.

Oh hey, I heard that kind of stuff on another topic some time ago... better stop there. ^^

_________________
皆黙って俺について来い!!
Code:
<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)

Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54


Fri Dec 05, 2008 9:24 pm
Profile
Inmate

Joined: Thu Jan 11, 2007 4:28 am
Posts: 1485
Location: Salem, Oregon
Post 
FitzRoy wrote:
If a perfect format was possible, it would have been done already.


oh really? since when has that been true in application to anything.

_________________
byuu wrote:
Seriously, what kind of asshole makes an old-school 2D emulator that requires a Core 2 to get full speed? >:(


Fri Dec 05, 2008 9:38 pm
Profile WWW
Buzzkill Gil

Joined: Wed Jan 12, 2005 7:14 pm
Posts: 4231
Post 
FitzRoy wrote:
The problem with SNSF is it isn't easy to create. If the game didn't have a sound test, and most don't, you need to be able to hack the rom AND isolate the music from the sound. Conversely, my grandmother could capture an SPC. An archival quality format is interesting, but useless if it doesn't beget an archive.
There's huge archives of NSF, PSF, SID, SAP, and whatever other format that requires hacking capability.


On the other hand, the first out the door usually has the advantage.


Fri Dec 05, 2008 9:52 pm
Profile
Post 
My understanding of SNSF is that the files are basically hacked-up ROMs with as much data as possible trimmed off.

That makes the player emulate both the CPU and SMP, so that they can talk to each other.

I understand the advantage of the approach -- it's more fault-tolerant to timing when you have multiple players. But it adds a ridiculous level of complication to things.

I'd prefer if we perfect the last very minor issues with our current SMP / DSP cores, and move to have one standardized pure C89 library for playing back sound files.

At that point, the files would be SPC+logged read accesses to $f4-$f7. No need for cutting up ROM files, or emulating a 65816, to play back music. And anyone can dump them, just as they can now with SPC files.

But yes, we want it to be as close to perfect as possible before we go making a bunch of dumps that a future revision of the player may break. We're close, though. Cycle-perfect SMP core, mul/div/daa/das and all associated quirks fully supported, DSP that's 99.9% bit-perfect, etc.


Fri Dec 05, 2008 10:55 pm
Zealot
User avatar

Joined: Wed Jul 28, 2004 3:31 am
Posts: 1140
Post 
Logged read accesses would still require hacking in the event of players that stream all of the music data in real-time, at least some way to handle a loop on the log data. That's assuming anything needs to loop the log data for constant music playback.


Fri Dec 05, 2008 11:06 pm
Profile WWW
Post 
Files that need SPC logging could also provide fade-outs. Otherwise, yes, you'd have to hack the SPC file up.


Fri Dec 05, 2008 11:15 pm
Lurker

Joined: Tue Apr 10, 2007 4:30 pm
Posts: 152
Location: Sweden
Post 
I still think that there is a point in supporting prerecorded input.


Sat Dec 06, 2008 12:33 am
Profile WWW
Post 
I believe I've finally got a decent working model for CPU<>PPU sync, with only a minimal compromise.

PPU cannot run ahead of CPU:

We know that many registers can be written mid-scanline and have immediate effects, these include at least the screen and BG enable commands. One can also modify OAM and CGRAM on a per-cycle basis.

CPU cannot ordinarily run ahead of PPU:

The CPU polls the V/H pins of the PPU every clock tick. The states are fairly predictable, but the lengths can change based on interlace and overscan settings.

Extreme 1:

Forcefully sync both processors every single clock tick, causing ~20M context switches a second. Too slow, eats up ~50% of a second just syncing; let alone emulation overhead.

Extreme 2:

Give each core its own completely independent PPU latch counter, forcefully sync whenever interlace and overscan are changed.

Compromise:

Keep only one PPU counter system, a class inside of the PPU itself. Use a tick/tock system and a ring buffer history, like so:

Code:
void CPU::tick() {
  ppu.counter.tick();
  uint16_t v = ppu.counter.vtime();
  uint16_t h = ppu.counter.htime();
}

void PPU::tick() {
  ppu.counter.tock();
  uint16_t v = ppu.counter.vhist();
  uint16_t h = ppu.counter.hhist();
}

//called by CPU
void PPU::Counter::tick() {
  //this will deplete the ring buffer completely ...
  if(ring_buffer.is_full()) scheduler.sync_ppu_up_to_cpu();

  //save current value for the PPU later on ...
  ring_buffer.push(current_vcounter, current_hcounter);

  //here, we use ppu.interlace(), ppu.overscan() and ppu.field()
  //as needed, to properly increment the counter positions by one cycle.
}

//called by PPU
void PPU::Counter::tock() {
  //this will add at least one new entry to the buffer ...
  if(ring_buffer.is_empty()) scheduler.sync_cpu_up_to_ppu();

  //slide our FILO buffer forward by one time position
  ring_buffer.pop();
}

uint16_t PPU::Counter::v,htime() {
  //or to get really hard-core, we could return their blanking states
  //as a boolean, instead. though I see no advantage in doing this ...
  return current_v,hcounter();
}

uint16_t PPU::Counter::v,hhist() {
  return ring_buffer.v,hcounter();
}


Whenever the CPU writes to $[00-3f]:[2100-213f], we call scheduler.sync_ppu_up_to_cpu() so that the PPU will use the new values just-in-time. This would work exactly the same as the current CPU<>SMP sync on writes to $[00-3f]:[2140-217f].

The only big difference is that the PPU cannot run ahead. But, that should not cause any noticeable speed penalty. For each time the PPU syncs to the CPU, the CPU should easily be able to execute at least one full scanline before needing to switch control back to the PPU.

That would drop ~20m context switches to ~(262*60*2) or ~32k switches a second (assuming of course the app doesn't hammer the $21xx registers non-stop. I know of no SNES games that do.)

The nicest part of this approach is that 100% of the PPU counter implementation resides inside of the PPU, rather than having the CPU try and emulate the PPU timing.

So, if in theory, we were to throw a different PPU core in that ran at 640x480, with 525 scanlines per frame, the CPU would need absolutely no adjustments ... even IRQs would work as expected. True modularity that allows eg the bsnes CPU core to be plugged directly into an Apple II GS emulator, if desired.

And there's only one counter. No need to spawn two instances. Since the PPU never goes ahead of the CPU, and the CPU syncs the PPU on writes to the interlace and overscan registers, it's 100% safe to use cached counter values. We never have to worry about an edge case causing the two counters to desync (which would permanently break IRQ timing if they did.)

If we're really lucky, the counter values won't even be needed for an unrolled cycle-based PPU loop, except for the V=240 and V=261->262 or 0. Like how the cycle-based DSP runs in a fixed 32-cycle loop.

I'm thinking it will be best to shoehorn the PPU1 and PPU2 chips into a single class, like I do now. Just instead of having struct regs {}, have struct ppu1 {} and struct ppu2 {}; and clearly denote which chip is doing what for each cycle.

Now to see if I can work out a model to do this same thing with the current scanline-renderer ...

I'd really like to make this the primary target for work in 2009. Enough talk, time to get started on this already.


Wed Dec 10, 2008 7:42 pm
ZSNES Shake Shake Prinny
User avatar

Joined: Wed Jul 28, 2004 4:15 pm
Posts: 5613
Location: PAL50, dood !
Post 
Good approach.

What do you intend to do about the 2 ppus ?

_________________
皆黙って俺について来い!!
Code:
<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)

Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54


Wed Dec 10, 2008 8:53 pm
Profile
Display posts from previous:  Sort by  
This topic is locked, you cannot edit posts or make further replies.   [ 234 posts ]  Go to page Previous  1 ... 6, 7, 8, 9, 10  Next

Who is online

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

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software.