@Sappharad
We were aware that Mono supported Winforms, we also knew Mono had several caveats listed (obviously, P/Invoke based winform stuff won't work).
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.
It looks like Mono has improved a lot since then, so hooray!
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...
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.
Emulator Coder, Site Developer, Site Owner, Expert player
(3573)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
We are interested in the idea of making some practical cross-platform changes. Maybe a fork is best but like you said it is developing rapidly. Discussion would be preferred, I don't suppose you IRC? We would prefer to discuss this way (#bizhawk on freenode)
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.
As far as Mono goes, it is much better. I have a game I made for a college class (using GDI+ for graphics), and in 2006 it wouldn't run in Mono, but now it works perfectly. And I've read that the Mono-based WinForms designer is 99% complete, though it doesn't seem to be implemented in the core builds of MonoDevelop.
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.
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.
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 was editing my post to talk about ways to separate Mono and .NET code so you could have it all in the same code base, but after doing some more searching on it, it seems like it would be easier to just make a fork and keep it separate. So I just abandoned my edit.
How much of the client (in terms of total features like TAS tools, cheats, etc.) is tied up in Windows-only or WinForms code? Can't any of it be reused just with different UI calls?
Emulator Coder, Site Developer, Site Owner, Expert player
(3573)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
Much of the code is reusable for another port. The rerecording for instance is a movie class that has no windows-specific or winform code, there's a number of classes such as this that are easily re-usueable. And from what I understand the basic winform dialogs are fine except for lua, and the ones that use the virtuallistview. Most dialogs do not use this so they are easily copied as well. I think about 80% of the codebase could be ported without issue.
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.
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.
I'll once again point out my lack of experience before I ask this question.
Why use DirectX and OpenGL instead of something like SDL, which seems a bit easier to port? Well, one downside is that Windows comes with DX while Linux and Mac OSX come with OpenGL, whereas SDL is a separate thing users would need to download.
OpenGL sucks on certain ATI cards. Mostly the mobile Radeons.
SDL is implemented using DirectDraw on Windows. On Linux, I think it uses X11, so it doesn't talk directly to video hardware. (not 100% sure whether DirectDraw is still being used or not)
Why use DirectX and OpenGL instead of something like SDL, which seems a bit easier to port? Well, one downside is that Windows comes with DX while Linux and Mac OSX come with OpenGL, whereas SDL is a separate thing users would need to download.
Users wouldn't need to download SDL so long as its libraries were statically linked into the application, but developers would. One big problem with SDL is that it has very primitive windowing limitations -- you get one window, which SDL holds sole control over. It also doesn't do so hot with direct pixel manipulation. It's basically designed for simple 2D sprite-based gaming applications, which ironically enough emulators don't do (because they're at too low a level to be able to observe what the sprites in the game are).
Using SDL would also pretty well lock you out of ever adding an N64 or PSX emulator core, let alone something more advanced; you need 3D acceleration for those.
My vote generally is for OpenGL, because of its cross-platform capabilities. If your program uses DirectX, then you're locking out a potentially significant proportion of the community (Linux/Mac users) because they simply can't run your code. Dual-booting is enough of a pain that only the really motivated people will be willing to bother with it.
As for performance of OpenGL vs. DirectX, my impression is that BizHawk is aimed at the TASing community, so while it's nice if the emulator is as optimized as possible, it's not absolutely vital that the game be able to play back at its native framerate. In any event, are the bottlenecks really in the graphics engine at this point?
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Using SDL would also pretty well lock you out of ever adding an N64 or PSX emulator core, let alone something more advanced; you need 3D acceleration for those.
You most certainly do not; the most accurate PSX graphics are done in full software (as well as PS2 graphics), and I have a hunch if there were any accurate N64 emulators out there, they'd have a soft graphics mode too.
Why use DirectX and OpenGL instead of something like SDL, which seems a bit easier to port? Well, one downside is that Windows comes with DX while Linux and Mac OSX come with OpenGL, whereas SDL is a separate thing users would need to download.
Users wouldn't need to download SDL so long as its libraries were statically linked into the application, but developers would. One big problem with SDL is that it has very primitive windowing limitations -- you get one window, which SDL holds sole control over. It also doesn't do so hot with direct pixel manipulation. It's basically designed for simple 2D sprite-based gaming applications, which ironically enough emulators don't do (because they're at too low a level to be able to observe what the sprites in the game are).
Using SDL would also pretty well lock you out of ever adding an N64 or PSX emulator core, let alone something more advanced; you need 3D acceleration for those.
The most well-used version of MAME on Linux is SDLMAME. Ubuntu even used SDLMAME to replace the base MAME package in their repositories. And I'm pretty sure SDLMAME shares full compatibility with the core MAME project. I don't know how many 3D games MAME supports, but it seems they're quite doable with SDL.
But again, I'm far from an expert, so I really have no place in debating any of this.
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)
Let me just say that if a cross-platform version doesn't exist (or is severely crippled) you'll have no chance of switching the official emulator to this without alienating a significant portion of your userbase - even those who don't make TASes often like to play back in an emulator, because it's a much smaller download and looks better, and in many cases, emulating an entire system is more lightweight than running Flash ;)
But yeah, good luck with this - I would love to see it working well, it'd be nice to have some unified UI for everything.
Let me just say that if a cross-platform version doesn't exist (or is severely crippled) you'll have no chance of switching the official emulator to this without alienating a significant portion of your userbase - even those who don't make TASes often like to play back in an emulator, because it's a much smaller download and looks better, and in many cases, emulating an entire system is more lightweight than running Flash ;)
But yeah, good luck with this - I would love to see it working well, it'd be nice to have some unified UI for everything.
It seems like a majority of the TASVideos supported emulators are Windows-only already, so I don't think there's a risk of alienating anyone at this point.
Few of the emulators play nice in Wine, either. Even a couple of the native versions have issues, at least for me. So I'm quite happy with the promise of this project.
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.
Joined: 10/12/2011
Posts: 6438
Location: The land down under.
adelikat wrote:
is a Multi-platform emulator.It emulates a number of cores and provides full rerecording support.
Cannot wait for Playstation added to it and the fact the encoders don't have to wait an hour to encode :D
adelikat wrote:
Currently BizHawk emulates NES, SMS, GG, SG-1000, PCE, PCE CD, SGX, and TI-83 at release quality. It also includes experimental Genesis and Gameboy cores.
Time to use this with GBA games ;D
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account.Something better for yourself and also others.
Having Aero enabled won't prevent something that doesn't like it from running (like Gens). However, when said application starts, Windows disables Aero while said application is running. This results in an annoying black screen and wait for everything to refresh, and prevents useful features of Aero from being used (personally, I'm partial to being able to see a mini-screen of any of the programs running on the taskbar, but if Aero is disabled, I can't do that).
And sometimes Windows is slow to re-enable Aero when the Hatey McHaterson application is shut off.
Having an alternative that doesn't do all that is vastly preferable, IMO.
