No. What would you say about all the smw and sm64 hacks that work fine on less accurate emulators that don't work on real hardware? Thus, Master of Puppet's question is better.
@adelikat: I think the hack works fine in FCEUX, but I can't test it atm.
I'm glad you understand that. The ideal behavior would be for it to match hardware, like you've said. I think the question zeromus asked would help determine why it doesn't work in BizHawk, whether it be due to the romhack itself, or emulation accuracy.
Build output of svn rev 8611 from monodevelop 3.0.2: http://pastebin.com/cfWvurPR
(search for "error"/"warning" (if you're interested in warnings))
Not sure how I missed this.
Anyway, the current portable branch compiles almost out of the box for me. The only thing that I needed to change was setting the VersionInfo project to use XBuild instead of MSSBuild. (All other projects should be the default, MSBuild)
Tested on Ubuntu with a fresh install of the latest Monodevelop and related Mono crap at this time. It launches, you can run games, but unfortunately opening the control config screen crashed when I tried it so you can't actually do anything. And none of the native cores have been ported to Linux. Someone else is going to need to deal with those, at the moment I've barely had time for much more than keeping the existing things working. Progress will be slow on this front until I start working on a new UI for other platforms.
Here is kind of a stupid question but... Does the file Track01av1.wav exist?
Daemon tools is still willing to mount your image even when the CDDA it references does not exist.
Btw, even though nitsuja provided a JP/EU-synced version of the previous movie, Flygon instead used the US file and did this for the JP/EU music encodes
I'm not sure if it would be better to do this or use the JP/EU-synced movie instead, though
So the actual encode on YouTube uses the swapped audio files, but that means the ending music is wrong. What was the purpose of doing that this time around? Consistent times?
Seems kind of stupid to provide an audio swapped run when you had the ability to do a proper encode this time.
Wouldn't it make more sense to say "nothing" instead of "an Oxoo"?
Black isn't nothing though. A program literally drawing nothing would look like this if you drag another window across it.
That's only true in the scenario you've captured.
On older versions of Windows, (or when WDM is disabled such as Windows classic) any time you uncover a portion of a window that was previously covered it would send a request to the application to redraw that area of the window. Until it's been re-drawn, you see what was previously on that portion of the screen. On newer versions of Windows with GPU acceleration and WDM, each window is a separate layer and the rendered content of the window is retained whether it's visible or not. This was necessary for features like peek when you mouse-over a minimized window in the task bar to see what's in it. (Not to mention important for Aero glass, so they could quickly blur the underlying content without asking for everything to redraw as you move things)
Back to the topic at hand, it's 0x00, not Oxoo. Those are zeros. A 0x prefix before a number is the standard used by many programming languages, including C and C#. For clarity, sometimes it's a lot clearer to initialize a short to 0xFFFF instead of typing 65535 because then you can easily see that "oh, all of the bits are on". For 0 it doesn't really matter though. In HTML and CSS, it's the equivalent of putting # in front of your hex color.
Sorry, I read the posts linearly without paying attention to the poster names. So I thought the answer to the "Why do you need crc32?" question was for telling the two oracle games apart, and provided an answer for how to tell the two games apart.
After looking up again, I see those were two different conversations. But hopefully my suggestion is at least somewhat useful.
I've been experimenting with a partial hud replacement for the Zelda Oracles games - nothing fancy, just a replaced health meter and an added Maple meter. I've just run into the issue that Seasons stores the bytes I need in a different location from Ages, so either I make two flavors or I actually study case/switch flow control.
The reason Gasha Tree progress isn't included? Each tree has its own byte.
Can't you just check the title at ROM offset 0x134 for that?
Oracle of Ages is "ZELDA NAYRU" and Oracle of Seasons is "ZELDA DIN"
Compact Disc Digital Audio (CDDA or CD-DA) is the standard format for audio compact discs. The standard is defined in the Red Book, one of a series of "Rainbow Books" (named for their binding colors) that contain the technical specifications for all CD formats.
- BizHawk 1.7.0 and later are known not to work on some video cards (mainly older computers); it certainly doesn't work for me on the computer I am using now.
The machine mentioned by the user has a built in AMD Radeon HD 7640G, which should have very good support for OpenGL. I doubt this is the issue.
It's possible that recent AMD catalyst graphics card drivers need to be installed if lack of OpenGL is the problem.
This won't work out of the box. You'll get error messages like:
Error CS2001: Source file `/home/testuser/bizhawk-read-only/Version/svnrev.cs' could not be found (CS2001) (BizHawk.Common)
You'll need to supply these files yourself.
The bash script subwcrev.sh is supposed to run as a pre-build event for the "Version" project. That generates the svnrev.cs file.
I suppose bash is a requirement too then. Oh, and you'll need to have checked out from svn (or git with the svn wrapper) for the script to work. If you just did a raw download of the repository, the script won't be able to pull your SVN version number.
The version thing is a standard requirement though, even the Windows version does the same thing with its equivalent .bat file.
Feos PROVED that it will show blinking because of the frame dropping algorithm youtube uses.
So it makes uploading in 60fps rather than 30fps deblinking a lot more viable - because when it's downgraded to 30fps, it shows the blinking!
But in the case of the run that this thread is about, you don't see any blinking at all. When Sonic is fighting any of the bosses, nothing happens when Robotnik is hit. You should see him flashing, or at least light up if deblinked. At least for me, it looks like nothing happens at all when he's hit.
Does it really matter? I don't know. It didn't bother me enough to acquire the proper version of Gens to watch the run against the actual ROM, I still watched the entire 30fps video anyway. If there were a 60fps version though, I would've picked it since my 7 year old desktop can play them just fine at 1080p with no noticeable frame drops.
Wow, that drama. As I always take things, and as I said in another thread Flygon was super dramatic about, once there's a proof that something is actually better, we will agree that it's better. Now I only need to test once again what we see when 30 fps blinking is youtubed at 60 fps. Note: it must be not blinking stuff, it must look semi-transparent (the exact way it looked on TVs). Hold on.
EDIT: Oh god, it wasn't not deblinked properly, it was not deblinked at all! Spike, what happened?
I think you're treating this like people are outraged about it, but that's not the case. Nobody's making a scene about it, Flygon merely brought a legitimate concern to your attention.
The video simply isn't presented well, as you've now seen, and there's interest in seeing the problem be corrected. 60fps is just the most obvious way to solve the problem since you get smoother animation as well.
Whether people prefer flashing or transparency, I don't know. I just voted for the fact that I'd prefer the smoother animation for a video of this nature.
Edit: I see what you mean about the video above. In 480p, the 60fps version looks like flashing whereas in 1080p it looks almost transparent. It sucks that HD is required for 60fps. Anyway, you already provide two variants of this run. Is it a huge inconvenience to offer a separate 60fps version for people who want it? Do you need someone to "donate" the upload in these cases?
Someone complained that the official upload isn't 60fps, so I decided to completely stuff up my own encode in such a way that it still somehow caps at 1080p.
'course, since the 60fps mode feature seems to cap at 1080p anyway, I've done my job.
60 fps on YouTube does nothing we might be interested in. It still can't deblink, so virtually it's the same 30 fps footage, just tweaked somehow.
Flygon's encode runs fine for me at 1080p60fps, and my machine is 7 years old. 60fps YouTube video just requires a video card capable of hardware decoding. The current published video isn't even de-blinked properly, you can't see anything when Sonic hits a boss.
High speed games like this deserve 60fps encodes. If someone can't handle one now, they probably will be able to in a few years. I would prefer to see 60fps as well. Why not just offer both?
Just wanted to add my opinion on this subject, since I watched the run and enjoyed it.
Download latest code from the portable branch.
1. Open BizHawk.sln in Monodevelop.
2. Click Build.
Any native cores (Genesis, SNES, QuickNES, Lynx, GBA, GBC, GB, N64, Saturn, etc.) will not work unless someone ports those to Linux.
Their hashes are for the entire disc yes, and while slow I do think we want it, a bad disc dump can (like any bad dump rom) have the read error anywhere, just testing some sectors / files on the disc is not enough.
I think the point is just to identify the disc, so we know version Y of game X is supported, not to tell you that your dump is bad. There are already tools to verify the dumps themselves.
The next question you'll probably ask... It looks like color wants a number from you. 0 is going to be black, if it accepts it, 0xFFFFFF will be white. Otherwise 16777215 should be white.
Not exactly user friendly, but oh well.
Sappharad, I was reporting the issues I experienced in case it could help with the development, even if it could just aid in prioritizing UX bugs. Unfortunately there's a lot on my plate (as always) and I'm not able to provide any support. The most I can do about the flashing screen is record a video. But that will just show a symptom.
Yes, I understand. Most of it hasn't been documented and I just wanted to be chime in as to the reasons for some of the rough edges. It deserves to be fixed but my time is spread between a lot different projects. (and a backlog of games I've bought and not played)
I've been trying to spend a few hours every Tuesday on the OS X port, but lately I've been stabbing in different directions each time and never actually finishing one thing. For awhile a couple of times I tried to get the mupen64 stuff ported and stashed away some partially adjusted but unbuildable code. A couple weeks back I started trying to get Lua working by upgrading to a newer Lua library that has support for OS X and Linux, but had some unusual runtime issues with that.
Yesterday I finally found where I put the native UI code that I had started on a year or two ago because this thread prompted me to give it another go. I figured that might be useful for at least basic functionality like playing games until other features are added as they're wanted. I didn't really do anything with it yet, but it's an option now. I've always been leaning towards the existing UI from windows though, because it just saves so much time.
So anyway, things still move, but there aren't really any priorities because I haven't gotten much feedback to drive that.
The first time BizHawk is started on OSX, it consumes 100% CPU time on a single core for approximately 60 seconds, before showing the main window.
Also after the first time starting the app, the native file select dialog refuses to accept focus.
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.
The screen flickers uncontrollably. The display configuration options don't seem to provide any solutions.
No controller inputs work. Configuration is default (keyboard).
I also have trouble with loading a NES ROM I wrote; when loading the .nes file, BizHawk shows a broken "Choose File From Archive" window: http://i.imgur.com/XdYJYY9.png The emulator happily crashes if I hit Ok in this window. The only way I can actually load the ROM is by zipping it. :\ Here's the ROM, zipped because it's tiny: http://www.kodewerx.org/tmp/test.zip
Most of these problems are things I'm aware of. The OS X port isn't intended to be good, it's just intended to be usable. It really needs a native UI, which it doesn't have, and I haven't really improved the wrapper around the WinForms UI for the last 18 months or so.
I've seen the 60 seconds thing, but it only happened to me once and it wasn't obvious why. It was just frozen on some XML deserialization code to load the config, and after I let it sit long enough it never happened again so I assumed it was related to the fact that the first time I happened to me was after upgrading to one of the Yosemite developer previews.
Focus issue is worked around by switching focus away and back to the dialog.
The OS X Native Menu bar responsiveness is due to the butchery that I use to wrap WinForms inside of MonoMac. I was told I couldn't do it and it wouldn't be possible, but I went and did it anyway. The problem is that BizHawk runs entirely on the main thread, so I need to give it a few ms every frame to let the menus work at all. They're ok, but not great. Once again, a native UI would solve this. It's the same thing regarding menu states and updates. I suck the menu content out of the WinForms app and translate it to OS X menus when the app starts. I also trap the menu changes, but that doesn't cover everything. A lot of the menus in BizHawk update via an Opening event, which there really isn't an equivalent to on OS X. (Apart from Activated, which is the equivalent of the Opened event that occurs after the menu has already opened. Most BizHawk menus update before they open.) This is something that could be improved if I hook into some more calls, but never really went and did.
I've never seen any flickering issues before, both natively or in VMWare. Not sure what to tell you on that without some more details.
All controller inputs need to be configured in the control config dialog before you use them. The defaults are all based on the Windows key names, and many cases those defaults don't match the Mac key names. I didn't bother creating Mac defaults for the default config file.
The problem with tiny files I've seen as well. It's an issue with the library I use in the OS X version to read 7-zip and other archives. (The one on Windows invokes a native 7-zip implementation, for the portable branch I switched to a different one written entirely in .NET) BizHawk by default will ask the archiver if it believes the file you tried to open is an archive so it can decompress it. It misidentifies a lot of smaller files as being archives when they're not and tries to decompress them. This could be improved, I usually just load the compressed versions of games I know are misdetected.
In short, yes, there are a lot of annoyances when it comes to UI on OS X. I haven't really attempted to improve them in the past year or so, I've basically just tried to keep up with core changes for the last year and keep the code building and occasionally try to get some of the native cores building. Staying caught up was my main priority, I was hoping at some point that someone else would be interested in poking at it because building a brand new UI was a rather massive undertaking and if that were to happen it would have almost no chance of ever being in sync with Windows. That's the justification for the shitty wrapper, although I still was hoping to improve it at some point.
If you want it, you can always grab the source from the portable branch in SVN and use the completely un-wrapped WinForms UI. The menus and dialogs won't be native, but the UI will be slightly more responsive in some cases.
Ok so i seem to keep crashing. every time i change settings, and i am wondering if anyone could add me on Skype so i can get a detailed description of what is happening
I don't have Skype.
Can you explain what you're doing? Not very many people use the OS X version, so any posts here could probably be helpful. The crash report text might be useful too, but probably not.
It may have something to do with the fact that recently Dolphin started emulating load times correctly, they more accurately represent load times on the actual console. Previously everything loaded really fast. This may contribute to your problems where things had worked before.
The blunt truth is your computer and/or graphics card is too old. To support it we will need to put in a directx fallback. This is a LOT of work, to support very few computers still in use. I'm sorry, but that's hard to prioritize.
Hi, sorry for the long wait. The computer I used was a "MacBook 13-inch, Late 2009".
No worries though, I got myself a PC instead, and BizHawk is running fine :p
Glad to hear you found a solution.
One thing to keep in mind in the future.... I forgot to mention that you can install Windows on any Mac and dual boot with both operating systems. I do this myself, it's good for running games that aren't available on OS X.
