It is currently Wed Sep 19, 2018 4:13 am

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 151 posts ]  Go to page Previous  1 ... 7, 8, 9, 10, 11  Next
Author Message
PostPosted: Tue Aug 14, 2018 4:14 pm 
Offline
User avatar

Joined: Wed Oct 22, 2008 9:27 pm
Posts: 100
creaothceann wrote:
I guess it's a bit more...


Are we even talking about the same thing? 99.9% of unl games work with heuristics. I thought we were talking about mappings that go outside the boundaries of licensed boards.


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

Joined: Thu Oct 26, 2017 12:29 pm
Posts: 52
I want to try and compile this, but I have no idea.
Can someone give me a quick tutorial on makefiles?
As I understand, they only work natively on Linux. For Windows, I need something like CygWin?

_________________
...


Top
 Profile  
 
PostPosted: Tue Aug 14, 2018 6:11 pm 
Offline

Joined: Sat May 09, 2015 7:21 pm
Posts: 86
The procedure for compiling bsnes-mcfly on Windows is a bit involved, and I don't think a beginner should attempt it right away.

For starters, have you ever compiled higan before? You won't need Cygwin; Cygwin is designed to make the POSIX API available for use on Windows, which higan was carefully designed to not need. Instead, you need to use MinGW-w64 (I think it will work on 32-bit Windows as well, but I'm not sure). Make sure that it is in your PATH. If you use an installer, the PATH should be handled automatically for you.

In case you're wondering, the reason why Visual Studio won't work is that it lags behind on support for C++14, which is used heavily by higan and bsnes, and bsnes-mcfly with them.

Once you have MinGW-w64, attempt to compile higan v106 or bsnes v106r57. To do this, navigate into the higan/ directory where there's a file named “GNUmakefile”, then type “mingw32-make”. If you're compiling bsnes, you may need to type “mingw32-make target=bsnes”. If all goes well, you should have higan.exe or bsnes.exe in the higan/out/ directory.

In order to compile bsnes-mcfly, you will additionally need the source code of Qt 5.10.1. When you have that, follow the instructions in bsnes-mcfly's included README.txt file to compile Qt (also available in this post).

================================

Regarding unlicensed game compatibility, I have only this to say:

bsnes-mcfly's new unlicensed boards database will fill in the gaps left behind by byuu's licensed boards database, but only for games that bsnes v073 supported. This includes Bad Apple (ExHiROM without RAM).

It does not include the DSP1 tech demo (malformed header). bsnes v073 was the first version of bsnes to incorporate low-level emulation of the uPD7725 (DSP1, Dungeon Master, SD Gundam GX, Top Gear 3000), so already a cartridge folder would have been required (bsnes v073 did not support concatenated firmware like the upcoming bsnes v107). But even beyond that, the DSP1 tech demo does not have a properly formatted header, so in the absence of a manifest, bsnes v073 and bsnes v072 (the last HLE version) both assume a LoROM without a uPD7725.

Image

I suppose I could force detection of a DSP1 if the firmware is concatenated by taking an SHA256 hash of the last 8192 bytes of the ROM (and therefore allow combination coprocessors such as DSP1+Super FX), but the DSP1 tech demo was not released with a concatenated firmware, so I doubt that would solve anything.

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


Top
 Profile  
 
PostPosted: Fri Aug 17, 2018 1:06 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1388
Quote:
I suppose I could force detection of a DSP1 if the firmware is concatenated by taking an SHA256 hash of the last 8192 bytes of the ROM (and therefore allow combination coprocessors such as DSP1+Super FX)


Clever, but yet another caveat is that ... it's ideal if we're gonna do LLE to allow for uPD7725 code that isn't official DSP1,1B,2,3,4 code. So it could be literally anything there.

You could go off of the file size mask like how I detect it icarus now ... but yeah, the problem is nobody ships the firmware with the games, so it doesn't do anyone any good. For this case, if you really want to support it, I'd probably just add the game's SHA256 sum to an unlicensed database.


Top
 Profile  
 
PostPosted: Mon Aug 20, 2018 6:32 am 
Offline

