It is currently Mon Dec 10, 2018 11:49 pm

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 168 posts ]  Go to page Previous  1 ... 6, 7, 8, 9, 10, 11, 12  Next
Author Message
PostPosted: Fri Aug 03, 2018 7:36 am 
Offline

Joined: Sat May 09, 2015 7:21 pm
Posts: 91
bsnes-mcfly v106r11 has been released. This version is based on higan/bsnes v106r52... sort of. nall is based on v106r53 and has a new header that has something to do with SIMD. I don't know exactly what it does, but if you have an Intel Core Haswell or later (I have the ancient Lynnfield), and you compile bsnes-mcfly from source (which requires Qt 5 to be in your PATH), it might influence bsnes-mcfly's performance somehow.

This version, to the best of my knowledge, fixes the crash on exit that 007 and I both experienced. Not deconstructing ruby's drivers was indeed the cause of the crash... and then there was another crash on exit. And another one. And another one! My Qt windows weren't deconstructing their widgets (and menus in the case of the presentation window) properly! So I wrote custom deconstructors to handle that properly, and I replaced every Qt slot with a C++11 lambda. Only 1 file in the entire source still requires moc to compile, and it's a template class for the file loader that defines custom events.

I may have missed a window somewhere, but for now, I'm not getting any crashes on exit anymore. Let me know if you still have a crash on exit. If you do, don't delete your settings this time; they might be crucial in reproducing the crash.

And finally, there was an order of operations issue with saving your configuration settings and deconstructing ruby's drivers, so that's been taken care of.

Aside from crash on exit fixes, this version also makes a slight adjustment to the way frame skipping works in the Compatibility and Performance profiles; previously, a bug meant that instead of skipping frames, it was skipping scanlines. The symptom was that when using fast forward in the Compatibility or Performance profile, sometimes only part of the screen would be updated, divided into horizontal bars. It was most noticeable during fades to black. Now, it skips frames like it's supposed to. Note that the Accuracy profile doesn't have frame skip, so it was not affected.

_________________
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)


Top
 Profile  
 
PostPosted: Fri Aug 03, 2018 12:30 pm 
Offline

Joined: Mon May 02, 2016 5:55 am
Posts: 28
hex_usr wrote:
bsnes-mcfly v106r11 has been released. This version is based on higan/bsnes v106r52... sort of. nall is based on v106r53 and has a new header that has something to do with SIMD. I don't know exactly what it does, but if you have an Intel Core Haswell or later (I have the ancient Lynnfield), and you compile bsnes-mcfly from source (which requires Qt 5 to be in your PATH), it might influence bsnes-mcfly's performance somehow.

This version, to the best of my knowledge, fixes the crash on exit that 007 and I both experienced. Not deconstructing ruby's drivers was indeed the cause of the crash... and then there was another crash on exit. And another one. And another one! My Qt windows weren't deconstructing their widgets (and menus in the case of the presentation window) properly! So I wrote custom deconstructors to handle that properly, and I replaced every Qt slot with a C++11 lambda. Only 1 file in the entire source still requires moc to compile, and it's a template class for the file loader that defines custom events.

I may have missed a window somewhere, but for now, I'm not getting any crashes on exit anymore. Let me know if you still have a crash on exit. If you do, don't delete your settings this time; they might be crucial in reproducing the crash.

And finally, there was an order of operations issue with saving your configuration settings and deconstructing ruby's drivers, so that's been taken care of.

Aside from crash on exit fixes, this version also makes a slight adjustment to the way frame skipping works in the Compatibility and Performance profiles; previously, a bug meant that instead of skipping frames, it was skipping scanlines. The symptom was that when using fast forward in the Compatibility or Performance profile, sometimes only part of the screen would be updated, divided into horizontal bars. It was most noticeable during fades to black. Now, it skips frames like it's supposed to. Note that the Accuracy profile doesn't have frame skip, so it was not affected.


I dont know how to compile this but if you want me to compile on my Haswell and submit/test Im willing to learn.


Thanks for another build.


Top
 Profile  
 
