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.  [ 283 posts ]  Go to page Previous  1 ... 8, 9, 10, 11, 12
bsnes v0.036 released 
Author Message
Rookie

Joined: Sat Aug 07, 2004 7:20 pm
Posts: 46
Post 
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...


Tue Oct 21, 2008 11:24 pm
Profile
Regular
User avatar

Joined: Thu Jul 29, 2004 8:55 am
Posts: 265
Location: The Netherlands
Post 
Nicely said, I agree fully.

_________________
"Change is inevitable; progress is optional"


Wed Oct 22, 2008 10:27 am
Profile
Post 
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.


Thu Oct 23, 2008 12:45 am
Regular
User avatar

Joined: Tue Mar 07, 2006 10:32 am
Posts: 347
Location: The Netherlands
Post 
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:
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.


Thu Oct 23, 2008 10:50 am
Profile
Veteran

Joined: Wed Aug 04, 2004 5:43 pm
Posts: 861
Location: Sloop
Post 
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.


Thu Oct 23, 2008 1:50 pm
Profile
Regular

Joined: Sat Mar 04, 2006 3:17 pm
Posts: 307
Post 
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.


Thu Oct 23, 2008 8:08 pm
Profile
Post 
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.


Sun Oct 26, 2008 5:54 am
Post 
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.


Sun Oct 26, 2008 10:43 am
Display posts from previous:  Sort by  
This topic is locked, you cannot edit posts or make further replies.   [ 283 posts ]  Go to page Previous  1 ... 8, 9, 10, 11, 12

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.