Posts for Sappharad

1 2
5 6
Experienced Forum User
Joined: 3/11/2012
Posts: 149
Location: WI
PikachuMan wrote:
I see that in the core road map says that Project64 1.6 is going to be integrated into Bizhawk. I hope someday that 1.7 to be integrated for the sake of this hack.
The source code to Project 64 1.7 is not available. With the way that previous emulators (Gambatte, BSNES) have been integrated into BizHawk, it would not be possible to integrate that version of PJ64 without the source code.
Experienced Forum User
Joined: 3/11/2012
Posts: 149
Location: WI
Does Dolphin have any debugger features similar to WiiRd and GCNrd? Back on the Gamecube, I was able to accomplish a similar task by setting a read breakpoint on the address of a file in the FST. The game would only read from that location if the file for that table entry was being requested. I don't know where it's loaded in memory on the Wii, but on the GCN the FST was always near the end of main RAM and there was a pointer to it somewhere near the beginning. Since WiiRd has the same FST modification features that GCNrd had, I'm assuming the same trick would work.
Experienced Forum User
Joined: 3/11/2012
Posts: 149
Location: WI
Doing a quick bump for the OS X release of 1.3.0 since this was falling to the bottom of the page. I've actually made some improvements to the OS X specific side of things this time around, because one of those improvements was necessary to use FDS games. - Improved stability a bit. A few cases where the emulator spontaneously crashed on loading a game should be fixed now. - Your config changes should always save now when Closing/Quitting the emulator. Sometimes that wasn't working before. - The logic to recreate the Windows menus as Mac menus is now capable of handling some cases where the menu contents change while the program is running. Right now, I've only implemented this in a hack-like manner for the NES menu so that Famicom Disk System options show up properly. I can this in a better way for other menus that change (such as the Recent list) in the future. This was probably the longest I've spent on OS X specific changes in a few months. Not sure when I'll have several hours to do more again.
Experienced Forum User
Joined: 3/11/2012
Posts: 149
Location: WI
YoungJ1997lol wrote:
Occasionaly, on the Mac version, when I load a game, it'll close automatically.
I would suggest keeping problems specific to the Mac version in this thread because I think I'm the only person who works on it. That being said, the problem has one of two causes. The first, is a completely random failure that is probably a result of me mixing OS X and Windows UI components. It happens randomly, and the problem occurs inside Mono itself, so I have little control over it. There are ways around the problem, but it's a lot of work and right now very few people even download the Mac builds so I haven't put much effort into resolving it. The second cause is that the game you decided to load isn't working and something blew up. You should usually see an error, but maybe not always.
Experienced Forum User
Joined: 3/11/2012
Posts: 149
Location: WI
adelikat wrote:
Ok, no core requests or "Any plans on X core?" questions! http://tasvideos.org/Bizhawk/CoreRoadMap.html
Isn't SGB already supported? The page implies it's still on the to do list.
YoungJ1997lol wrote:
Mac support?
Already been available for 6 months now.
Post subject: Re: Unable to run Bizhawk
Experienced Forum User
Joined: 3/11/2012
Posts: 149
Location: WI
Randil wrote:
The only additional error information I got from this message was (I translated it from Swedish):
 Problem event name:	CLR20r3
  Probleme signature 01:	bizhawk.multiclient.exe
  Probleme signature 02:	1.0.1.3169
  Probleme signature 03:	505f4621
  Probleme signature 04:	BizHawk.MultiClient
  Probleme signature 05:	1.0.1.3169
  Probleme signature 06:	505f4621
  Probleme signature 07:	5ff
  Probleme signature 08:	54
  Probleme signature 09:	System.IO.FileNotFoundException
  OS-version:	6.1.7600.2.0.0.256.48
  Language variant:	1053
  Additional information 1:	0a9e
  Additional information 2:	0a9e372d3b4ad19135b953a78882e789
  Additional information 3:	0a9e
  Additional information 4:	0a9e372d3b4ad19135b953a78882e789
