bsnes-mcfly: The v073 and bsnes-classic killer

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
007
Posts: 89
Joined: Mon May 02, 2016 5:55 am

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by 007 »

hex_usr wrote:I think there are some fullscreen config options already, aren't there? You will have to use keyboard shortcuts though, especially if you use Direct3D's exclusive mode.

By default, pressing Shift+6 (not the keypad, the horizontal number key) will set either square pixels or 8:7 rectangular pixels* depending on whether you have Correct Aspect Ratio turned on. Either way, this leaves black bars on the left and right sides of the screen. I don't mind the black bars at all, but I heard they really bother a few users, so...

Pressing Shift+7 will completely ignore the console's native pixel aspect ratio and horizontally stretch the emulated screen to fill the entire monitor. I find this horizontal stretching to be really ugly, but it does cover up the black bars if that's what you truly want.

Pressing Shift+8 will chop off parts of the top and bottom to minimize horizontal stretching while still filling the entire screen. Depending on the game, this could chop off important info. In Super Mario World, the HUD is still visible, but a small portion of the top is cut off.

You can also press Shift+1, Shift+2, Shift+3, Shift+4, or Shift+5 to set the resolution to 256×239, 512×478, 768×717, 1024×956, or 1280×1195 respectively. Depending on your monitor, not only will this create black bars on the left and right sides, it also creates them on the top and bottom as well.

*Important note: 8:7 is the pixel aspect ratio of the SNES, or the ratio of a single pixel's width to its height. The overall display aspect ratio is 64:49 when displaying 224 scanlines and 2048:1673 when displaying 239 scanlines. The display aspect ratio of the NES (240 scanlines) is 128:105.

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

As for Mega Man X2 not loading the first time and loading the second time instead (yes, I saw your pre-edit post): I cannot reproduce this bug, and it sounds like the other computers you tried cannot reproduce it either? In the current development version on my computer, I made a slight change to the load/unload program code to cover up a possible source of bugs, which will appear in bsnes-mcfly v106r06. If it does come up again, be sure to check the firmware/ folder and make sure that cx4.data.rom is intact.

However, the preferred form is to concatenate this firmware directly to the game ROM and make a 1,575,936 byte ROM that still works in ZSNES and Snes9x. If you do that, bsnes-mcfly (and bsnes v107) will ignore the firmware/ folder and use the concatenated ROM instead, which is currently the only way to use a custom firmware if one gets created in the future. byuu has been pushing for concatenated firmware for many years now, yet No-Intro has strongly opposed it for fear of not being able to distinguish where the main program ROM ends and where the firmware begins. Something that icarus proves is a piece of cake, no harder than detecting copier headers.
Thanks for the info on the shortcuts.

Im really not sure what was causing my mega man x2 issue. It was only happening on a specific system which drove me mad. I have since formatted and reinstalled windows and fresh drivers system needed it anyway. Can no longer produce that problem.

I currently am not using concatenate roms. But I have the proper verified by crc files in the firmware folder.


Been playing with this emulator alot since discovering it. No issues. On my media center I run the accuracy core however I tried the other 2 modes as well.

I am really really liking bsnes-mcfly thank you for this.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by tepples »

To address No-Intro's concerns: Are there any licensed Super NES ROMs that aren't a power of two bytes in size, 3/4 of a power of two, or 5/8 of a power of two? As far as I'm aware, these are the only sizes for which the internal header checksum algorithm is well defined.
hex_usr
Posts: 92
Joined: Sat May 09, 2015 7:21 pm

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by hex_usr »

I don't think any licensed SNES games not matching those sizes exist.

The most common firmware (DSP1) is 8192 bytes long, the largest firmware (ST018) is 163,840 bytes long, the smallest firmware (Super Game Boy boot ROM) is 256 bytes long, and the second-smallest firmware (Cx4) is 3072 bytes long. No firmware is exactly the same size as the copier header (512 bytes). All the same, I think it would be best to not consider a ROM that has both a copier header and a coprocessor firmware to be valid. It is best to treat them as mutually exclusive, and if a ROM has both a copier header and a coprocessor firmware, the emulator should reject it.