PostPosted: Fri Aug 03, 2018 4:18 pm 
Offline

Joined: Mon May 02, 2016 5:55 am
Posts: 28
@hex_usr

so tested this. cant make it crash anymore. even switching filters. build feels very stable.

I have one suggestion, the description of compatible core states to switch to accuracy for the few problematic games. however the new bsnes core this is has no known problematic games. maybe reword along the lines to switch to accuracy if you believe you found a incompatible game.


Top
 Profile  
 
PostPosted: Fri Aug 03, 2018 4:41 pm 
Offline

Joined: Sat May 09, 2015 7:21 pm
Posts: 91
007 wrote:
I dont know how to compile this but if you want me to compile on my Haswell and submit/test Im willing to learn.

You will need MinGW-w64 and the source code to Qt 5; Visual Studio probably won't work because it has historically been incompatible with the C++14 standard that higan and bsnes use. I use Qt 5.10.1, but bsnes-mcfly has been tested as far back as Qt 5.7.

Once you have extracted both of those, make sure you have the directories “<qt-install-dir>\qtbase” “<qt-install-dir>\qtbase\bin” and “<mingw-install-dir>\bin” in your PATH. If you install MinGW-w64 with an installer, the latter directory should be automatically handled for you.

Then, navigate to where you installed bsnes-mcfly's source code and run cc.bat. I designed cc.bat to run the “pause” command if it detects that compilation failed, so it won't automatically close and prevent you from seeing any important error messages like most batch files do. cc.bat will compile the Accuracy and Compatibility profiles into bsnes\out\bsnes-mcfly.exe, so if you want the Performance profile, you'll have to go into the command prompt and run “mingw32-make profile=performance” from within the bsnes\ directory.

007 wrote:
even switching filters

Crashing on switching filters was an unrelated bug, caused by me being overzealous with optimizations and rendering directly into ruby's video buffer instead of using an intermediate buffer. I think I fixed that already in bsnes-mcfly v106r10, didn't I?

007 wrote:
I have one suggestion, the description of compatible core states to switch to accuracy for the few problematic games.

The “few problematic games” mentioned in that description refer to Air Strike Patrol, which requires the Accuracy profile's PPU in order to draw a shadow under your plane, and Koushien 2 and Rendering Ranger R2, which both require cycle-based DSP timing (the Compatibility profile uses sample-based timing). Go ahead and try to run those games in the Compatibility profile; you'll find that Air Strike Patrol will slow down the emulator to just barely faster than the Accuracy profile, because bsnes-mcfly looks up the internal ROM header's name (“AIR STRIKE PATROL” or “DESERT FIGHTER” for the NTSC-J region) and automatically activates the Accuracy profile's PPU, though it still uses the Compatibility profile's sample-based DSP timing. Similarly, Koushien 2 and Rendering Ranger R2 will automatically activate the cycle-based DSP timing while still using the OpenMP-based PPU in the Compatibility profile. The speed hit will be pretty minor compared to Air Strike Patrol.

Note that the Performance profile does not automatically activate parts of other profiles like this. If you run Air Strike Patrol in the Performance profile, the plane shadow will be invisible.

I could name those games directly in the description, but would that be legally safe? Could Nintendo or SETA find a reason to sue me for mentioning which games won't work with certain features? I already have a tooltip for the Double VRAM option that mentions that Yoshi's Island will look like a garbled mess with 128 KB VRAM (hover your mouse cursor over the checkbox to see it), and I'm a little iffy on that, too.

EDIT: Corrected the PATH for Qt.

EDIT 2: Whoops, forgot that I disabled automatic profile switching because of a crashing bug.

_________________
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)


Last edited by hex_usr on Mon Aug 06, 2018 4:10 am, edited 2 times in total.

Top
 Profile  
 
PostPosted: Fri Aug 03, 2018 7:14 pm 
Offline

Joined: Mon May 02, 2016 5:55 am
Posts: 28
@hex_usr

am going to try and compile now.

I re read the descriptions makes sense to leave as is.

Ill come back on with what I compile. Using i5-4570.


Top
 Profile  
 