I hope this is of some help. Does anyone know what the problem could be? Is there any additional information I can provide that could be helpful in finding the problem?
Did you unzip BizHawk before running it? You're getting a File Not Found error, which means it can't find a file that it's looking for. I also found it interesting that the version number in your error is listed as 1.0.1.3169, but I'm not sure if that means anything because I've never used an official release so maybe that's normal.
Experienced Forum User
Joined: 3/11/2012
Posts: 149
Location: WI
Dwedit wrote:
This is also a Microsoft .NET program, which is unlikely to work on Linux.
adelikat wrote:
2) Older versions of BizHawk have linux builds. Those come without lua, and some of the tool dialogs, but otherwise work. Linux support is poorly maintained since the guy doing the builds mono builds is interested in it for Mac.
The portable branch will still compile and run from a fresh checkout of SVN on Linux. There are UI problems on Linux that don't exist under OS X but otherwise there's nothing stopping someone else from maintaining linux builds. :-) I may come back to Linux some day and do another build, but it would be nice if someone who uses the OS regularly would maintain that part. I can handle making sure it continues to build and stays in sync with the trunk.
Experienced Forum User
Joined: 3/11/2012
Posts: 149
Location: WI
Not sure if you're aware, (probably, but you saying you were excited about this core made me question it) the Musashi Core is enabled in the released version. Which is why it works so well. In the OS X release, which isn't using Musashi, it's as bad as the previous version just with better sound.
Experienced Forum User
Joined: 3/11/2012
Posts: 149
Location: WI
blitzag wrote:
Ok thank you. In this case, what kind of (small) Linux build I should look into?
Honestly, I don't know. Mono on Linux doesn't even have an "official" distribution, each distro seems to have it's own. And MonoDevelop 3.0, which has been out for a couple months now, isn't even available on Linux yet. I only provided a linux build because someone would ask for it, my own testing on it was unstable because I was running it in a VM without any hardware acceleration. We really need someone who actively uses linux to support it better. The changes I make all work for Linux too, but actually using them is another story. Mono seems to be best supported on OpenSuse Linux, but I haven't actually tried it there. I've only tried Ubuntu, which "kind of" works, but not as well as my testing on OS X. For example, with the Linux build, if I run it out of the MonoDevelop IDE it works fine, yet if I run it standalone the menus are usually unresponsive. My future plans should fix some of the problems, but they're awhile off now because it "works on my machine" and as long as a few people can use it I'm not too concerned.
Experienced Forum User
Joined: 3/11/2012
Posts: 149
Location: WI
blitzag wrote:
Mac OSX 10.7.3 I load up a run and the emulator just crashes. If I don't load a rom, the emulator will run for about 30 seconds before crashing. Here is the pastebin of the crash report: http://pastebin.com/CH69v5s4
It appears to be graphics related, and it's crashing inside of the mono runtime. The problem might go away if I ever get OpenGL implemented for OS X, or you can just keep trying new versions of Mono when they come out to see if they fix it. Sorry about that.
Experienced Forum User
Joined: 3/11/2012
Posts: 149
Location: WI
Can you give me any more details than that? I have an old 10.6.8 Virtual Machine in VMWare, and I copied the latest version over to it and I was able to run an NES game just fine. The VM is a fresh install of OS X with nothing else besides the Mono Runtime, which I hoped would be a good test environment.
Experienced Forum User
Joined: 3/11/2012
Posts: 149
Location: WI
Dwedit wrote:
Tested Fire Hawk again, still broken.
I asked zeromus about your post on Saturday, it wasn't ignored. (The same problem seems to affect other Codemasters games) He said something like he wants to re-write the audio anyway, so it's not worth fixing it now.
Experienced Forum User
Joined: 3/11/2012
Posts: 149
Location: WI
Updated the first post with 1.0.4 builds. Added a linux build, but it's going to remain poorly supported due to my lack of interest in Linux support. I'd suggest that Mac and Linux specific issues should probably stay in this thread where they can be easily found.
Experienced Forum User
Joined: 3/11/2012
Posts: 149
Location: WI
jlun2 wrote:
NitroGenesis wrote:
Works for me.
I tried both Chrome and IE; both don't work. Can someone please download it and post it on mediafire or something? Thanks!
Run windows update. It's under optional installs.
Experienced Forum User
Joined: 3/11/2012
Posts: 149
Location: WI
Limne wrote:
I kind of wonder about some things... Why C#? Portability has never been a big priority for Microsoft... Considering the way their scaling back on XNA these days I'm kind of all-together wary of them, but I digress.
I don't think you really read this thread, or noticed the thread right below this one about the OS X port. I think the mono team has done a really great job bringing C# to other platforms. Aside from platform specific code and some minor bugs in their WinForms implementation (which were easy to work around) the non-windows ports run great. I get full speed performance on all of the systems I've actually tested, and that's not even using hardware accelerated video.
adelikat wrote:
As for portability, its possible, and being worked on right now thanks to sapphire and pcc.
I'm actually in "maintenance mode" right now, merging the latest changes down about every two weeks. (I started porting an XNA game to OS X about two weeks ago, so that's a temporary distraction for me because it's more fun.) But as-is, anyone can build and run the code themselves and it's playable so it's not a big deal. I'll resume work on my wrapper in a couple of weeks.
Experienced Forum User
Joined: 3/11/2012
Posts: 149
Location: WI
Updated the first post with a new build. The menus are now translated to native OS X menus. But just like the file open dialogs, I haven't quite done everything necessary in this area yet. (For example, the recent lists will only populate once, when the open the program) There may be some stability issues that I haven't isolated yet. I left the emulator paused for about 15 minutes and it crashed. I will address these things when I can find them.
Experienced Forum User
Joined: 3/11/2012
Posts: 149
Location: WI
Mac OS X Build of 1.11.7: http://projects.sappharad.com/bizhawk_mac/BizHawk_mac_1.11.7.zip Current and older versions were once available on SourceForge: https://sourceforge.net/projects/bizhawk/files/BizHawk/ Linux Build of 1.0.4a: (Not latest, see below for reasons) http://code.google.com/p/bizhawk/downloads/detail?name=bizhawk-1.0.4a-linux.tar.gz Note: This lacks some features of the Windows version and provided for enjoyment and feedback. See below for more details. Mac Requirements: 1. A Mac running OS X 10.7.5 or later. 2. Mono runtime. (The program will take you to the download page if you don't have this) Note: Mono runtime 3.10 has a bug which prevents BizHawk from working. If you have 3.10 installed, downgrade to 3.08 or upgrade to 3.12 or later. Linux Requirements: 1. The latest Mono Runtime must be installed. Older versions experience problems with behavior and drawing of the UI. 2. OpenAL is required. It will throw an error on startup if you don't have it. What works: - NES, FDS, SMS, Game Gear, PCE/TG16 games, Atari 2600, Atari 7800, Atari Lynx, ColecoVision, Genesis/MegaDrive, Sega CD, Gameboy, Gameboy Color, Gameboy Advance, Wonderswan. (Other systems untested and/or unsupported) - Keyboard input - Sound - OpenGL - TAS Recording - TAS Playback General information: - Lua support is disabled. It is probably possible to add, but getting all of the systems ported is a higher priority. Mac version specific limitations / known bugs: - Mac file open dialogs don't have a file type drop-down. They're restricted to supported file types by default right now. Please post Linux or Mac specific problems in this thread. Edit history: (2012-04-14) 2nd mac alpha build of 1.0.3, with native OS X menus. (2012-06-16) In sync with 1.0.4 release. Posted Linux build. (2012-06-19) Posted builds for 1.0.4a. (2012-07-05) Mac build of 1.0.4b posted. Ignored linux this time, because I don't want to test it. Feel free to checkout branches/portable/ from SVN for linux. (2012-08-03) OS X build of 1.0.5 release posted. (2012-09-22) OS X build of 1.1.0 release posted. Missing SNES and GB/GBC support. (2012-10-08) OS X build of 1.1.1b release posted. Missing SNES and GB/SGB/GBC support. (2012-10-20) OS X build of 1.2.0 release posted. Adds Atari 2600 in sync with Windows, but missing SNES and GB/SGB/GBC support. (2012-12-01) OS X build of 1.3.0 release posted. Adds ColecoVision and FDS support in sync with windows, still missing SNES and GB/SGB/GBC support. (2012-12-26) OS X build of 1.4.0 release posted. Adds Atari 7800 in sync with Windows. (2013-03-25) OS X build of 1.4.1 release posted. (2013-08-23) OS X build of 1.5.0 release posted. Does not add any of the new systems supported on Windows, but does contain other changes like the new firmware dialog. (2013-08-31) OS X build of 1.5.1 release posted. Contains same fixes as the windows version, at least the ones that are applicable. (2013-10-20) OS X build of 1.5.2 release posted. (2014-02-25) OS X build of 1.6.0 release posted. Adds Genesis / Sega CD support in sync with Windows. Also adds OpenGL support on OS X, and the Audio Sync option is working. (Which Genesis usually needs, sound can crackle without it) (2014-04-01) OS X build of 1.6.1 release posted. No OS X specific changes, so whatever bug fixes from the Windows version are applicable here are fixed. (2014-06-08) OS X build of 1.7.0 release posted. Adds QuickNES and Wonderswan cores in sync with Windows release, also finally includes Gameboy cores (Gameboy, Gameboy Color) in the OS X port. (2014-06-23) OS X build of 1.7.1 release posted. (2014-07-19) OS X build of 1.7.2 release posted. (2014-07-22) OS X build of 1.7.3 release posted. (2014-08-03) OS X build of 1.7.4 release posted. (2014-08-26) OS X build of 1.8.0 release posted. Adds GBA Support. (2014-08-29) OS X build of 1.8.1 release posted. (2014-09-23) OS X build of 1.8.2 release posted. (2014-10-12) OS X build of 1.8.4 release posted. Added note above not to use the most recent OS X Mono Runtime 3.10, it has a bug which causes BizHawk not to work. (2014-11-23) OS X build of 1.9.0 release posted. Adds Atari Lynx. (2014-11-29) OS X build of 1.9.1 release posted. (2015-03-04) OS X build of 1.9.2 release posted. (2015-03-15) OS X build of 1.9.3 posted. (2015-04-06) OS X build of 1.9.4 posted. (2015-06-21) OS X build of 1.10.0 posted. Includes the new mgba core. (2015-07-19) OS X build of 1.11.0 posted. Includes the new PSX core. (2015-07-19) OS X build of 1.11.1 posted. Improves UI responsiveness, fixes FDS and .bkm movie playback. (2015-10-15) OS X build of 1.11.3 posted. Adds game controller support! (UI responsiveness seems to be sluggish again.) (2015-12-23) OS X build of 1.11.4 posted. Note that the new LibRetro stuff is not working on OS X in this release. You can try it anyway, but it will crash. (2016-02-15) OS X build of 1.11.5 posted. Fixed a couple of bugs reported in this thread. (2016-03-09) OS X build of 1.11.6 posted. (2016-09-01) macOS build of 1.11.7 posted. Note: Active work by me on the macOS port has been halted. See this post for more details.
Experienced Forum User
Joined: 3/11/2012
Posts: 149
Location: WI
PikachuMan wrote:
I installed the .net framework but it still won't load. I can't get it to work. I need some help. What do I do?
You have not provided any useful information that would allow someone to help you. 1. What are you trying to do? 2. What happens when you try to do it? Are you getting an error message? If so, what is the error message? 3. What version of Windows are you running? You say "it still won't load" which implies that you may have asked for help previously, but there's nothing else from you in this thread. Bizhawk will not work on Windows 98.
Experienced Forum User
Joined: 3/11/2012
Posts: 149
Location: WI
Edit: Changes mentioned below are now checked into /branches/portable/ on svn. Changes so far: (These changes affect non-windows platforms ONLY) 1. Audio support via OpenAL. 2. Keyboard input support via OpenTK. 3. Archive support (7z,rar,zip,gz) via SharpCompress. (Needed to use NES games.) 4. OpenGL support on Linux (OS X not supported.) In other words, it's enough to play games in the emulator. It is my hope to finish OpenGL on Sunday, and then I can post a WIP build for OS X and Linux users to play with. Edit 2: No builds coming as planned. Very basic OpenGL support is checked in, but I discovered today that the windows forms GLControl in OpenTK is not supported under Mac OS X at this time. That leaves GDI only, which isn't the greatest. I'm looking for an alternative and probably won't post a binary until I've found one.
Experienced Forum User
Joined: 3/11/2012
Posts: 149
Location: WI
Some things to keep in mind: 1. The Windows version already uses DirectX, and the OpenGL discussion is about other platforms. Nobody intends to change anything for Windows users, that would just make people angry. 2. OpenTK is a replacement for the now-dead Tao project, which had SDL support. As far as I know, the reason OpenGL sucks on Windows Vista and later is because of Microsoft removing native OpenGL support when they implemented WDM. Unless the graphics card drivers have a specific implementation of OpenGL, it goes through DirectX as a 2nd class citizen. (This is what I have read in the past, none of it may be true.) But anyway, OpenGL performance on Windows wouldn't really matter since we're just going to render a quad with a texture on it. A 10 year old graphics card could handle that just fine. I'm going to implement OpenGL support, if someone wants anything else they can implement that. (Keep in mind that the regular client has GDI so even if you don't have OpenGL support it can always fall back)
Experienced Forum User
Joined: 3/11/2012
Posts: 149
Location: WI
Zeikcied wrote:
But if you made a fork specifically for Linux and Mac, then that wouldn't really impact the main project. The code bases would be separate. So I guess I'm not understanding the issue with making a straight port of the existing client.
I think the only real issue is that moves very fast. Check out the SVN changelog, there are many revisions checked in every single day. But you're right. I would rather have the current feature set of the MultiClient, than some limited thing. I've already made some progress on a mini client (basically it loads up roms and displays them to an OpenGL control in the wrong colors because OGL doesn't have an ARGB texture format, just ABGR and RGBA so I'll need to swap the buffer around) but I can scrap it, fork, and start integrating OGL into the real thing. Anyone mind if I start a fork on Github then? From what I've read, it seems like it would be fairly simple to pull changes from SVN over to Git but I've never tried it before.
Experienced Forum User
Joined: 3/11/2012
Posts: 149
Location: WI
Zeikcied wrote:
Sappharad wrote:
If there is any interest, I can start a fork for changes to make this playable on OS X and Linux. I see that the trunk moves pretty fast though, so it might be difficult to keep it in sync.
I guess I should have read this thread before PMing Adelikat. I know a basic amount of C# (though I took those classes in 2003/2004) and I run Linux, so I'm really interested in seeing this ported. I can try to help, I suppose. I don't know anything about OpenTK, so I'd need to read up on that first. LUA and 7z support should be possible.
I should probably have followed up on this after I discussed it with them on IRC on Sunday. It was decided (mostly by zeromus, who seems to be against everything per his comments about mapper 0 in another thread) that making portability changes directly to the main client is not preferred for several reasons. There are a few instances where native GDI calls are made to improve the usability of the application, such as in VirtualListView. They felt uncomfortable adding platform specific code (well, it would be making some stuff windows / non-windows) because if nobody is around to maintain it and it breaks, it's just going to get in the way. I can understand this because I've seen it happen in the past. (I use an old version of a popular Linux audio player that had OS X code ripped out in the past year because nobody was around to maintain it. I'm perfectly content with the version I've been using for the past 3 years so I had no reason to help them bring it up to current standards.) The solution that they seemed agreeable to was a new mini-client that used the existing emulator core but was written from scratch with portable WinForms code. It could serve as an example for anyone wanting to start a native UI for other platforms. So what I'm going to do is come up with a very simple client that just lets you play games, and once that's done I'll start on a separate client with a native OS X UI and add the features that I want to see. I'll work on it over the weekend and report back at some point.
Experienced Forum User
Joined: 3/11/2012
Posts: 149
Location: WI
vecna wrote:
Bizhawk has been in development for.. perhaps longer than we would like to admit, in the early days we did some test with Mono and at the time, it had trouble running our emulation cores alone, without any UI. This was fairly discouraging to us with respect to mono. What did you have to change to get it to run that far under Mono? Even if Winforms works, obviously the DirectX stuff would all fail under OS X...
The changes were exactly the kind of things you would expect, and I'd estimate that they took me under an hour to do yesterday. I wanted to see just how deeply tied to Windows it was, so I just killed things one by one until it could run a game. (By commenting things out and/or changing return values appropriately) 1. Disabled DirectSound 2. Disabled DirectInput 3. Disabled Direct3D, so it reverted to GDI+ drawing 4. Replaced hard coded backslashes in pathnames with Path.DirectorySeparatorChar (You have a few of these in the code, and it blows up since OS X uses forward slashes in pathnames) 5. Removed some native calls in ScreenSaver.cs and VirtualListView.cs 6. Disabled LUA support, since that's calling an unmanaged DLL. I also had to avoid loading NES games, since 7-zip was calling an unmanaged DLL. (That could easily be replaced with SharpZip on non-windows platforms, if the database was stored in a zip file instead of 7z. There would be no need to sacrifice support on Windows because you could just support both) After those changes, I was able to test GameGear and SMS games, both worked at full speed. (Of course, since I had to kill input support you could only watch them) I would agree that Mono sucked a couple of years ago. For work, I do C# development on a large WinForms app (the solution contains over 60 separate projects) and a couple years ago I brought home a copy of the source code to get some experience with Mono. At that time, after several hours of work I reached the point where I could go no further because the codebase was so complex that it crashed the Mono compiler. A year later I loaded it up again with the current version of Mono at the time and actually managed to get the application building and running. WinForms support in Mono isn't perfect, but in most cases it works now. I've started looking into doing this properly (instead of killing things, adding alternatives) and it seems like pretty much everything would have feasible alternatives. OpenTK offers alternatives for all of the DirectX stuff I killed, and could be added as optional alternatives to the DirectX stuff. (Direct3D -> OpenGL, DirectSound -> OpenAL, DirectInput -> OpenTK.Input) Nobody on Windows would need them, but I don't think it would be difficult for them to live alongside DirectX. There are some issues with OpenTK 1.0, which is about 2 years old now, but 1.1 was due out a few months ago and even though it hasn't been released yet the nightlies from SVN fix all of the problems with it. If there is any interest, I can start a fork for changes to make this playable on OS X and Linux. I see that the trunk moves pretty fast though, so it might be difficult to keep it in sync.
Experienced Forum User
Joined: 3/11/2012
Posts: 149
Location: WI
vecna wrote:
The emulation cores (in Bizhawk.Emulation.dll) contain no windows-specific code and were designed to be portable. However, the client is significantly complex, so unfortunately just "porting the GUI" to another platform is a major undertaking.
You are aware that Mono supports WinForms, correct? It would be nice if you keep this in mind when referencing native code, if you ever plan to go multi-platform. That way if you can't get someone to do a native UI for a platform, you can at least fall back to the WinForms one. I just stumbled upon this project a few hours ago, it's very nice to see these emulators implemented in C#. I may wish to make some contributions at a later date...
1 2
5 6