I will note that, for byuu's preservation database, byuu will check the last 256 kilobytes (2 megabits) of a ROM and chop off the last 128 kilobytes (1 megabit) if they match the preceding 128 kilobytes exactly. Spectre, for example, is 1 megabyte long, but it can be truncated to 896 kilobytes and then mirrored back to 1 megabyte to produce exactly the same ROM. It is the 896-kilobyte version that byuu catalogues. He does this in order to guard against cartridges that, for example, store 4 megabytes when only 3 megabytes are needed. Spectre has no coprocessor, and certainly none with firmware. I don't think any of the firmware games fit this criterion though.
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by lidnariq »

hex_usr wrote:*Important note: 8:7 is the pixel aspect ratio of the SNES, or the ratio of a single pixel's width to its height.
Vaguely off-topic: Do you handle PAL PAR also?
hex_usr
Posts: 92
Joined: Sat May 09, 2015 7:21 pm

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by hex_usr »

Yes, actually; the PAL pixel aspect ratio is 2,950,000:2,128,137, or approximately 11:8. You'll need to press Shift+P to activate it, and Shift+N to switch back to the NTSC aspect ratio; bsnes v073 did not automatically select the aspect ratio based on the cartridge region, so neither does bsnes-mcfly.
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)
007
Posts: 89
Joined: Mon May 02, 2016 5:55 am

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by 007 »

hex_usr wrote:Yes, actually; the PAL pixel aspect ratio is 2,950,000:2,128,137, or approximately 11:8. You'll need to press Shift+P to activate it, and Shift+N to switch back to the NTSC aspect ratio; bsnes v073 did not automatically select the aspect ratio based on the cartridge region, so neither does bsnes-mcfly.
Would it be possible to include a readme with the next release that lists all the shortcuts and stuff?

Useful for those of us that dont know bsnes well.
hex_usr
Posts: 92
Joined: Sat May 09, 2015 7:21 pm

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by hex_usr »

All of the keyboard shortcuts in bsnes-mcfly are customizable. Open the Configuration Settings window and select the Input tab to see which hotkeys are available, and configure them as you please. Unfortunately, Windows users will not be able to use the Pause/Break key.

Some very basic documentation is available by selecting Help/Documentation..., but it does not list any hotkeys. I'd like to build on that documentation in the future.
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)
007
Posts: 89
Joined: Mon May 02, 2016 5:55 am

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by 007 »

hex_usr wrote:All of the keyboard shortcuts in bsnes-mcfly are customizable. Open the Configuration Settings window and select the Input tab to see which hotkeys are available, and configure them as you please. Unfortunately, Windows users will not be able to use the Pause/Break key.

Some very basic documentation is available by selecting Help/Documentation..., but it does not list any hotkeys. I'd like to build on that documentation in the future.

ok nice thanks.

back to my original topic can you add ability to define screen resolution?

Let say I leave my media center at 4k desktop res but want bsnes to use lets say 640 x 480 x 32bit

snes9x does what i mean so does mednafen even when using bsnes core.

Im not neaning resolution of render i am meaning define pc screen res mode.
hex_usr
Posts: 92
Joined: Sat May 09, 2015 7:21 pm

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by hex_usr »

Oh, that's what you meant? To shrink the PC resolution down instead of stretching the SNES image up?

I don't think that will be easy. I deliberately designed bsnes-mcfly to use as much of byuu's code as possible by converting the Qt-based UI for compatibility with the most current higan/bsnes version instead of having it stagnate at v073 for all time. Unlike some people.

Which means that bsnes-mcfly includes nall (general header library) and ruby (video/audio/input abstraction layer) as dependencies, completely unchanged from the equivalent higan version. To implement your feature request, I would have to modify ruby, and I have deliberately prohibited myself from modifying these dependencies in any way.

You should ask byuu if he will implement this feature in his upcoming bsnes revival. I don't know if he will agree or not, but if he does, I will be able to pull in any changes he makes to ruby in order to add the feature to bsnes-mcfly.
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)
007
Posts: 89
Joined: Mon May 02, 2016 5:55 am

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by 007 »

hex_usr wrote:Oh, that's what you meant? To shrink the PC resolution down instead of stretching the SNES image up?