PostPosted: Fri Aug 03, 2018 7:47 pm 
Offline

Joined: Mon May 02, 2016 5:55 am
Posts: 28
having trouble. Will try again.

Ill figure it out.

https://drive.google.com/file/d/1FHLrjy ... sp=sharing


Top
 Profile  
 
PostPosted: Sat Aug 04, 2018 4:11 am 
Offline

Joined: Sat May 09, 2015 7:21 pm
Posts: 91
Oops, I knew I forgot something. I had hoped that you could just use the precompiled Qt DLLs that I included in the ZIP download, and maybe that's technically true, but you still need to have moc (Qt's meta object compiler) and rcc (Qt's resource compiler) in order to compile bsnes-mcfly. And in order to get those, you'll need to compile Qt yourself.

And the PATH isn't supposed to point to “<qt-install-dir>\qtbase”, it's supposed to point to “<qt-install-dir>\qtbase\bin” instead. Sorry about that.

Did you read the included README.txt by any chance? I included directions for compiling Qt in there. I'll include the relevant section below:

If you wish to compile Qt yourself on Windows, you will need MinGW-w64 SEH.
TDM-GCC has not been updated since 2015 and will not work.

Open qtbase/mkspecs/win32-g++/qmake.conf and change the following properties:
Code:
QMAKE_LINK   = $${CROSS_COMPILE}g++ -static-libgcc -static-libstdc++
QMAKE_LINK_C = $${CROSS_COMPILE}gcc -static-libgcc -static-libstdc++


Navigate to Qt's root directory and run the following command with no line breaks:
Code:
configure -prefix %CD%\qtbase -release -opensource -confirm-license -nomake tests -nomake examples -no-opengl -no-zlib -skip qt3d -skip activeqt -skip qtandroidextras -skip qtcanvas3d -skip qtcharts -skip qtconnectivity -skip qtdatavis3d -skip qtgamepad -skip qtlocation -skip qtmacextras -skip qtnetworkauth -skip qtpurchasing -skip qtserialbus -skip qtspeech -skip qtwebglplugin -skip qtx11extras

Navigate to qtbase/ and run “mingw32-make”. This can take a while. You can optionally add a “-j#” option, where # is the number of simultaneous compilation jobs. The number of CPU cores you have minus 1 is a good number.

When it is done, you will find some DLLs in the directory where you installed Qt's source. Here's where each one needs to be copied:
  • qtbase/lib/Qt5Core.dll → <bsnes-mcfly>/
  • qtbase/lib/Qt5Gui.dll → <bsnes-mcfly>/
  • qtbase/lib/Qt5Widgets.dll → <bsnes-mcfly>/
  • qtbase/plugins/platforms/qwindows.dll → <bsnes-mcfly>/platforms/
  • qtbase/plugins/styles/qwindowsvistastyle.dll → <bsnes-mcfly>/styles/

If you need to recompile Qt, run “mingw32-make distclean -j#” first. (substitute # with the number of simultaneous jobs)

_________________
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)


Top
 Profile  
 
PostPosted: Mon Aug 06, 2018 4:26 am 
Offline

Joined: Sat May 09, 2015 7:21 pm
Posts: 91
hex_usr wrote:
Go ahead and try to run those games in the Compatibility profile; you'll find that Air Strike Patrol will slow down the emulator to just barely faster than the Accuracy profile, because bsnes-mcfly looks up the internal ROM header's name (“AIR STRIKE PATROL” or “DESERT FIGHTER” for the NTSC-J region) and automatically activates the Accuracy profile's PPU, though it still uses the Compatibility profile's sample-based DSP timing. Similarly, Koushien 2 and Rendering Ranger R2 will automatically activate the cycle-based DSP timing while still using the OpenMP-based PPU in the Compatibility profile. The speed hit will be pretty minor compared to Air Strike Patrol.

Oops, I forgot... I disabled automatic profile switching because of a crashing bug. When enabled, if you load a game in the Accuracy profile, and then load the same game again in the Compatibility profile without a full restart first, bsnes-mcfly will crash.

