Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
For that screenshot, it looks like this game would be more accurately portrayed with a 240px wide screenshot. Uzebox software can choose its own pixel width in pure software, so Uzem just outputs 720px and calls it a day...
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
MESHUGGAH wrote:
But the issue is that I'm forced to stay in the same non-sync setting otherwise the dialog pops up until there is no savestate with previous non-sync setting.
.
Right. That's what you said the first time. And I'm not unsympathetic to it, but there's clearly a workaround that you can use: Don't change those settings.
As far as the dialog goes, we're going to change it so that aborts/bails the TASStudio session. Until that happens, you can use CTRL+ALT+DEL and force close the application for the same effect.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
MESHUGGAH wrote:
3. There's an unrequired "Memory consistency check" that fails if you change anything in the "sync settings" like the drawing color which has nothing to do with a TAS.
Ehh... I could do something about this, but it's non-trivial to fix and it's honestly not something that should be an issue. The non-sync settings really don't affect sync, even though they're in savestates, so there won't be any issue with the published movie since it's not savestate anchored (if it is, never do that ever; it's a bad idea for many reasons).
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
ais523 wrote:
The actual time should be determined via the most accurate available method of replaying the run
I've been considering this one for a while for other non-N64 consoles. The official timing should be, at a minimum, an output from the emulator that's read after the run is emulated. This handles VFR consoles well, like the NES; since turning rendering off and on can change the skipped dot pattern, you don't know exactly how many cycles a run took until the emulator has played it back.
Another example is the GameBoy, where we regrettably use a method of input timing that makes it much more difficult for TASers, in order to get more accurate timing -- but that's simply because the timing that TASVideos uses is coming from the wrong place altogether.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Ethan White wrote:
Mupen basically never desyncs like that. It only desyncs if you load state or save state or something stupid on the first frame of the TAS.
Bullshit. I've had multiple "who knows what happened" desyncs encoding Mupen.
Ethan White wrote:
this only happens if aero is turned on. Just turn it off.
Bullshit. I've had it happen on Windows 7 with no aero. (This may be GPU plugin specific).
Ethan White wrote:
that's annoying but can be avoided by not putting anything in front of the Mupen window.
So my computer is entirely unusable for the length of the capture job, cool.
Ethan White wrote:
There is an AVI-splitting version of Mupen. It Only splits 26 times (which is annoying), but it works.
Let me guess, it's available as binary only on some dude's geocities website? I like that though, it shows the utter incompetence of people who decided to modify Mupen; you know you have a splitting problem, so you make a splitter... and you give it a limit of 26 splits. Heh.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Blazephlozard wrote:
(a picture)
Vivid has way more saturated yellows and blues than your photograph. I agree that the red hue seems off. From other images, I've seen that vivid greens are way different on vivid vs real hardware.
Blazephlozard wrote:
(shouldn't GB TASes be encoded with a yellow-green filter then?)
Doh hoh hoh... That's actually a good question. I don't know.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Non5en5e wrote:
natt wrote:
Swordless Link wrote:
The solution is obvious. The "BizHawk or bust" rule is a failure, and people who actually TAS N64 games clearly dislike it. Allow Mupen (even if BizHawk is still preferred), or risk not getting new N64 runs on your site. Easy.
Does that mean you'll go away forever? Because that sounds awesome!
What a very logic and polite way to challenge somebody else's position...
There's no challenge. The goals of the TASVideos community and the SM64 community are not compatible. I agree with the position; SM64 speedrunners should stop submitting movies to TASVideos and TASVideos should stop publishing them.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Swordless Link wrote:
The solution is obvious. The "BizHawk or bust" rule is a failure, and people who actually TAS N64 games clearly dislike it. Allow Mupen (even if BizHawk is still preferred), or risk not getting new N64 runs on your site. Easy.
Does that mean you'll go away forever? Because that sounds awesome!
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Radiant wrote:
So it's a poor man's version of GTA made for a poor man's SNES, and many years after both originals came out? That's kind of weird.
I like the run. It's short enough to stay interesting, and the part where you 'chase' the guy by staying ahead of him is funny. Yes vote.
Uzebox has a vastly superior CPU to the SNES, but all parts of video rendering (down to sync generation) and audio rendering are done in full software. The end result is much closer to a NES in raw power, although much more flexible.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Saturnus core is slower than the original Mednafen core it was based on, which was already slow. At least it's stable. That CPU is at the cusp of usability, depending on game.
I know some possible ways to make Saturnus faster, but there are a lot of other things that need doing too.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
It's a tricky question, as the GBC's LCD is not backlit, and so color output depends on viewing environment. Using the Gambatte preset will give a color output that, when viewed on a properly adjusted computer monitor, will appear to the human eye as reasonably close to how real GBC hardware appears in average lighting conditions.
If there's a slightly more accurate palette that the community would like to see used, I'll gladly add it to Bizhawk, but the idea that a real GBC screen could output a gamut anywhere near sRGB (what the Vivid preset gives) is patent nonsense.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
PikachuMan wrote:
For OpenAL in BizHawk 2.0, shouldn't openal64.dll be used?
BizHawk 1.13 and earlier used openal32.dll for OpenAL.
I don't know offhand what the naming convention is for various OpenAL related binaries, but I don't have to check; if Bizhawk was trying to load a native binary for the wrong bitness, it would not work at all. But OpenAL output works in Bizhawk 2.x.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
CasualChris wrote:
natt wrote:
CasualChris wrote:
Mega Man X3, Mega Man X, Mega Man 7, and Super Mario World. Just a bunch of basic stuff that worked completely fine in Snes9x up until today.
Snes9x wasn't in Bizhawk until 2.0...
Mega Man X3 won't work and has always crashed the Snes9x core since it was released. The others should work.
I noticed that MMX2 does not work either. Is it because of the chip that renders the wireframe models?
Yes. Snes9x handles the chip well enough, there were just differences in how Snes9x was put into Bizhawk that caused the issue. The next release will put force both of those games to the bnses core
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
TASVideoAgent wrote:
Note for encoder (probably Spikestuff): Please use the Vivid color palette. I think the TASvideos encode used the default "Gambatte" palette, and I don't know exactly what it's supposed to be, because Charizard isn't pink, he's orange
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Certain games are known not to work in our Snes9x core and are being set to the Bsnes core only in the next release. What are you trying to play that crashes in Snes9x?
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Pokota wrote:
Because native compilation is better than having to run it through a compatibility layer. Even if we still end up piping (and having to recompile a heluva lot of plugins), having x64 avisynth will be better than x86 avisynth.
This brings up an interesting point, though. Were all the tests done with piping, or just the x64 test? It'll be easier to compare if the only change is architecture.
What compatibility layer? All cpus with the x64 instruction set fully support the x86 instruction set at full speed. SysWOW64 might ding you a few cycles on syscalls, but that will hardly be noticable.
Like with x264, there's a maybe 5-10% speed gain down the line due to x64 being a better instruction set. But that's it, and x264 does have a lot of hand tuned assembly to ensure that bonus that avisynth does not.
There are a lot of good reasons to clean up (or replace!) avisynth, but don't be expecting speed gains at the end of the tunnel
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
feos wrote:
Note that x64 build of x264 required piping, because there's no x64 build of avisynth 2.6+. If someone helps us move to an avisynth fork that supports x64, that'd be extremely helpful.
Why would it be helpful? When I did encodes, the piping was an advantage, not a disadvantage. You get some multiprocess speedup, and it's more stable because avisynth, a notorious memory stomper, is not in the same process as anything else important. You can also flexibly upgrade builds of x264 without needing anything special in them.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Alyosha wrote:
Alright, I just updated gambatte with a fix for pocket monsters.
Also, I updated console selection in the GB menu so that you can now pick which console you want to boot your game in.
'Default' boots according to rom extension.