Good to know that the filenames are being fixed.
Could you please point me to what to link against for PresentationFramework and System.Windows.Shell on Linux with mono?
zeromus wrote:
You need to be using the portable branch. The master branch is developed without consideration for whether it works on non-windows platforms. Perhaps your problems will vanish if you do that.
Git is requested by the build process as part of the version.csproj building, which interrogates the local git repository for revision information. I would expect that to work even if .git didnt exist, but I don't bother testing it on linux so I don't know. Perhaps it's been fixed in the portable branch.
Git is required on the portable branch too. The Version project has a conditional to execute the Build.Tool.exe under mono as part of the build process. (It's identical to the windows command, just with 'mono' in front so that it actually works.)
Linux build instructions are mentioned earlier in this thread. Just check out the portable branch from github, using git, and open it in the CURRENT version of MonoDevelop and build it. Don't use an old version, they distribute official ones themselves because Linux package mangers don't like to manage up to date packages themselves.
BizHawk (from the branch) still builds out of the box on Linux last time I tried. You might have an issue with the Version project, that's the only thing that ever gave me troubles because MonoDevelop sometimes doesn't like that there aren't any files in it. You can work around the problem by adding a file, or creating the VersionInfo.cs file that the version project would have created yourself, then just turn off that project so you don't get a build error from it.
Last time I tried BizHawk on Linux, it did not work very well. It builds fine, but the UI was very unstable and the crashes were inside of the mono framework itself. It's been a while since I've tried it on Linux though, I don't really use it very often because of how often stuff breaks.
Aww come on man. I just want to know if PSXhawk is on it.
PSX has been supported on OS X since the same release it was added on Windows. The only systems OS X is missing (as far as I know) are N64, SNES, and Saturn.
I have no intention of removing PSX support.
As far as the other new things in 1.11.4, I haven't finished looking.
Edit: 1.11.4 OS X build is out. There is not SNES support yet, I wasn't able to get that working, nor was I able to get the new LibRetro core loader working. Both of those features can be looked at some time in the future. I figured I'd release what's working, so you can get the fixes for other systems at least.
The libRetro thing should work if you provide one of their .dylib files, but instead completely crashes the application. I'm not sure as to the cause. It loads the dylib fine, but crashes BizHawk when it actually tries to use it.
it's the 1.11.3 Mac revision, when i opened it last night it was like "hey MacHawk 1.11.4 has just come out, update to the latest version, then when i clicked on the link it took me to the PC download page instead of the Mac download page.
Are you just referring to the website? The application itself doesn't have any sort of auto-update mechanism.
I don't understand what's telling you to update.
(Delaying 1.11.4 OS X build for another day or two. Want to see if I can get SNES working this time.)
whats going on here, it says there is a new version on my mac version of bizhawk which i want to personally call MacHawk ;) is it thinking of the PC version?
Due to how the Version Update notice page works, BizHawk for Mac, thinks "Update available."
What says there's an update? What version update page?
The OS X build should be ready today or tomorrow. I merged everything over yesterday, just need to deal with the changes to native cores.
Another thing to consider, unless someone has fixed it recently, BizHawk only polls for controllers when you open it.
So if you plug in a controller while BizHawk is running, it won't be usable until you restart the emulator.
As zeromus already mentioned, thanks for noticing it. It's not a big deal to me, but was worth fixing I guess.
I've re-uploaded the source forge build with an empty config file. I'll try not to make that mistake again. I already have a script that prepares the builds for release, but it doesn't do the zipping part since that's a right-click away.
thanks for noticing that, i took the file down so he can evaluate the situation and make a new build
I don't think it was necessary to take down, but I can get a new build ready later.
My usual procedure is
1. Make Build
2. Zip Build
3. Test Build to make sure it actually works.
4. Upload build
But I must have accidentally done step 3 before step 2, so the config file wasn't clean.
Rest assured that there is no game bundled into the zip file, just a reference to the folder on my desktop where I keep a few games to quickly test with. (And in case it comes up, no, Sonic Triple Trouble was not released for SMS. It's the fan-made port.)
So just wondering guys. Does HawkBiz have compatibleity with PS3 controllers? I tried connecting one up last night and all I could do was jump shoot and enter my vehicle. Can't move and when I try to assign buttons it does nothing :( please help me guys.
PS3 controller does not function as a standard controller when plugged into a computer like the PS4 controller does. According to a quick google search, they might function over bluetooth but I haven't looked at that.
The Steam controller also does not work for BizHawk on OS X yet, I can't even detect it as a controller. I contacted Valve abut it, they're aware of the issue and confirmed that their controller isn't recognized as a Gamepad on OS X yet and that will be fixed with a firmware update in the coming weeks. (Probably in time for the official launch in November.) I'll try to make sure it's supported correctly when they fix it.
I look forward to a day when BizHawk runs natively
What do you mean? Some Linux/OSX-friendly toolkits?
I would assume something like this:
http://projects.sappharad.com/bizhawk_mac/bizhawk_linux_broken.png
Screenshot is from the EtoHawk UI in the portable branch. Actually really very bad on Linux right now. I can't map all of my controller buttons without mono crashing and bringing down the entire app. And the picture of the controller on the right side of the dialog doesn't show up for some reason.
I added 1.11.3 to the first post.
The OS X port supports Game controllers now, although it's kind of rough. An XBOX 360 controller works and maps fine, but when I try to configure a PS4 controller the D-Pad acts as if it's rotated clockwise by 45 degrees, making it difficult to map and use.
And sometimes the application doesn't detect the controller, so you need to close the app, unplug + replug the controller, then relaunch BizHawk and it might detect the controller. You can't plug/unplug controllers while the program is running, although I'll probably fix that in the future.
Progress on the new UI is still moving along extremely slowly. Controller configuration dialog is pretty close to finally being done, it works now at least.
cpu model: Intel(R) core(TM)2 Quad CPU Q9650 @3.00GHz 2.99 GHz
zeromus wrote:
your cpu is also on the old and weak side. 7 years old and optimized for multiple threads (useless for emulation) even when it was made. call it 8 years old then.
still it seems a bit slower than it should (im not sure i would expect 60 on your system though)
My primary machine has an Intel Xeon E5462 @ 2.80GHz. Based on PassMark scores, his CPU is slightly faster than mine. (1268 vs 1219 for single thread)
I can run PSX at 60fps. So 60fps should definitely be achievable. Definitely double check that it's not running in GDI mode.
To add to what zeromus said, most people don't have the resources to test anything except Windows, nor do they care. For a project that relies entirely on people who do this in their spare time, adding the complication of making something work everywhere would only hurt the possibility of more people helping out. If it's a pain in the ass to develop for, nobody's going to want to do it.
Having said that, they've already done a really great job making the backend portable. Everything on the C# side that isn't the user interface builds and runs fine outside of Windows with no modifications required. It's perfectly ready for someone to write a proper, native UI for other platforms, it just needs people to spend the time to do so. They already did plenty of refactoring to ensure that would be possible, and it's the right way to do it. If you look at other multi-platform emulators like Kega, that's how it was done there. The UI for Kega is native on OS X and Windows, but the backend is the same. It's right approach to take when trying to provide a good experience for everyone.
What I've done so far for the OS X port is pretty lazy. I wanted an OS X version, but didn't really want to spend time writing the UI from scratch so I kept trying to stick band-aids all over the existing Windows UI to make it work on OS X, and to some extent it kind of works on Linux too. The current plan to write a new UI for these other platforms is the right approach, which is why I started that a few months ago. When it's far enough along, that code should be able to live in the same place as the Windows version, since the stuff that it will share (non-UI) is already portable. The last time I tested it, the new UI was working fine from the master branch with no changes to that code, which is kind of one of the things you're asking for. It's just a separate solution, which shares the existing backend projects.
It's still much easier for me to roll new builds against the existing UI than it is to work on the new one, which is why this process is moving so slowly. I use the current builds to play games and sometimes watch .bkm movies, so I don't have a lot of motivation to re-implement stuff that already works even though it's a bit rough.
I hope this gives a little bit of insight. If anyone's familiar with C# and wants to help out, that's always a good option. I'm trying to implement the new UI with the Eto Framework, which is a wrapper that translates to native UI's across Windows, Mac OS X and Linux. Coding is similar to using WinForms, but all of the UI is built by hand since there isn't a drag/drop designer like WinForm, and everything is organized using Layouts similar to how you would build a web page in HTML. So there's a bit of a learning curve for me, as I struggle to figure out how to make it behave the way I want to. The end result looks great on every platform, and it even does neat platform specific stuff like launching file open dialogs as sheets on OS X which is something I can't do with the current UI.
a bunch of stuff builds now after i made a svnrev.cs! now I'm getting an error in Firmwareconfigs.resx in client.emuhawk. there seems to be a problem with tbbGroup.Image.
here's the error : http://pastebin.com/5bFnBCqh
any ideas as to what this is?
Upgrade to a newer version of MonoDevelop or the MDK.
Older versions of Mono's compiler really hated BizHawk's resx files, I've had problems with them in the past. It was a bug in their compiler. You should be using a version of MonoDevelop that supports MSBuild, anything newer than 4.x should work. (5.9..4.5 is the latest according to their site.)
They provide official packages for Debian, Ubuntu, CentOS and Fedora now. Previously, the versions on official repos for distros like Ubuntu were really old.
Alternatively, you can go into the ResX file and just delete the XML for the particular resource that is failing, although that icon will be blank in your build then. (Only do this if you know what to safely delete)
Hang on does this mean we can use N64 on this Mac port?
No. N64, SNES and Saturn are not supported on OS X right now. All other systems should be working.
I made some progress with SNES, (the core is ported) only to find out that the method it uses to communicate with BizHawk isn't supported on OS X and Linux. Since BizHawk may get a second SNES core eventually, I'm not going to attempt to work-around the problem in the near future.
N64 is possible, but it's probably the most effort of the ones missing. I may attempt it again at some point. In other words, some day but not yet.
The native OSX menu bar doesn't like to respond to clicks. It also contains menu items that should be disabled, like the debuggers; choosing one of these unimplemented menu items appears to do nothing. Choosing the menu item a second time crashes the application.
I did some actual work on this problem for the OS X build of 1.11.1.
The menus are now responsive like a normal application most of the time, as long as CPU cycles aren't being eaten up by emulation. So for cores that run 100% with not much difficulty, everything seems fine. On my 7 year old Mac Pro, which can run PSX full speed but CPU use is close to being maxed out, menus become sluggish.
Menus now update to disable things and such. There are still cases where they can be wrong, but the majority of situations are handled correctly.
The flickering and redraw problems in the WinForms dialogs are a mono specific problem, so unfortunately there's nothing I can do about that. The UI will be completely replaced with a native one at some point, that's an early work-in-progress.
it's not building for me. i get an error in Versioninfo.cs in Bizhawk.common.
The name "SubWCRev" does not exist in the current context.
I've also had issues with "svnrev.cs" not existing. Either of those look familiar to you? I'll have another chance to try and fix the errors later this week.
This is a fairly simple problem, and it just means that BizHawk is having problems pulling the version number from your checked out copy. The version project is supposed to create an updated VersionInfo.cs file with the correct build number each time you build, but I haven't really played with that since the move from SVN to Git to see if it's still working correctly. Take a look at the template (It's in the version project folder) and create VersionInfo.cs manually for now if you don't want to wait for me to look into it. I probably did the same thing and just set the revision to 0. If you're making local builds for yourself, the version doesn't matter anyway.
I'm going to try and get Bizhawk up and running on linux without having to use WINE. I don't have a lot of free time, so expect progress to be very slow.
Anyone who has experience working with monodevelop , especially on linux, please shoot me a PM.
See my post earlier on this page, from March 4th of this year. As of then, it was still building on Linux for me, with a fresh install of the latest version of MonoDevelop. There were some windows that crashed, but it was possible to build and run.
No work has been done to port any of the native cores (QuickNES, BSNES, Genesis Plus, etc.) to Linux.
When I open up bizhawk on my Mac, the emulator doesn't even open. It just crashes. I have installed Mono.
Make sure you're running at least 10.7, and that the version of Mono you have installed is also recent. Can't provide anymore advice than that, since you provided no details about the crash.
Bumping to mention that I posted a Mac build of 1.10.0. It has the new mgba core as well.
This also fixes QuickNES, which was broken in the 1.9.4 Mac build because I forgot to test it.
But )it also fails at regular NES games. )I gt this dialog with Legend of Zelda as well as SMB.
My bad. Guess I forgot to test QuickNES in the last release. It will be fixed when I get around to posting 1.10. (Done)
skypickle wrote:
Mole mania starts but it asks to hit the 'start' button. Unfortunately, no keys work for this.
Input keys use the Windows defaults, which don't match Mac. (Enter vs. Return key, etc.) You'll need to configure the keys the first time you use a system, like Zeromus says.
I suppose I could update all of the defaults for the future. I updated them for the Eto version, which won't be ready for some time.
Did you unzip the archive properly?
If so, you could always just copy the dll's from the dll folder into the main folder and see if it works then. You're not supposed to have to do that though.
EDIT: I think I fixed it but I'm not sure why this fixes it - for whatever reason it just fails at drawing images when you use event.onframestart(), but not when you use the old while true do loop method.
I don't know anything about this, having no real knowledge of Lua, so this may seem like a stupid comment, but...
OnFrameStart() would imply to me something that happens before the frame is drawn, such that if you draw the frame is going to draw over that afterwards. So you'll get the exact problem you're describing.
Not sure if there's any reality to that, but if I were to draw against someone's API I would expect to do it after they do, so they don't draw over me.
is there a fixed linux build i can try?
I've tried the old v1.0.4a but it is not showing the menus...
EDIT: i'm going to try wine+winetricks dotnet40...
Yeah, that's your best bet right now.
The last time I tried BizHawk on Linux, it did compile and run, but the controller config screen crashed. I'll have an alternative ready in maybe 6 months that should work on Linux, but things are moving slowly right now because I'm only giving it about an hour per week.
I've tried running the latest v1.9.4 on my ubuntu trusty installation:
You're trying to run the mac build on Linux. You can't run the Mac build on Linux, it uses native OS X UI components.
You need to build from source code.
