TASVideos

Posted: 9/7/2015 7:50 PM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

i can't debug that xml. bizhawk's debugger is incomplete garbage. test it on bsnes 0.87, that's what we're based on.

Posted: 9/2/2015 8:04 PM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

is your ai evolving to something that can crash bsnes? are you resuming the ai after it crashes or just starting it from scratch

Posted: 9/2/2015 5:37 AM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

How did you get the in-game timer to match the frame counter anyway? That doesn't make sense. The game isn't even running yet at frame 0, the bios takes some time to load it. Then the bios takes some time to boot up. Anyway, that's not evidence of a timer running way too fast without another data point. It could be evidence of the clock being offset by 4 seconds, depending on what point it begins at. It is not a setting problem on your end. If this is real, it may be a bug. Mednafen may be running some longer or shorter frames than psxjin but that would probably only happen during loading and mode switches, it should be stable within a scene, and it would only create an offset, not a problem with the speed. I would be amazed if the game was doing anything but counting vsyncs for its timer. It's hard to see how mednafen or psxjin either could get this wrong. But note that counting vsyncs may be hard on the psx (according to psx-spx), and an emulator with different timing may be stressing the bios's vblank irq and making the game lose vsync counts. It would be impossible to judge which emulator was more accurate without comparing a real console to a stopwatch, but we're not going to be questioning mednafen's timing here. It's more likely to be the exact emulator with the naive timing. Perhaps you can google for more information on the FF9 in-game clock not matching reality. If other people have noticed that, then it would be proof psxjin was wrong, right?

Posted: 9/2/2015 4:06 AM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

that happens when bsnes crashes. I've never heard of that happening before. Lots of folks have run mari/o for a long time. I suspect your cpu burped.

Posted: 9/1/2015 11:53 PM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

I think we've wrestled with this before on n64 (not completely sure why that one, but the problem has to do with how long the main thread is suspended). If that's it, it's related to the shell doing something unusual for sending taskbar commands. The unusual stuff wrecks it when the main thread is suspended at any point other than a message pump--in this case, it's suspended spooling data to ffmpeg. It's not clear why microsoft has to do this when it breaks so many programs (it definitely does) and is so unusual. Microsoft says we shouldnt have this problem because we shouldnt ever suspend the UI thread, but they're full of shit. Basically nobody programs UIs any other way except for mickey mouse stuff because it requires you to add logic which could essentially process commands from the UI in any random nonsensical order. I think nobody in the world fully understands this problem. I addressed it somehow for n64 in commit cfa433a9a6b8dcac9df4ae2ba3ddd63b94bf6eb2 but maybe incompletely. I think I remember deciding the win32 event wait function worked OK while the .net one would additionally run the message pump which made the main UI thread re-enter. Unfortunately I was unable to make this same workaround help for the ffmpeg scenario. This problem for n64 did only happen in windows 7+

Posted: 9/1/2015 3:09 AM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

games can do any weird thing without regard to your expectations. 2 frames sounds like the time it takes to boot up a new game mode where the loading loop is mysteriously responsive to input for no useful reason. take this to the playstation games sub-forum.

Posted: 9/1/2015 2:33 AM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

FWIW, I can't make any sense out of spikestuff's explanation, but I'm no TASer. edit: spikestuff says theres no bugs, and he just tased the game without being stumped by a cue file, so I believe him.

Posted: 9/1/2015 2:27 AM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

alyosha, I would need the original fm2 in order to debug it, but since you got it working, it's not very interesting. adituv, thanks for reporting that, but just so you know, this feature is being developed right now, right?

Posted: 9/1/2015 12:22 AM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

post url of movie youre trying to import, so we have an actual test case

Posted: 8/31/2015 11:13 PM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

if the game is running at 50fps and it's an ntsc game with an ntsc bios, then your system is inadequate, or it isn't actually an ntsc game. I cant help you if you cant figure out what *(@#ing game you have. IMO youre wasting your time until you find a disc that checks vs redump.org the ghost lag cannot be a problem due to your cue. I'm surprised to hear this, I don't think we have any problem with our lag detection. Maybe ask the guy who tased the game if it's acting odd.

Posted: 8/31/2015 9:13 PM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

use the built-in hashing functions and rom status report to investigate the disc image you have. mednafen is not usually working when you have a mismatch between bios and game, but bizhawk shouldnt be offering a game the wrong bios unless you've done something foolish like accept a bios it doesnt want in the firmware manager.

Posted: 8/31/2015 4:30 PM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

add all 3 items to github bug tracker, but dont expect remembering the last domain to work. it's kind of incompatible with multi-system emulator conecpts. For #1, we might show an icon instead of a checkbox

Posted: 8/30/2015 2:33 PM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

have you tried client.SetGameExtraPadding to give yourself a reliable margin for drawing OSD stuff? It'll get scaled with the game. I might could make something similar which doesnt get scaled. I cant promise it works well in whatever build youre using, I'm continually fiddling with it

Posted: 8/29/2015 2:59 PM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

The other emulators are stupid. The xml contains the information that references all the other files. It's the package file, if you will. Doing it any other way requires checking the disk for accessory files every time you open a .sfc, just in case it's an msu-1 rom.

Posted: 8/28/2015 9:10 AM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

yes, youre missing the help menu and the lua functions list box

Posted: 8/28/2015 6:47 AM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

I've only tested it with super road blaster (load SuperRoadBlaster.xml), which was state of the art at the time we forked our bsnes. Im sure higan has gone through 10 format changes for loading msu-1 games since then. I only intend to load xmls, but if you can prove the community of weirdos making useless cd-audio msu-1 romhacks have converged on some other defacto format/solution then maybe I'll listen read more here http://forums.nesdev.com/viewtopic.php?f=12&t=11004&start=60

Posted: 8/26/2015 5:39 PM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

wiggling sticks?

Posted: 8/25/2015 9:43 PM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

Why are you trying to press keys to bind analog controls

Posted: 8/25/2015 8:32 PM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

TILT came out of the joypad controls table. To tilt bizhawk, kick over your case, or bind it the same as any other control.

Posted: 8/25/2015 7:38 PM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

i dunno, check the lua libraries. Write up a bug for this one: PWD incorrect from event.onexit

Posted: 8/25/2015 7:37 PM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

Seriously? You loop over all the controls and print them out. At some point "tilt" gets printed. Now you wonder if bizhawk supports tilting? Of course it does. You print everthing it supports, and it started printing tilt. Stop looping over all the controls and just print the ones you want. Finally, i dont know why, but in the meantime you can use 0xFFFFFFFF. You know, like the example lua scripts provided with the emulator do.

Posted: 8/25/2015 6:41 AM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

the file may not be getting opened from the right PWD. directory. use fully qualified paths or use process monitor to watch for random_name.txt and verify whether the wrong PWD is getting used for onexit

Posted: 8/25/2015 6:39 AM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

That code only runs when the game changes resolution. If it fails, it's probably your video driver's fault. Upgrade or downgrade your video drivers, or wait for the next version of bizhawk.