This bug affects the official bsnes as well (using the Fast PPU checkbox), and it even affects the latest v106r56 WIP release. I know byuu previously attempted a fix to work around the 1-game lag in calculating the save state size, but I guess it doesn't work as expected.

The PPU and DSP are selected within SuperFamicom::System::load(), and serializeInit() is also called within the same function. But in bsnes, hackCompatibility() is called after emulator->load() has already been called... which means that it doesn't even have the intended effect and will run Air Strike Patrol with no visible shadow.

I had a fix for the save state size's 1-game lag, but I dropped it because I thought byuu's fix would work. This was what I used:

sfc/system/system.cpp
Code:
auto System::load(Emulator::Interface* interface) -> bool {
  //...
  bus.reset();
  if(!cartridge.load()) return false;

  hacks.fastPPU = settings.fastPPU;
  hacks.fastDSP = settings.fastDSP;

  if(!cpu.load(system)) return false;
  if(!smp.load(system)) return false;
  if(!ppu.load(system)) return false;
  if(!dsp.load(system)) return false;
  //...
  serializeInit();
  this->interface = interface;
  return information.loaded = true;
}

I loaded the cartridge first. This was required in order to read the ROM header. Then I set the hack settings, and loaded the PPU and DSP afterwards.

...but even that doesn't fix this crash bug now. And GDB doesn't help, it just says that the crash happened in a Windows DLL.

_________________
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)


Top
 Profile  
 
PostPosted: Tue Aug 07, 2018 4:24 am 
Offline

Joined: Thu Jul 24, 2008 3:23 pm
Posts: 13
Location: Moscow, Russia
I would enjoy being able to load things like the DSP-1 tech demo and Bad Apple demo by Ladida from plain .sfc files. If it's not too difficult to implement in bsnes-mcfly, that is.


Top
 Profile  
 
PostPosted: Tue Aug 07, 2018 5:41 am 
Offline

Joined: Sat May 09, 2015 7:21 pm
Posts: 91
If the ROM header is not properly formatted, bsnes-mcfly won't be able to figure out that a DSP1 is required. The same is true of the official bsnes, and when importing the ROM in icarus for use in higan. You will need to either supply a manifest, or edit the ROM in a hex editor.

If you choose to supply a manifest, place the manifest in the same directory as the ROM and name it the same as the ROM but with the “.bml” extension. Here's the manifest:
Code:
game
  sha256:   42ff54a03c2c8f42daa1d4e342464abde303df4e90dcf17173f36ec01702e887
  label:    DSP1 Prototype
  name:     DSP1 Prototype
  //serial:   SN-10
  region:   NTSC
  revision: 1.0
  //board:    SHVC-2Q5B-03
  board:    NEC-LOROM
    memory
      type: ROM
      size: 0x20000
      content: Program
    memory
      type: ROM
      size: 0x1800
      content: Program
      manufacturer: NEC
      architecture: uPD7725
      identifier: DSP1
    memory
      type: ROM
      size: 0x800
      content: Data
      manufacturer: NEC
      architecture: uPD7725
      identifier: DSP1
    memory
      type: RAM
      size: 0x200
      content: Data
      manufacturer: NEC
      architecture: uPD7725
      identifier: DSP1
      volatile


If you choose the hex editor route, you will need to go to $7FB0, and overwrite the 48 bytes of FF that you find there with the following:
Code:
30 30 44 53 50 31 00 00 00 00 00 00 00 00 00 00
44 53 50 31 20 50 72 6F 74 6F 74 79 70 65 20 20
20 20 20 20 20 20 03 07 00 0E 33 00 12 07 ED F8

Also, I don't think I need to say this, but make sure you have the DSP1 firmware in little endian format. The preferred form is to concatenate the firmware directly to the end of the ROM that uses it, but you can also put it in the firmware/ directory where bsnes-mcfly is installed. Even though the performance profile has high-level emulation of the DSP1, it requires the firmware in order to validate the DSP program. I made it that way in order to not relieve any pressure on No-Intro to bundle the firmwares with the ROMs that use them.

