Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
All the determinism hack does is forces a savestate to be taken every frame, even if the frontend did not ask for one. As a result, it makes things slower. It's required because the savestate code in BSNES is worthless junk, and it breaks some things because the savestate code in BSNES is worthless junk.
The same bugs do exist on lsnes; you used to be able to desync some movies by taking extra savestates. That may have changed with more recent builds; I think lsnes ignores your savestate request sometimes as a different hack around.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
That's not clear. Once the ACE breakout occurs and the initial payload is sent, the rest of the movie has no logical connection to to the original game. It's not a superplay because it's not even a play. Any payload as possible so long as it meets the technical restrictions of the system, and the rest of the movie is something that belongs on a demoscene exhibition.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
sappharad is aware of issues specifically with the Bizhawk snes core and is working on it. Might be fixed with time. Most of the others, you're probably SOL on; OSX emulation isn't that popular.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
4 way link is new emulation development; might be difficult. 2 way link with more than 2 total carts and connections that can be plugged and unplugged is much simpler; all the complex work has already been done. How useful would this feature be? Are there many games that could do something interesting with it?
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
At one time I was a contributor to the PrBoom-Plus project and implemented an exact capture system in it. If that code is still there and still works, it would be superior to kkapture.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
No such offset exists for mgba. workram is allocated on the heap.
The offset should exist for vbanext. I'd expect the workram to be in .bss or something similar. I'm a bit rusty on win32 PE, but anyone that would be able to do something useful with the memory offset should be able to easily find it themselves.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Alyosha wrote:
I'm getting this exception in the most recent Dev Builds whenveer I open the emulator or load a game (any core):
System.InvalidOperationException: Sync mode is required
at BizHawk.Client.EmuHawk.SoundOutputProvider.set_BaseSoundProvider(ISoundProvider value)
at BizHawk.Client.EmuHawk.Sound.StartSound()
at BizHawk.Client.EmuHawk.WinFormExtensions.FormExtensions.ShowHawkDialog(CommonDialog form)
at BizHawk.Client.EmuHawk.MainForm.OpenRom()
at BizHawk.Client.EmuHawk.MainForm.OpenRomMenuItem_Click(Object sender, EventArgs e)
at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
at System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e)
at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
at System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met)
at System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met)
at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
at System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
at System.Windows.Forms.ToolStrip.WndProc(Message& m)
at System.Windows.Forms.ToolStripDropDown.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
EDIT: Things seem to work if I comment out the exception
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Everyone has their own opinion about whether FFXII is good or not, but I think most people would agree that it's much different than all of the other FF games, including FFX, FFXIII, and FFIX and below. So I can't say whether or not you'll like it, but I can say that if you don't like it, it will be for different reasons.
I personally liked FFX quite a bit, and FFXII is one of my favorite games of all time. I thought FFXIII was utter dogshit.
Sorry, but is it just me or is the download link dead?
Edit: Ok, downloaded from http://tasvideos.org/Bizhawk/ReleaseHistory.html#Bizhawk11191
Edit2: Ok, for real, this is what I did.
1. Open BizHawk 1.11.9.1
2. Open the Rom Keitai Denjuu Telefang 2 - Speed (Japan).gba
3. Load this savestate https://drive.google.com/file/d/0B-2O13fpsnI4ZlNlZ3ZZOC1sYUk/view?usp=sharing (either drag it or place it on folder)
4. Press "A" to start the battle
5. Press "A" to get into battle:
6. Click the menu bar -> GBA -> GPU Viewer
7. Click the "sprites" under "available widgets, then click "refresh" button. You should get this:
It doesn't occur when the trainer occurs; only once the monster is summoned. No idea why.
Edit3: Works fine on VBA-next, so it's mgba core.
Edit4: Viewing tiles in the mgba emulator itself (not BizHawk) seems fine. Hm.
Fixed. It was actually a frontend issue. The game asks for sprites that creep slightly past the end of VRAM, and the viewer didn't bounds check, so it read a little pixel garbage off of the end of VRAM. Depending on the memory layout though, that could be in an invalid host memory area and trigger an access violation.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Mothrayas wrote:
Sync note: due to a bug in the mGBA code in BizHawk regarding RTC configuration, the movie may desync depending on the timezone it is played back on. I verified that it synced with a system configured to timezone GMT-5 (US Eastern Time) while it desynced in Fortree Gym at my native GMT+1.
I'm looking into this. I've run some movie time in a debugger and it isn't doing anything different on timezones; the code in question is timezone agnostic, as best as I can tell (I've been wrong before, but it's only 3 lines...)
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Weegeechan wrote:
So, is it confirmed to work or is it not implemented fully?
Neither of the above. I implemented to a spec, which apparently isn't enough for at least some games, but no investigation has been made into what is missing. If it needs subframe input, that will be hard unless we can fake it somehow...
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Weegeechan wrote:
Hey Alyosha, have you ever considered emulating the Famicom controller 2 microphone? There is a decent amount of information on it and it seems possible to emulate in some way. There is only a small amount of games that seem to use it but it could be useful in FDS Kid Icarus and the FDS Legend of Zelda.
The microphone is already implemented and has been for a long time. Is it not working for you?
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Aktan wrote:
To make matters worse, when you convert back to RGB as most displays are or YUV4:4:4, the upscaling of the chroma is probably not using point resize either, adding some color bleeding also...
This is the real killer for 4:2:0. It doesn't matter how smart you are when encoding; the playback software is going to stomp over that and make film-based assumptions about how to filter the chroma.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Warp wrote:
feos wrote:
I'd prefer to hear counter points to using C#.
Nowadays when developing a web server backend, it's usually a good idea to use a popular well-tested framework (such as for example Symfony) instead of programming it from scratch.
If you look at Wikipedia's comparison of web frameworks page, C# is conspicuously absent.
I don't want to get involved in this discussion, but as a point of fact C# is literally the first goddamn thing on that fucking page you linked did you even fucking read it
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Gamer Maiden Sonia wrote:
Aktan wrote:
Honestly H.264 in AVI is an hack and shouldn't be used unless B-Frames are turned off, which would be true if you are using lossless mode.
Warepire wrote:
That's because AVI isn't meant to contain video encoded to x264.
If I understand correctly, it's not a good idea to choose either then?
I know the x264 codec has 7 VFW FourCC options:
H264
h264
X264
x264
AVC1
avc1
VSSH
If I can't pick H264 nor x264, what should I pick then?
The fourcc used isn't the problem. AVI cannot properly support mpeg4 part 10 aka h.264 aka AVC aka whatever you want to call it, regardless of fourcc labeling. You should not use that container to store that format.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
DeHackEd wrote:
Here's an idea I sorta made up just now. There's an arcade game I play where the real hardware runs too many frames per second, at over 61. When the NTSC signal is recorded on most capture hardware it outputs at 59.94 or 29.97fps and frames get dropped. This was easily noticed because the game has a built-in timer with 0.01s accuracy. The NES runs at ~60.1 fps, so maybe the framerate of the provided video can be useful? If it's not a recording standard, or if there's no dropped frames to account for the framerate variance, you may have a smoking gun.
I worry that this method can lead to false positives if a particular china special capture card has unexpected timing parameters, or if the user inadvertently processes the video in a weird way through Vegas or whatever. On the other hand, a skilled forger would easily know what timings are to be expected, and could carefully post-process the video to make it work.
You can find smoking guns sometimes; the best ones are emulation defects not present on real hardware. But there's no way to give the "VERIFIED NO CHEATING" guarantees that some sites claim.