It is currently Sat Aug 19, 2017 9:55 am

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 171 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7, 8 ... 12  Next
Author Message
PostPosted: Sat Nov 14, 2015 8:22 pm 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 318
Location: FL
64-bit builds (including accuracy) are now available in the OP.

Image

Going forward I'll probably keep publishing both 64 and 32-bit builds (but most likely only 64-bit for accuracy).


Top
 Profile  
 
PostPosted: Mon Nov 16, 2015 1:13 pm 
Offline

Joined: Thu Feb 26, 2015 2:37 am
Posts: 38
Yah for 64-bit for accuracy!!

Does anyone know if BSNES-Classic has a 64-bit for accuracy build now as well?


Top
 Profile  
 
PostPosted: Tue Nov 17, 2015 3:40 pm 
Offline

Joined: Mon Nov 10, 2008 3:09 pm
Posts: 413
If you're using bsnes-plus for development or ROM hacking, you should be aware that PPU register viewing and VRAM/CGRAM/OAM breakpoints only work with the compatibility profile.

I don't have access to an environment to build 64-bit Windows binaries, but as far as I know bsnes-classic should compile for that target if you have the necessary libraries (i.e. Qt 4.8).

The choice of profile is completely orthogonal to the build target. Releasing 32-bit compatibility builds and 64-bit accuracy builds was just an arbitrary choice that byuu made. The build I use on my own Linux machine is 64-bit compatibility.


Top
 Profile  
 
PostPosted: Tue Nov 17, 2015 4:21 pm 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 318
Location: FL
I've uploaded newer 64-bit builds which should be a fair bit faster than the previous ones (blame me not bothering to switch away from outdated sjlj-based tools until now...)

If you were experiencing slower emulation with the x64 builds (especially with coprocessor-based games) that shouldn't be an issue anymore.

AWJ wrote:
The choice of profile is completely orthogonal to the build target. Releasing 32-bit compatibility builds and 64-bit accuracy builds was just an arbitrary choice that byuu made. The build I use on my own Linux machine is 64-bit compatibility.


I think having 64-bit compatibility and accuracy but only 32-bit compatibility seems like a pretty reasonable default. I think most people at this point would be best-suited by the 64-bit compatibility build, whereas a 32-bit accuracy build would be too underperforming to be worth it (and I doubt many potential users still need the performance profile that much...)

I personally did not even own a 64-bit machine until fairly recently, which is one of the reasons I didn't publish 64-bit builds until now (the other being the aforementioned lack of official 64-bit Qt binaries for Windows). But both of those aren't issues for me anymore, and I can keep producing 32-bit builds with the same toolchain, so I'll likely continue to do so until it stops being feasible.


Top
 Profile  
 
PostPosted: Wed Nov 18, 2015 10:41 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1329
I gave up on 32-bit builds, myself.

For whatever reason, the 32-bit MinGW project ships with headers from Windows 98. They don't even have headers for DirectDraw. I used to have to dig out the DirectX SDK from November 2008, pull out its headers to drop into MinGW, and then go find glext.h from opengl.org, just to get stuff compiling. I'm tired of doing all the extra work.

I haven't heard a single complaint from anyone for not having the 32-bit builds anymore. And I usually average around 60,000 downloads a release (it was a 2:1 split on 64-bit vs 32-bit when I released both), so I don't think it's really a big issue anymore.

And as much as I want to drop the performance profile, the bottom-tier computers (Zotac Zbox BI-320, Intel NUC5CPYH, etc) still require it to run at full speed. The 10% speedup for 64-bit mode is quite nice here. Even with that, I still dip to around ~55fps during the Yoshi's Island title screen, but the games themselves are all playable.

Another nice ~10% speedup is to use profile-guided optimizations. But like the 32-bit builds, I just couldn't keep up with all the extra work they require (it was seriously taking me 4-6 hours to put together new release builds at one point), so I stopped doing it.


Top
 Profile  
 
PostPosted: Wed Nov 18, 2015 1:40 pm 
Online
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2924
Location: Tampere, Finland
byuu wrote:
For whatever reason, the 32-bit MinGW project ships with headers from Windows 98.

Have you tried MinGW-W64? Despite its name, it can make 32-bit builds.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Wed Nov 18, 2015 3:02 pm 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 318
Location: FL
byuu wrote:
I gave up on 32-bit builds, myself.

For whatever reason, the 32-bit MinGW project ships with headers from Windows 98. They don't even have headers for DirectDraw. I used to have to dig out the DirectX SDK from November 2008, pull out its headers to drop into MinGW, and then go find glext.h from opengl.org, just to get stuff compiling. I'm tired of doing all the extra work.


I used to have those exact things in the build instructions for bsnes-plus back when I still used the original MinGW (which is basically dead, for all intents and purposes). Now that I use mingw-w64, I can just make both 64- and 32-bit builds with the same stock toolchain in about 30 seconds total. (I do plan to eventually commit some makefile additions to streamline it a bit for other people, but it definitely beats having to scavenge for fixes to an out-of-date compiler distribution.)


Top
 Profile  
 