Joined: Sat May 09, 2015 7:21 pm
Posts: 86
bsnes-mcfly v106r12 has been released. This version is based on bsnes v106r57, but with WASAPI dynamic rate control from the 20180808 meta-WIP (the XAudio2 dynamic rate control was omitted because it is currently broken).

It is now possible to input cheat codes in AAAAAA=DD and AAAAAA=CC?DD formats (A: address, D: data, C: comparison), which are supported by the official bsnes and higan. This is in addition to the older AAAAAADD and AAAAAA:DD formats that bsnes v073 supported, the AAAAAA/DD and AAAAAA/CC/DD formats that higan v092 supported, and the Game Genie format. And because bsnes-mcfly retains whether a cheat code is in Game Genie format and does not convert it to Pro Action Replay format, it can't use the same cheats.bml filename as the official bsnes, at least for cartridge folders.

For now, I'm putting them inside <cartridge-folder>/bsnes-mcfly/cheats.bml, but in the long term, I want to use bsnes's <cartridge-folder>/cheats.bml if and only if every cheat code is compatible with bsnes. If even 1 cheat code is in Game Genie format or uses a colon instead of an equals sign, then the entire cheat file is incompatible with bsnes and needs to use a different path.

Unfortunately, I did not give that same consideration to standalone ROMs. If you assign a separate cheats path, make it different from the cheats path used by Snes9x and the official bsnes if you have those emulators. I hope to fix this in the future. Maybe I'll use the .gg extension if even 1 cheat code is in Game Genie format, and the existing .cht extension if every last one of them is in Pro Action Replay format.

In addition, an unofficial boards database has been added that supplements byuu's official boards database. Currently, its only entry is “EXHIROM”, which refers to ExHiROM without any RAM. This will allow Ladida's Bad Apple tech demo to work as a standalone ROM with no need for a manifest.

As for the DSP1 tech demo, seeing as bsnes v073 did not support it either, I'm not particularly motivated to come up with a way to support it manifest-free. I could register it in an unlicensed games database much like the boards database, but the licensed database includes coprocessor firmwares in its SHA256 hashes, and I will want to do the same for the unlicensed one. And if I do that, I will need to create a shim database for coprocessor games that maps each SHA256 hash without a firmware to a hash with a firmware, and that's going to be rather tedious to do, especially when all the licensed games work with heuristics.

