TASVideos

Posted: 10/22/2018 12:31 AM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

Depending on your point of view, this may never have been fixed. Things are complicated. Use this pattern: OnFrameStart: joypad.get (will be unmolested physical values) Calculate new buttons joypad.set (new buttons) OnFrameEnd: joypad.set({Start="",Up="", etc)) --"rests joypad to normal" -- this actually clears the stickies set by OnFrameStart, but the timing is important and must be done by OnFrameEnd MainLoop: while true do emu.frameadvance

Posted: 3/14/2018 1:10 AM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

There is no such option, because the mednafen PSX core lacks such an option.

Posted: 11/7/2017 2:54 AM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

Who can tell the future? I can only tell you that not even I have ever built a waterbox core, so it's in a pretty bad situation. I think he does it in linux, maybe the setup steps spew shit all over your system like gnuware is prone to do, so it can't even be readily uploaded?

Posted: 11/7/2017 2:49 AM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

That won't work. The memory card file is read once only when the game boots. You need to use a PSX memory card manager tool to combine save files from several bizhawk saves into one memory card. You would name the file what the file needs to be. It creates the file it needs to have. Think about it.

Posted: 10/17/2017 12:00 AM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

Cheats are so broken that I say they're completely broken. If they work, then you get lucky. Your screenshot is a problem with the hex editor, not the cheats. I don't see any problem with endianness. If you are able to manually enter any cheats which work, but yet you cannot use the cheat converter to achieve the same results as that manual cheat, then submit that as a bug in the cheat converter. If a manual cheat works, then great. I'm surprised. if a manual cheat does not work, then I'm not surprised.

Posted: 10/14/2017 2:30 PM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

Any cheat code that you can manually apply, but yet the converter deosn't work, you can post a bug about on the bug tracker. "doesnt even work when i manually apply cheats" or "doesnt work at all" we already know about.

Posted: 10/14/2017 2:29 PM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

It's actually as simple as adding the file path in the target for the romfile, both for bizhawk, and for virtually every program made for every operating system in all of history.

Posted: 10/10/2017 9:23 PM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

cheats are all broken right now. don't discuss it in another topic. use 1.x if you need cheats.

Posted: 10/9/2017 2:19 AM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

I tried getting the mupen64plus-core/src/r4300/x86_64 to build and that entire module (even the 32bit parts) looked trashed and out of date. I dont know what we used before. I need someone who knows what's going on in the mupen core to tell me how in the world our recompiler used to work.

Posted: 10/5/2017 1:38 AM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

something installed a slimdx.dll to your windows system32 or syswow64 directory. It should not have done that. Remove it. If you find out what did it, put that dll in that application's directory and you'll probably fix it (after having broken it by removing it from the windows system directory)

Posted: 10/5/2017 12:23 AM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

It was certainly removed because it was impeding the 64bit transition. I see some junko in the source code about an x64 dynarec. What is that? Could the dynarec use that? Why did I think I had to take it out in the first place? I don't know, you tell me. Are there mupen64pluses that are 64bit and have a dynarec? I can't get that code to compile right now, it seems out of date.

Posted: 10/5/2017 12:15 AM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

SSD doesn't present a problem, because an SSD is faster than a CDrom in every possible case, even if it's jittery. All you need to do is buffer it to be as slow as an ideal CD

Posted: 9/15/2017 12:45 AM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

This dll got lost when we went 64bits. I just made a 64bit dll. I have no idea whether it works because I couldnt tell the difference between libdarm broken and debugger broken, and I know the debugger is always broken, but maybe youll know.

Posted: 9/13/2017 11:25 PM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

We make standard issue assurances, comparable to 99% of software. The purpose of the status message is to confirm that youve hit the key in case the savestate is instant. In case it wasn't clear, this is not a negotiable subject. We will not be the vanguard of unreliable sloshy behavior r&d innovation for the thrill of gamers. That is the _opposite_ of our mission statement.

Posted: 9/13/2017 11:02 PM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

We do not do this because we don't want something so important to be untrustworthy. When the client unfreezes, your savestate is complete. The hitching is a purposeful signal that it is safe to proceed. Confirm that you're not testing a core which is doing unnecessary buffer copies; several of them are, currently. I doubt the disk IO is the biggest use of time. That should be instant. Confirm inside a core with a large savestate by returning a preallocated array full of whitenoise instead of doing deeper work to create useful savestate data. You will see that it's now basically instant. After all that proof that it's a waste of time, if anyone adds this "feature" to make gamers think they're having more fun until less reliable software malfunctions and ruins their day, it *must* default to OFF, and be surrounded by a warning that it is an insane choice to change that option. It could be put into the rewind&states configuration, or config>advanced. In the meantime, try changing the rewind&states configuration backup and screenshot options.

Posted: 9/4/2017 9:26 PM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

I am reading it as someone not in possession of much situational awareness attempting to wish what he desires into existence

Posted: 8/29/2017 5:15 AM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

unsafe means the bounds wont be checked, and the managed code could now corrupt or crash the process. This would ordinarily be a bad idea for nice, supposedly bulletproof cores, but that ship has already sailed

Posted: 8/21/2017 10:21 PM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

By "not working" do you mean "does nothing" or "crash"? Because it definitely looks like it crashes to me. Sometimes when I debug it, it will trace a few instructions before it tries to read an address out of range from the sysbus. Maybe we lost some address masking somewhere

Posted: 8/15/2017 9:12 AM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

no, but depending on what functions youre using to draw (they dont all work the same, its a pretty schizo bunch of APIs) you might could draw to an offscreen image (or even a file) and then draw that onto the screen after passing it to some external program for rotating.. good luck. put it on the github bug tracker and maybe itll get done some day, although no promises itll work like you want or be done in a timely manner

Posted: 8/11/2017 9:54 PM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

mothrayas, the most expedient way for you to solve that that is report to gambatte upstream

Posted: 8/11/2017 1:48 AM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

My only request is that you make an effort to prepare it for a higher level of debugging quality, even though it can't be used yet, chiefly by giving it the ability to step and exit from emulation mid-frame. We're not likely to address the problem of bizhawk-cant-handle-debugging very soon, but we're more likely to do it sooner if we have a nice in-house c# core to practice with. However, this goal will come into conflict with performance. My philosophy is, if you want it to be _fast_, you shouldn't do it in c# in the first place. A fluffy c# core should be for features, instead.

Posted: 8/9/2017 6:17 PM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

I dont know for a fact that it's a game bug, but I'd judge it's a possibility. The game is using a bit of a timing-sensitive special effect there to render the rail in front of the player, on the same BG as the distance city backdrop. The glitch is infrequent enough that it could pass QA. If it happens on hardware it looks like it will be seemingly randomly. But if it helps, you may be able to verify it (check for it in the emulator first) on an earlier stage using the same effect.

Posted: 8/5/2017 9:33 PM

Quote

zeromus

Editor, Emulator Coder, Experienced Forum User

Joined: 8/7/2008
Posts: 1156

what changed was https://github.com/TASVideos/BizHawk/commit/3a4b9ed798435f26ff0afe7e72c31e574209ebc3 I can't believe these were good dumps. Please tell me which "good" redump game you used which triggered this. There may be something unusual about them.