I don't think that will be easy. I deliberately designed bsnes-mcfly to use as much of byuu's code as possible by converting the Qt-based UI for compatibility with the most current higan/bsnes version instead of having it stagnate at v073 for all time. Unlike some people.

Which means that bsnes-mcfly includes nall (general header library) and ruby (video/audio/input abstraction layer) as dependencies, completely unchanged from the equivalent higan version. To implement your feature request, I would have to modify ruby, and I have deliberately prohibited myself from modifying these dependencies in any way.

You should ask byuu if he will implement this feature in his upcoming bsnes revival. I don't know if he will agree or not, but if he does, I will be able to pull in any changes he makes to ruby in order to add the feature to bsnes-mcfly.
Yes exactly what I mean. This allows the computer to have less overhead in emulating.

if desktop = 3840 x 2160 and emulator runs at same it will take so much power however if user can define launch in a lower system resolution it will take less power for same emulation. bsnes/higan being very power hungry would benefit greatly from this.

easy test run bsnes with pc set to highest resolution you and and try at lowest resolution you can.

This very purpose is why most emulators are written to allow this change.

I imagine byuu will eventually see this post. I believe he is currently on vacation in Japan.

I thought you could implement the resolution swap at gui level. I fully understand not wanting to alter the higan code and agree with that thought.
007
Posts: 89
Joined: Mon May 02, 2016 5:55 am

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by 007 »

oh and also thanks for bsnes-mcfly :)
creaothceann
Posts: 611
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by creaothceann »

Stretching the SNES resolution to a higher one is usually not done by the CPU but by the graphics card, which shouldn't have any problem with that (unless it's a cheap one from the 90's).
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
007
Posts: 89
Joined: Mon May 02, 2016 5:55 am

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by 007 »

creaothceann wrote:Stretching the SNES resolution to a higher one is usually not done by the CPU but by the graphics card, which shouldn't have any problem with that (unless it's a cheap one from the 90's).

The system I did my tests on was with an i5-4570 cpu and Nvidia GTX 1050 (and yes I consider it low end but hi end enough to emulate snes)


Not high end, not exactly SHIT.

Monitoring resources I see a difference. Also directly related this effects operating temp.


Instead of putting a pointless comment do some testing.


Hopefully your reply wasn't typed on a $299 Walmart AMD powered laptop.
hex_usr
Posts: 92
Joined: Sat May 09, 2015 7:21 pm

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by hex_usr »

007, what profile do you use?

I managed to reproduce that bug that prevents Mega Man X2 from running the first time and requires reloading the game in order to work. It happens regardless of whether the Cx4 firmware is concatenated directly to the program ROM or read from the firmware/ directory. But I could only get the bug to happen with the performance profile. With the accuracy and compatibility profiles, Mega Man X2 loads the first time, all the time.

The only reason I found this bug when I did is that I usually don't use the performance profile (I use the compatibility profile for general gaming), but I had it active in order to test some massive code changes in the PPU and SMP that should increase speed without harming what little accuracy is left (if I did it right). I haven't narrowed down the cause of the bug yet though.
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)
007
Posts: 89
Joined: Mon May 02, 2016 5:55 am

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by 007 »

hex_usr wrote:007, what profile do you use?

I managed to reproduce that bug that prevents Mega Man X2 from running the first time and requires reloading the game in order to work. It happens regardless of whether the Cx4 firmware is concatenated directly to the program ROM or read from the firmware/ directory. But I could only get the bug to happen with the performance profile. With the accuracy and compatibility profiles, Mega Man X2 loads the first time, all the time.

The only reason I found this bug when I did is that I usually don't use the performance profile (I use the compatibility profile for general gaming), but I had it active in order to test some massive code changes in the PPU and SMP that should increase speed without harming what little accuracy is left (if I did it right). I haven't narrowed down the cause of the bug yet though.

I been using accuracy profile. Explains why the problem vanished lol.

Just tested and you are correct in performance profile problem is there always and in the other 2 profiles its not.

When I first bumped into the problem I would of been in performance mode.

I was doing my own little test I was comparing your performance profile vs the new bsnes that byuu is working on seeing if one required more power than the other.
Post Reply