PostPosted: Wed Nov 18, 2015 9:38 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1329
> Have you tried MinGW-W64? Despite its name, it can make 32-bit builds.

Yes, -m32 produces binaries with miscompiled instructions. This causes lots of weird glitches and outright crashes depending upon what you do. It's probably fine for simple projects, but doesn't work for something as complicated as higan. The NES core seems especially prone to problems.

I guess the SNES core is stable enough for Revenant, so that's good at least.


Top
 Profile  
 
PostPosted: Mon Nov 23, 2015 5:19 pm 
Offline

Joined: Sat Nov 21, 2015 11:05 am
Posts: 3
Excelent work and congratulations for the Accuracy Build!!!! Please, can you upload an updated x64 accurate build? Air Strike Patrol have a bug in the "Good Luck" message when I launch it in the accuracy profile but with the last compatibility build (2015/11/21) the message shows perfect. Thanks!!!


Top
 Profile  
 
PostPosted: Mon Nov 23, 2015 6:01 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1329
If I recall, that "Good Luck" text is supposed to "rotate", but it's on the same BG as the HUD on the left. The compatibility profile caches the BG scroll registers so the message and HUD both end up stationary. And a long time ago with v073 accuracy, the timing was wrong so the effect didn't work right. It's fixed in since probably v078 or so, but ... yeah. I get that I change the internals too much for you to be able to do much besides attempt back-porting fixes. Especially for your specific case where you can't just use the relatively stable Emulator::Interface, but have to tap into all the internal state for the debugger. We're in kind of a lose-lose situation here with all these forks, unfortunately :(

The ASP devs definitely enjoyed toying with the PPUs.


Top
 Profile  
 
PostPosted: Mon Nov 23, 2015 8:22 pm 
Offline

Joined: Sat Nov 21, 2015 11:05 am
Posts: 3
Thanks for the reply!! Well, it's a pity for now. :( I love the SNES games and I love this emulator for the accuracy but it's open source after all so I can wait for futures releases (for the bsnes-plus version with more Higan capabilities). Thanks again for this awesome work!!! :D


Top
 Profile  
 
PostPosted: Wed Nov 25, 2015 9:55 am 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 318
Location: FL
byuu wrote:
If I recall, that "Good Luck" text is supposed to "rotate", but it's on the same BG as the HUD on the left. The compatibility profile caches the BG scroll registers so the message and HUD both end up stationary. And a long time ago with v073 accuracy, the timing was wrong so the effect didn't work right. It's fixed in since probably v078 or so, but ... yeah.

Out of curiosity, what changed about the timing that fixed that spinning text? I know ASP has been well-known for doing some rather uncommon stuff with the PPU, but I didn't realize the BG scrolling trickery behind that text (or whatever it is) until I tried it for myself. Doing a comparison of the accuracy PPUs in higan and bsnes-plus didn't reveal anything obviously relevant to me, but I'm certainly not all that familiar with the details of either one.

I did backport the fix you recently made for ATX2, and I know AWJ made some other changes to the PPU a while back, but do you think there are any other potential accuracy issues still worth checking on?


Top
 Profile  
 
PostPosted: Thu Nov 26, 2015 10:26 am 
Offline

Joined: Sat Nov 21, 2015 11:05 am
Posts: 3
Well, there is a bug in the Super Game Boy emulation: missing sound effects in Game Boy games. For example, unaudible multiple shots sounds with the S weapon in Operation C (Contra) and unaudible percusison effects of the music in Crystal Castle and Cloud Castle of Castlevania 2 Belmont's Revenge.


Last edited by sUPERtOTO009 on Thu Nov 26, 2015 1:26 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Thu Nov 26, 2015 12:40 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1329
> Out of curiosity, what changed about the timing that fixed that spinning text?

I just barely remember it was related to BG3 scroll registers. I am not sure of the exact fix for this one, sorry. I don't have a very good memory.

> do you think there are any other potential accuracy issues still worth checking on?

Probably. Did you get the SA-1 MDR fix for SD Gundam G-Next?

Again, bad memory, so I can't really point you at many specifics >_>


Top
 Profile  
 
PostPosted: Thu Nov 26, 2015 1:04 pm 
Offline

Joined: Mon Nov 10, 2008 3:09 pm
Posts: 413
byuu wrote:
> Out of curiosity, what changed about the timing that fixed that spinning text?

I just barely remember it was related to BG3 scroll registers. I am not sure of the exact fix for this one, sorry. I don't have a very good memory.

> do you think there are any other potential accuracy issues still worth checking on?

Probably. Did you get the SA-1 MDR fix for SD Gundam G-Next?

Again, bad memory, so I can't really point you at many specifics >_>


IIRC the SD Gundam G-Next problem was a regression that crept in when you changed the SA-1 to use a hardcoded switch table for its address map instead of a Bus object, in an attempt to get back speed that was lost in the post-074 memory system rewrite. bsnes-classic/plus still use the pre-074 memory system (which also means that unlike higan they support SA-1 games with BS-X data pack slots--another casualty of the memory system rewrite)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 171 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7, 8 ... 12  Next

All times are UTC - 7 hours


Who is online

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