As for Bad Apple, bsnes-mcfly does recognize that the ROM is an ExHiROM, but unfortunately, the Board database that is borrowed from higan does not define a board for ExHiROM without any cartridge RAM (both Tales of Phantasia and Daikaijuu Monogatari II have cartridge RAM), so Bad Apple won't work without a manifest, or unless you edit the header to indicate the presence of cartridge RAM. For the latter, change byte $40FFD8 from 0x00 to 0x05.

You could ask byuu to add an entry to the Boards database for ExHiROM without RAM, but because no commercial game was ever released using it, I doubt he will agree to add it for you.

_________________
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)


Top
 Profile  
 
PostPosted: Tue Aug 07, 2018 8:59 am 
Offline
User avatar

Joined: Mon Jan 23, 2006 7:47 am
Posts: 145
ROM hacks / PD ROMs are exactly what manifest support was created for (ROMs shouldn't have to be edited to make them work in certain emulators).


Top
 Profile  
 
PostPosted: Tue Aug 07, 2018 5:05 pm 
Offline

Joined: Sat May 09, 2015 7:21 pm
Posts: 91
angrylion asked about loading both games as “plain .sfc files”. I just provided an option that would avoid creating manifests, because those are primarily associated with cartridge folders, and I can't assume that angrylion has no opposition to placing a manifest right next to the ROM, even if it technically doesn't need to be in a .sfc folder.

...oh, but Bad Apple works in bsnes v073 without a manifest, doesn't it? Dang, I don't really like the idea, but I did say that I would “take any legal means to replace bsnes v073”, so...

I will create a supplemental boards database in order to fill in the gaps that byuu has left in his boards database. Its first entry will be “EXHIROM” without a “-RAM” suffix, so that Bad Apple will work without the need to edit the ROM or supply a manifest. Unfortunately, there is no way to also support the DSP1 prototype in the same way. Even if the firmware is concatenated, it's either supply a manifest, or edit the ROM. I don't think bsnes v073 supports it manfest-free either (although bsnes v072 and earlier have high-level emulation, bsnes-classic was not forked from those versions), so I shouldn't have to worry about that one, at least.

Annoying reminder: bsnes-mcfly tries to compete with bsnes v073 and bsnes-classic. It does not try to compete with the official bsnes v107. If you are satisfied with bsnes v107, I recommend that you continue to use it so that you don't have to suffer the bug's nest that is Qt.

_________________
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)


Top
 Profile  
 
PostPosted: Sat Aug 11, 2018 7:11 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1391
angrylion wrote:
I would enjoy being able to load things like the DSP-1 tech demo and Bad Apple demo by Ladida from plain .sfc files. If it's not too difficult to implement in bsnes-mcfly, that is.


Do you really expect us to maintain databases of mappings for every quirky unlicensed game out there?

Frankly, it's severely pushing it that I'm even including one for the Tengai Makyou Zero fan translation and Powerfest '94 / Campus Challenge '92.

Quote:
ROM hacks / PD ROMs are exactly what manifest support was created for (ROMs shouldn't have to be edited to make them work in certain emulators).


I just really wish we could have created a standard that wouldn't be subject to constant change.

But even if it were set in stone, it's not a standard if only my emulator supports it.


Top
 Profile  
 
PostPosted: Tue Aug 14, 2018 2:45 am 
Offline
User avatar

Joined: Wed Oct 22, 2008 9:27 pm
Posts: 101
byuu wrote:
Do you really expect us to maintain databases of mappings for every quirky unlicensed game out there?


How many are there, like 20? The NES is the only system that has a lot of this.

So on one hand, we have a 20-entry unl db. On the other, we have fights and drama and regret and confusion over legacy formats and their tendency to persist, as featured in this thread.


Top
 Profile  
 
PostPosted: Tue Aug 14, 2018 3:15 pm 
Offline
User avatar

Joined: Mon Jan 23, 2006 7:47 am
Posts: 145
FitzRoy wrote:
How many are there, like 20?

I'd guess it's a bit more...


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 168 posts ]  Go to page Previous  1 ... 6, 7, 8, 9, 10, 11, 12  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


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