Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
If you made it twice as big, it wouldn't fit on the screen.
If you made it twice as big, it wouldn't fit on the screen.
If you made it twice as big, it wouldn't fit on the screen.
If you made it twice as big, it wouldn't fit on the screen.
If you made it twice as big, it wouldn't fit on the screen.
If you made it twice as big, it wouldn't fit on the screen.
If you made it twice as big, it wouldn't fit on the screen.
If you made it twice as big, it wouldn't fit on the screen.
If you made it twice as big, it wouldn't fit on the screen.
If you made it twice as big, it wouldn't fit on the screen.
If you made it twice as big, it wouldn't fit on the screen.
If you made it twice as big, it wouldn't fit on the screen.
If you made it twice as big, it wouldn't fit on the screen.
If you made it twice as big, it wouldn't fit on the screen.
If you made it twice as big, it wouldn't fit on the screen.
If you made it twice as big, it wouldn't fit on the screen.
If you made it twice as big, it wouldn't fit on the screen.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I count 52px of titlebar chrome on bizhawk, 29px of statusbar chrome, and 40px of taskbar chrome. (1080 - (52 + 29 + 40)) / 2 = 479.5, so you're one pixel short. Sorry! You can't go on the ride.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
RaijinXBlade wrote:
1080
480x2=960
You'd have to have 120px or less of total chrome for that to fit. Exact amounts vary, but the least I can manage on windows95 theme (which is much slimmer than most newer themes) and a single height taskbar is 100px. Double height taskbar already blows that out.
So it's reasonable to expect that you can't do math. Inability to do math is a common issue.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I made a proof of concept Bizhawk integration a long time ago. It played games with working video, audio, and basic input, but there was a lot of work left to do. I chose not to pursue it further at the time because PPSSPP was under very active development and I felt it would be better to wait for them to resolve a lot of their own stuff first.
There's been no work since then. If you really want to see PPSSPPBizhawk, you'd be better off starting with a version of Bizhawk that actually had it, but there's really nothing to see; it's just PPSSPP but with a lot of stuff not working. Most notably, there was no attempt at savestates, so there is no TASabilty.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I don't think you understand what you're asking for. An OnMemory* callback exists to let you do things before the native memory action happens. Right after you return from it, the native memory action happens. Advancing the emulation clock from inside such a callback isn't just impossible; it makes no sense.
The usual way to do what I think you're actually trying to do is to set a flag inside the callback, which the rest of your code can respond to later.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I remember byuu ranting back in the day about snes9x developers copying bits of bsnes without looking at the big picture of emulation accuracy, and so accomplishing nothing... I guess they didn't learn their lesson.
The good news for bizhawk is that bsnes compat core is faster than it was and the determinism issues are gone, so snes9x isn't actually that important to us.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Shentok wrote:
Will 3D Pad support be available with the update to the Saturn core as well? I'd like to be able to have that for a couple of games I'd like to experiment a TAS with.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
feos wrote:
You can't answer these directly?
What are you talking about? I'm not sure how much more plain I can make it.
The output from the emulator will be 160 pixels wide. Stretch it so it is 275 pixels wide, without altering the height. This will be correct 100% of the time for any NTSC game on any NTSC 2600. The end. Stop imaging complexity where there isn't any.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
feos wrote:
I dunno if I want square or not, I want a setup that would be correct and reliable. I doubt the picture on a TV gets different cropping depending on the generated height. Probably we shouldn't crop a all? Or crop differently?
I'm not sure what you mean by reliable; are you afraid that the encoder is going to sneeze on his keyboard and type the wrong number? There are no random factors here. As far as correct goes, what I just posted is correct, so use that.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
feos wrote:
So maybe our encoding isn't right? Like, we had to add overscan to SMS manually to make the output match the TV, otherwise it's aspect ratio was completely wrong.
http://tasvideos.org/forum/viewtopic.php?t=15855
Maybe we should figure this out for atari too? Variable cropping doesn't sound like a prudent solution.
What do you mean, figure this out? All of this information is known and has been known for a very long time. The metadata that the 2600 core puts out is correct for NTSC; if you want square or as close to square as you'd ever get pixels, stretch the output image, originally 160px wide, to 275px wide.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
phoenix1291 wrote:
1.13.0 (movie recorded and played in this version),
Make movie,
stop movie,
load movie,
record avi/wav,
set video size to 800x720,
mute sound,
play movie,
Yeah, sorry about that. Workaround: Don't change size at all. Will be fixed.
I honestly didn't write that for Byuu's benefit, just the benefit of other people that might be interested. As for his reply, I didn't read past the "it's possible" in the first sentence. We've got years of experience from many TASers and multiple developers working on this core to demonstrate these facts. Byuu is like a climate change denier but for emulation determinism.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
creaothceann wrote:
Btw. a query:
RunToSave has never worked correctly over the entire life of bsnes. This was well known when the first bsnes movie was accepted to this site; if you pounded the savestate button a few dozen times at the beginning, the run would desync. Byuu has been presented facts about this a number of times and has flopped between viewpoints as needed, including denying the bugs, blaming them on the installation, and downplaying them as not significant for most users.
The best example I can think of is Tales of Phantasia. It uses a uniquely difficult sound engine that crashes the emulated game and in some cases even the emulator when you savestate too many times. This is 100% repeatable on any Bizhawk build of the appropriate version: Turn on 1frame rewind, load the game, and watch the attract always crash on the exact same frame <6000 frames in (the exact number escapes me now...). I fixed the emulator crash https://github.com/TASVideos/BizHawk/commit/451f786660744835be868c7fca91ef3fc33db687 but the game still crashed; then I fixed the game crash https://github.com/TASVideos/BizHawk/commit/587270cad2ec96eaeec0ae60e4247c31a0a06a2e (note: there are two commits before it that are also relevant; see end). The exact problem was completely plain under a debugger, and once the fix was implemented it never happened again in Bizhawk, but according to Byuu that couldn't possibly have been it because the game works in Snes9x, which is much less accurate!
Some other things are heavily broken too, all with the same MO: The game will work fine with no savestates, but the moment you start savestating every frame, things break. Super Game Boy, audio on some Rare games; Sonia knows more if you're interseted http://tasvideos.org/forum/viewtopic.php?t=19031
Besides complete breakage, there's also a lot of desync potential where a game will continue to run but handle timing subtlety differently. I believe Ilari has mitigated this by a combination of ignoring savestate requests at certain times and only taking savestates at known "good" times that happen to work out better, but I'm not sure; he's not the most cooperative and his code is impenetrable. Those solutions would be more duct tape and pray anyway; you still don't have something that is taking correct savestates.
End: Here are all of the commits that I ripped out of bizhawk that were related to our coreside fixes for libco savestate problems:
a60be7d2c9818229a0dcff0dbccf15f31015ca2a
a7b6a9af4d4c049dbcd775f05f8539f86456e5e9
57b1df8487e3102b2e81c75fb96640cb1da430a4
9119e4f4ea7661b555125f8d6023efda8f6ed704
b2c0910376657208acb325953fbb2dbd4957d5e1
587270cad2ec96eaeec0ae60e4247c31a0a06a2e
74c26d9b117d3bdc78f5e5247909c9a05dee2a98
5e3d6555b02b1d6a6b61d8aeb3617e256697cd01
451f786660744835be868c7fca91ef3fc33db687
There might be more of them, and I know there are frontend commits as well, and many other issues that we just didn't solve.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
hegyak wrote:
Is the NeoGeo Pocket Color Emulation really that good now a days? Because, I remember Card Fighters Clash having graphical issues and timing errors (Too fast Vs. Physical Device).
But, I look forward to seeing it happen all the same.
It's not an overly accurate core. The savestate determinism should be much better than before.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Alyosha wrote:
My opinion though is that at some point we really should be raising the standards of accuracy for NES submissions, especially with Mesen becoming available, otherwise we'll never advance console verification.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
There is not, that's built into the console. You'll have to do whatever a real console gamer would do (of course, you can make a backup of any saveram file you want to keep first).
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Take a Bizhawk Octoshock (PSX) saveram file and split it into two halves, each exactly 128KB. They will be valid MCD files that work in other emulators.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
The file has a name something like "Suikoden.SaveRAM" and you need to copy it and give it a new name something like "Suikoden II.SaveRAM" but the exact name will depend on what's in the game database. If you're not sure, start a new game in Suikoden II from scratch, save it, and see what name it comes up with.
Edit: Glad it worked out. To explain what happened: As a convenience feature, Bizhawk gives you separate memcards for each game you play. Usually it works out well, but in a few situations like this you need to do a bit of extra legwork.
