bsnes v0.036 released

Archived bsnes development news, feature requests and bug reports. Forum is now located at http://board.byuu.org/
Locked
wertigon
Rookie
Posts: 46
Joined: Sat Aug 07, 2004 7:20 pm

Post by wertigon »

I think Byuu isn't working with the MAME-crowd since they're not developing SNES stuff, simple as that.

And who said that collaboration between projects were bad? There are a few arcade games that uses the ST018 chips or so I've been told. Byuu wants ST018 support, MAME wants ST018 support, why not collaborate on a common goal then? It's not exactly as if bsnes and MAME are sworn enemies and will fight to the death over who is the better emulator...
ShadowFX
Regular
Posts: 265
Joined: Thu Jul 29, 2004 8:55 am
Location: The Netherlands

Post by ShadowFX »

Nicely said, I agree fully.
"Change is inevitable; progress is optional"
byuu

Post by byuu »

So, the issue with the cycle-based PPU was that I couldn't find a good way to allow the current sCPU core to utilize both models, due to the tight enslavement it uses on the current bPPU core. I also really didn't want to maintain two CPU cores ...

... but today, I came up with something rather obvious, that I think warrants more investigation: what if I convert sCPU to an abstract base class, that emulates all opcodes, memory management, H/DMA operations and MMIO registers; and has virtual functions to invoke the timing portion, which is filled in by two derived classes? One that cycle-steps back-and-forth with the new sPPU, and one that enslaves the old bPPU.

The timing core would consist of add_clocks(), scanline(), frame() and poll_interrupts() [IRQ + NMI testing]. The virtual overhead would be eliminated by compiling with the final derived class only. Eg a compile-time switch.

Really, that should be the only thing that needs to be separated. I'll just use some evil friend class tricks and have the one CPU timing core directly manipulate the scanline-renderer's counters directly.

After that point, we can consider maybe moving the scanline-CPU timing module back to range-tested IRQs. Yeah, it'll break F1 Grand Prix and Sink or Swim ... but we'd gain back a ~40% speedup. Who knows, maybe that can be fixed by someone in the future, too. Add in potential PGO support again in the future, and it should make bsnes relatively competitive with ZSNES v2; while still giving me a playground to focus only on accuracy above all else.

And I can finally get started on this, instead of complaining about it all the time :D

What I would need to do first, is clean up the sCPU as much as possible. I'd want it to be 100% clean before attempting an inheritance model. The biggest hurdle would be killing off the custom macro translator for the opcodes. And then I'd want to clean up and unify all of the variable structs for state information, that way all the timing-critical stuff can be moved to the individual timing cores.
Verdauga Greeneyes
Regular
Posts: 347
Joined: Tue Mar 07, 2006 10:32 am
Location: The Netherlands

Post by Verdauga Greeneyes »

First of all, your idea sounds pretty solid - good luck cleaning up your code, that sounds like a lot of work. It's great to finally see some progress on this front again.

I don't know if I'm particularly coherent today (didn't get much sleep), but here's an attempt at clarifying my code from the last page.

Code: Select all

scalar = min(viewheight / height, viewwidth / width);
width  = width  * scalar;
height = height * scalar;

is equivalent to the following:

if(viewheight / height < viewwidth / width)
{ width  = width  * viewheight / height;
         < width  * viewwidth  / width;
         < viewwidth;

  height = height * viewheight / height;
         = viewheight;
}else
if(viewheight / height > viewwidth / width)
{ width  = width  * viewwidth  / width;
         = viewwidth;
 
  height = height * viewwidth  / width;
         < height * viewheight / height;
         < viewheight;
}else
{ width  = width  * viewwidth  / width;
         = viewwidth;

  height = height * viewheight / height;
         = viewheight;
}

or

if(viewheight / height < viewwidth / width)
{ width  = viewheight * width / height;
  height = viewheight;
}else
if(viewheight / height > viewwidth / width)
{ width  = viewwidth;
  height = viewwidth * height / width;
}else
{ width  = viewwidth;
  height = viewheight;
}


In the case of portrait mode, the image width is likely to exceed the width of the screen, in which case viewheight / height > viewwidth / width ... in this case width is made equal to the screen width, and the height is reduced accordingly.
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

byuu wrote:After that point, we can consider maybe moving the scanline-CPU timing module back to range-tested IRQs. Yeah, it'll break F1 Grand Prix and Sink or Swim ... but we'd gain back a ~40% speedup. Who knows, maybe that can be fixed by someone in the future, too.


Numerous timing errors existed then with DMA, HDMA, and NMI that have since been fixed. Results might be different today. Add Battle Blaze, Robocop vs Terminator, and R-Type III to your list.
tetsuo55
Regular
Posts: 307
Joined: Sat Mar 04, 2006 3:17 pm

Post by tetsuo55 »

FitzRoy wrote:
byuu wrote:After that point, we can consider maybe moving the scanline-CPU timing module back to range-tested IRQs. Yeah, it'll break F1 Grand Prix and Sink or Swim ... but we'd gain back a ~40% speedup. Who knows, maybe that can be fixed by someone in the future, too.


Numerous timing errors existed then with DMA, HDMA, and NMI that have since been fixed. Results might be different today. Add Battle Blaze, Robocop vs Terminator, and R-Type III to your list.


I agree, big chance that all the fixes you did fixed them anyway.
Suissant

Post by Suissant »

FitzRoy wrote:If it was, I wouldn't have suggested it. You're talking about keeping three sliders nobody needs, hiding mode settings, hiding the aspect ratio, completely separate aspect ratio settings in advanced that uses fractions, and anyone who wants non-integer scaling in widowed mode can't. That's limiting useful options, complicated, and uninformative. So it takes you 1 minute to find a height scale that fills your fullscreen mode, and you're done forever. Big deal.


just posting to say that I as a average joe who only wants to play a game in the emulator, completely agree with this guy. first: I want an easy way to manipulate the aspect ratio and I want an option to play only in fullscreen instead of pressing f11.
byuu

Post by byuu »

The aspect ratio can be manipulated via Settings->Video Mode->Correct Aspect Ratio. Don't know how that could be any simpler. Can't imagine anyone out there not happy with 1:1 or auto 4:3 correction ...

I don't want to allow the emulator to start in fullscreen mode, especially not with the menubar and such off by default. Could confuse people. Easy enough to hit F11 after starting it ...

I usually lock these posts when releasing a new version, sorry about that. Please feel free to continue this conversation in the v037 thread.
Locked