One last thing: the Super Scope and Justifier are now usable with every profile, whereas previously they were usable exclusively in the Accuracy profile and would freak out with the other profiles (this bug also affects the bsnes WIPs). This is because the cursors were optimized for a resolution of 512×480, and if the resolution was 256×240, all your shots would be misaligned. Now, whenever the resolution is 256×240, a 16×16 cursor design is used instead of the 32×32 cursor design in higan and bsnes (in fact, it's the same one from higan v094, except for the color), and the cursor's X and Y coördinates are no longer multiplied by 2. When the resolution is 512×480, the cursor's coördinates are once again multiplied by 2, and the 32×32 design is used. In the cases of 512×240 or 256×480 resolution, the 32×32 cursor design is used (resulting in an oblong shape), but only the X or Y coördinate will be multiplied depending on the resolution.

With that, the list of evil hacks to make bsnes-mcfly more like bsnes v073 are the following:

  • sfc/controller/gamepad/gamepad.cpp: support simultaneous up+down and left+right (enforcing the prohibition of opposing directions is now handled by the GUI instead of the emulator core)
  • sfc/controller/justifier/justifier.cpp: smart cursor alignment/size for Fast PPU
  • sfc/controller/super-multitap/super-multitap.cpp: support simultaneous up+down and left+right
  • sfc/controller/super-scope/super-scope.cpp: smart cursor alignment/size for Fast PPU
  • sfc/dsp/misc.cpp: support muting individual channels (used to be unavailable in the Accuracy profile, but the fact that Compatibility uses the same DSP as Accuracy makes that difficult to enforce)
  • sfc/interface/configuration.cpp: interface for toggling PPU layers and DSP channels carefully designed to not save on exit
  • sfc/ppu-fast/background.cpp: support hiding individual layers in Modes 0-6 (Mode 7 currently not supported)
  • sfc/ppu-fast/io.cpp: support for 128 KB VRAM (can be disabled with a compile-time flag)
  • sfc/ppu-fast/object.cpp: support hiding individual layers
  • sfc/ppu-fast/ppu.cpp: frameskip support, set to 9 when using Fast Forward
  • sfc/system/system.cpp: load cartridge before PPU and DSP so that automatic profile selection can work for Air Strike Patrol without making the expected save state size lag behind 1 game load

EDIT: Including a comparison value doesn't make a cheat incompatible with bsnes v107, what was I thinking? Comparison values were added in higan v092 at the same time as the slash syntax (AAAAAA/CC/DD), and they were made universally available to all emulator cores that support cheats (the ones that have 8-bit data buses, which excludes the Mega Drive and Game Boy Advance), not just the Famicom and Game Boy.

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


Top
 Profile  
 
PostPosted: Wed Aug 22, 2018 7:42 am 
Offline

Joined: Sat May 09, 2015 7:21 pm
Posts: 86
Seeing as bsnes became feature-frozen with v106r57, I have decided that it's time to put bsnes-mcfly on GitLab. You can now see exactly how I went about porting the Qt GUI from each version following v073. It was a long ride, so make sure you have some free time before you go looking.

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


Top
 Profile  
 
PostPosted: Mon Aug 27, 2018 6:59 am 
Offline

Joined: Mon Aug 27, 2018 6:40 am
Posts: 3
Good Morning. Thanks for the emulator and let's get into the problem.

I have msu1 games that run on SD2SNES, Snes9x 1.56.2, bsnes-plus and bsnes-classic, but they do not run on the new version of byuu bsnes 106r44 nor on the bsnes-mcfly 106r12 version. Is there a way to explain what has changed or what should I do to convert the game format? Is the new format incompatible with SD2SNES and Snes9x? Thank you!


Top
 Profile  
 
PostPosted: Mon Aug 27, 2018 7:04 am 
Offline

Joined: Sat May 09, 2015 7:21 pm
Posts: 86
If you have your MSU1 game as a gamepak (cartridge folder), then I should warn you that the format has changed in order to accommodate the Voicer-kun. Now, the MSU1 data track is stored inside the msu1/ subdirectory with the name “data.rom”, and the audio tracks have also been moved into that same subdirectory.

  • game.sfc/
    • msu1/
      • data.rom
      • track-1.pcm
      • track-2.pcm
      • track-3.pcm
      • ...
    • program.rom
    • save.ram

If you have your MSU1 game in SD2SNES format (where every file shares the same name and are differentiated only by extension), then it should work just fine, but I'll check and make sure.

EDIT: Oh, I see what went wrong. For the SD2SNES format, bsnes and bsnes-mcfly mistakenly omit the hyphen-minus from the audio track names, so they expect a game in this format:

  • Secret of Mana.sfc (program ROM)
  • Secret of Mana.srm (save RAM)
  • Secret of Mana.msu (MSU1 data track)
  • Secret of Mana1.pcm (MSU1 audio track 1)
  • Secret of Mana2.pcm (MSU1 audio track 2)
  • Secret of Mana3.pcm (MSU1 audio track 3)
  • ...

Notice how there's no hyphen-minus separating the game name from the track ID? That's what you would need to rename your audio tracks if you want the game to work with bsnes v106r59 or bsnes-mcfly v106r12.

However, I believe this to be a bug, and that the audio track names are officially meant to have hyphen-minuses separating the game name from the audio track ID (because this is what bsnes v073 and the SD2SNES both expect). I'll fix this in the next release of bsnes-mcfly, but byuu needs to be informed of this right away, before he releases bsnes v107.

While I'm at it, I will also mention that bsnes's Super Game Boy support has a bug where an RTC time uses the “.srm” extension instead of “.rtc” like it should be. That means that if you play Pokémon Gold or Pokémon Silver (Pokémon Crystal won't run on the Super Game Boy), your save file will be overwritten by the file meant to keep track of the date and time.

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


Last edited by hex_usr on Mon Aug 27, 2018 7:15 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Mon Aug 27, 2018 7:14 am 
Offline

Joined: Mon Aug 27, 2018 6:40 am
Posts: 3
Code:
manifest.bml
mmx2_msu1-1.pcm
mmx2_msu1-10.pcm
mmx2_msu1-11.pcm
mmx2_msu1-12.pcm
mmx2_msu1-13.pcm
mmx2_msu1-14.pcm
mmx2_msu1-15.pcm
mmx2_msu1-16.pcm
mmx2_msu1-17.pcm
mmx2_msu1-18.pcm
mmx2_msu1-19.pcm
mmx2_msu1-2.pcm
mmx2_msu1-20.pcm
mmx2_msu1-21.pcm
mmx2_msu1-22.pcm
mmx2_msu1-23.pcm
mmx2_msu1-24.pcm
mmx2_msu1-26.pcm
mmx2_msu1-27.pcm
mmx2_msu1-28.pcm
mmx2_msu1-29.pcm
mmx2_msu1-3.pcm
mmx2_msu1-30.pcm
mmx2_msu1-31.pcm
mmx2_msu1-32.pcm
mmx2_msu1-4.pcm
mmx2_msu1-5.pcm
mmx2_msu1-6.pcm
mmx2_msu1-7.pcm
mmx2_msu1-8.pcm
mmx2_msu1-9.pcm
mmx2_msu1.bsz
mmx2_msu1.msu
mmx2_msu1.sfc
mmx2_msu1.xml


This is the list of original files I have. All in one folder.

Do I just need to rename the rom/.sfc and songs/.pcm files, then re-organize into new directories, or I need to convert/create new files? Thank you so much.


Top
 Profile  
 
PostPosted: Mon Aug 27, 2018 7:20 am 
Offline

Joined: Sat May 09, 2015 7:21 pm
Posts: 86
“manifest.bml” “mmx2_msu1.xml”

Oh, shoot! You have a higan v106 and bsnes v073 hybrid manifest! higan/bsnes v107 will be the first version to truly sever all backwards compatibility with bsnes v073 because its manifest format does not allow filename overrides. So unless this ROM hack does something tricky with the memory map, I think you should convert your game to the SD2SNES format. Unless you want to use higan instead of bsnes, which requires cartridge folders.

I don't think you need to create any new files, but you might be able to safely delete manifest.bml and mmx2_msu1.xml, unless that ROM hack makes some elaborate change like adding save RAM to this Cx4-enabled game.

This release came earlier than I expected, but here's bsnes-mcfly v106r13. It is based on higan/bsnes v106r59. This version fixes the MSU1 audio track name bug, so you don't have to rename any files with this version.

If you want to use bsnes v106r59 instead, you'll have to rename mmx2_msu1.sfc to “mmx2_msu1-.sfc” and mmx2_msu1.msu to “mmx2_msu1-.msu”. The reason I want you to rename those 2 files only instead of the audio tracks is so that if and when bsnes fixes the audio track name bug, you can easily revert back to “mmx2_msu1.sfc” and “mmx2_msu1.sfc” without the hassle of renaming every single audio track.

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


Top
 Profile  
 
PostPosted: Mon Aug 27, 2018 8:12 am 
Offline

Joined: Mon Aug 27, 2018 6:40 am
Posts: 3
Thank you so much. I tested here by renaming only 2 files, including the hyphen and made a script to remove the hyphen from the songs, and both methods worked.

Although NOT NECESSARY, I will share the script I did, which may help people with similar problems.

Code:
@echo off
cls
echo.
echo. This code is for BATCH file only!
echo.
SETLOCAL EnableDelayedExpansion
::for %%F in (%cd%\*.pcm) do (
:: For Test
for %%F in (*.pcm) do (
echo.0:%%F
set "_newname=%%F"
set "_newname=!_newname:-=!"
echo.1:!_newname!
)
:: Uncomment For Use
REM for %%F in (*.pcm) do (
REM set "_newname=%%F"
REM set "_newname=!_newname:-=!"
REM ren "%%F" "!_newname!"
REM )
ENDLOCAL
:: The command below renames folders
:: for /D %%D in (%cd%\*) do ren "%%D" "2_ %%~nxD"
:: see: https://ss64.com/nt/for.html
:: see: https://ss64.com/nt/syntax-replace.html
:: see: https://ss64.com/nt/setlocal.html
timeout /nobreak /t 5
exit /b


Anyway, the new version bsnes-mcfly_v106r13 does NOT need any changes, and my msu1 is playing loud! Keep Rocking!

once again, thank you very much, cheers!


Top
 Profile  
 
PostPosted: Mon Aug 27, 2018 2:03 pm 
Offline
User avatar

Joined: Thu Oct 26, 2017 12:29 pm
Posts: 52
This is a Higan general question:

Where can I find the enums used in the "settings.bml" that represent the keyboard-keys/input?
The format is "0x1/0/35". I specifically need the source of the last number.

Thank you.

_________________
...


Top
 Profile  
 
PostPosted: Mon Aug 27, 2018 4:55 pm 
Offline

Joined: Sat May 09, 2015 7:21 pm
Posts: 86
The keyboard IDs vary slightly for each operating system and input driver, so a given ID from one operating system will correspond to a different key on other operating systems. The one constant is that every input driver uses 0 for the Escape key.

For Windows, the keyboard IDs can be found in ruby/input/keyboard/rawinput.cpp. Assuming that 35 is a decimal number, I believe it would be the letter A.

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


Top
 Profile  
 
PostPosted: Sun Sep 02, 2018 7:38 am 
Offline

Joined: Sat May 09, 2015 7:21 pm
Posts: 86
Fair warning: byuu is attempting to add accurate emulation of the SA1's bus conflicts to higan/bsnes. In v106r60, internal code changes have caused a 2% speed hit to the Fast PPU+DSP with bus conflicts disabled when playing non-SA1 games, and a 9% speed hit when playing SA1 games. These same speed hits will also affect bsnes-mcfly's Compatibility profile. The Accuracy profile will also be similarly affected, I'm sure, and if bus conflicts are enabled, the speed hit will be around 51% (I'll leave them disabled for now).

I will make sure the Performance profile does not take a speed hit when merging this change. Although I wish I could remove the Performance profile outright...

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


Top
 Profile  
 
PostPosted: Tue Sep 11, 2018 8:07 am 
Offline

Joined: Sat May 09, 2015 7:21 pm
Posts: 86
bsnes-mcfly v106r14 bsnes-mcfly v106r14b has been released. It is based on higan/bsnes v106r63.

The “bsnes-accuracy.dll” file has been renamed to “bsnes-accuracy-compatibility.dll” to clarify that both the Accuracy and Compatibility profiles are included in the same file. That filename is 32 characters long, so if anyone has a problem getting it to work, tell me and I'll revert the change.

bsnes-mcfly now outputs .cht files that are compatible with bsnes v107 and Snes9x 1.56, so you shouldn't lose your cheats as you switch between emulators. However, in order to maintain feature parity with bsnes v073, bsnes-mcfly needs to remember which cheats are Game Genie cheats and which ones are not, so it outputs an additional cheat file with the .gg extension in order to keep track. In a gamepak (cartridge folder), the bsnes-compatible cheat file is stored in cheats.bml in the root of the folder, while the Game Genie cheat file is stored in bsnes-mcfly/cheats.bml.

One flaw of this method is that, if you change any cheats in bsnes or Snes9x, those changes won't be visible in bsnes-mcfly, and they will be erased when bsnes-mcfly is closed. I'll need to refine this method in the future.

Now, there's something I want to discuss regarding audio:

bsnes v073 did not perform any pitch correction when using Fast Forward. That meant that the audio's pitch would increase with its tempo instead of spending additional CPU time trying to retain the pitch. bsnes-mcfly tries to recreate the effect in order to look and sound like bsnes v073, but it's not perfect. I have to temporarily set the frequency in Emulator::audio to double the normal rate (48000Hz to 96000Hz for example) when using Fast Forward.

But when I do, the XAudio 2.1 driver crashes. I don't know why that is or why the other Windows audio drivers are not also affected, so unfortunately, I need to disable this code when using XAudio 2.1. Furthermore, this makes it impossible to adjust the emulation speed to Slowest, Slow, Fast, or Fastest. The problem is vexing, as this represents a lost bsnes v073 feature when using the XAudio 2.1 driver.

EDIT: Replaced defective v106r14, which would crash for first-time users but not upgrading users, with v106r14b.

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


Last edited by hex_usr on Wed Sep 12, 2018 5:48 pm, edited 1 time in total.

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

All times are UTC - 7 hours


Who is online

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