Posts for Wulf2k

1 2 3
Posted: 1/15/2018 8:44 PM
Quote
Wulf2k
Experienced Forum User
Joined: 10/18/2011
Posts: 64
As a heads up to anybody interested, reading from the wrong CPU was confirmed as a bug and has apparently been fixed in the source.
Posted: 1/13/2018 12:21 AM
Quote
Wulf2k
Experienced Forum User
Joined: 10/18/2011
Posts: 64
And to continue with the spam, does any functionality exist to hook certain instructions and dump something to the console? Right now I can set breakpoints and tell when a checkpoint is triggered or a new data file is set to load, but I don't necessarily want it to actually break execution every time while I'm testing stuff.
Posted: 1/13/2018 12:10 AM
Quote
Wulf2k
Experienced Forum User
Joined: 10/18/2011
Posts: 64
And rather than spam the forums, I'll ask another unrelated question here. Once I've got a movie started and watch it, to see it up to its end, how do I once again start recording from that point? It would seem that the only option is to record a new movie or start adding KeyInputs individually instead of it being back in Record mode.
Posted: 1/12/2018 10:23 PM
Quote
Wulf2k
Experienced Forum User
Joined: 10/18/2011
Posts: 64
Completely unrelated thought, but I believe there are also some shenanigans to be had by opening/closing the disc tray. Are TASes allowed to take advantage of those sorts of things, and do emulators even allow it / handle it accurately?
Posted: 1/12/2018 9:40 PM
(Edited: 1/22/2018 3:18 PM)
Post subject: PCSX2-RR - Lua bug?
Quote
Wulf2k
Experienced Forum User
Joined: 10/18/2011
Posts: 64
I'm currently toying with the idea of starting and ultimately failing to create a God of War TAS and immediately ran into an issue with trying to display things on the screen. It would seem that readdword ignores the CPU string passed to it. I've created an issue here - https://github.com/xTVaser/pcsx2-rr/issues/2 However, this seems like a rather obvious issue that would have presented itself immediately to anybody the first time they tried doing anything involving reading memory with LUA. Can anybody here see any obvious issues with what I'm trying to do before I waste more of their time trying to troubleshoot it? I do plan to (eventually) get the source compiling so I can work on these things myself but my first attempt at that wasn't very productive. Finally, once that issue is sorted out, does anybody know any handy LUA commands to convert bytes that make up a dword into a float? By which I mean that I don't want (int)589033298 as shown in the screenshot there, I want the float value that 0x231bef52 represents (...which is the wrong value in the first place, because I'm reading from the wrong memory) Anyway, I suppose I'm mostly just looking for moral support in these difficult times. I get the impression that even if I get all of this working, nobody has enough faith in PCSX2-RR for it to produce a syncing TAS anyway, but at the very least I'd like to create a few TAS-showcases of shorter gameplay. As an aside, several glitches/skips in God of War rely on load timing. Does anybody know if that's system-accurate in the emulator, and with a disc-based game, is it even feasibly possible to recreate accurate loading delays caused by seeking between different areas of data on the disc?
Posted: 1/10/2018 7:23 PM
Quote
Wulf2k
Experienced Forum User
Joined: 10/18/2011
Posts: 64
I have no clue how the emulators implement it, but the actual Game Genie device is something that would run on the hardware itself. It would take up memory, and use up actual cycles on the processor to process the codes. An LUA script would happen 'outside' of the emulated hardware and not use any emulated memory. From the point of view of the emulated system, those changes would happen by magic instead of as a result of in-system commands.
Posted: 9/8/2017 4:33 PM
Quote
Wulf2k
Experienced Forum User
Joined: 10/18/2011
Posts: 64
I'm rather late to the party but I'd like to question the "Executes arbitrary code" tag on this one. This is not arbitrary code execution, it's a semi-controlled jump. Has this been a topic of discussion before? If not, I'd like to take this opportunity to arbitrarily enforce my expectations upon the community at large. ACE should be a defined 'state'. Once you can overwrite any specified memory values with chosen values and can get the processor to jump there, the game has achieved ACE. This does not do that. (Note, I'm purely arguing about the ACE tag. The achievement in this game is still amazing, just not ACE)
Posted: 8/29/2017 6:18 PM
Quote
Wulf2k
Experienced Forum User
Joined: 10/18/2011
Posts: 64
For anybody that cares, vJoy does 'work' but it doesn't do XINPUT directly. http://vjoystick.sourceforge.net/site/index.php/vxbox Creating a fake XBox controller in the first place should have much better compatibility. Time to rewrite that feeder from scratch I suppose.
Posted: 8/25/2017 9:26 PM
Quote
Wulf2k
Experienced Forum User
Joined: 10/18/2011
Posts: 64
At the moment, I'm not sure. I run TwitchPlays every so often which coincidentally has a ton of overlap with (really crappy) TASing. I've written Twitch-bridges for a few individual games/programs already (Demon's Souls - PS3, Dark Souls - PC, PS4 Remote Play - PC), and I'd like something a bit more generic, so I can just define the commands/controls and twiddle a fake joystick rather than messing with each program to find the code that handles its input. Trying to get the controls accurate to the frame/millisecond gives this a lot of TAS-overlap, so I don't feel bad about asking for it here. Most of the Twitch-strings end up being mini-TASes from a known-starting point with no control over the RNG. Depends heavily on the game of course, if you can reliably start from a position where the same inputs/durations will bring you to the exact same endpoint.
Posted: 8/25/2017 8:41 PM
Quote
Wulf2k
Experienced Forum User
Joined: 10/18/2011
Posts: 64
I'm probably overcomplicating things, but.... vJoy will handle the device. x360ce will convert it to XInput for increased compatibility. And I just need to write a Twitch/vJoy feeder application based off of this - http://vjoystick.sourceforge.net/site/index.php/dev/87-writing-a-feeder-application2 Should work. Let me know if you're aware of anything less complex.
Posted: 8/25/2017 7:54 PM
Quote
Wulf2k
Experienced Forum User
Joined: 10/18/2011
Posts: 64
Checked it out and came across this in their forums.
AHK is good at detecting joystick buttons, but can't really send them. seach the forum for PP_Joy ( i think it's called) for some other examples of emulating joystick inputs.
PPJoy seemed a dead-end as well, but reading up on it brought me to vJoy - https://sourceforge.net/projects/vjoystick/ Haven't looked into the mechanics of it yet, but it should be a good start. Thanks.
Posted: 8/25/2017 5:14 PM
Post subject: PC - Virtual gamepads suitable for faking TAS-level input?
Quote
Wulf2k
Experienced Forum User
Joined: 10/18/2011
Posts: 64
I know something like this must exist so I figured I'd ask before reinventing the wheel. Are there any easily accessible programs that present themselves as D/XInput devices which could be controlled from an external program to feed games reproducible strings of input with millisecond-level accuracy? I don't need it to hook into the game and actually count frames, if that proves necessary I could do it myself, so I really just need a dumb controller that can have its valued changed.
Posted: 7/7/2017 7:59 PM
Quote
Wulf2k
Experienced Forum User
Joined: 10/18/2011
Posts: 64
I'll try and make that my weekend reading project before making another post on the topic so I don't rehash a bunch of stuff. The shift register isn't a complicated piece of hardware to add, I'm just thinking that from a purely conceptual point of view it should be unnecessary. If that theory holds up, this project is no longer a "breadboard and mess of wires" project, and it becomes a "connect 5 wires to NES controller port" project. If serial communication can be processed fast enough to feed it the inputs, then somebody setting up their own NESBot only needs to get an Arduino, plug it in via USB, and hook into the controller port. I could probably walk a dedicated newbie through that in under an hour. Anyway, this is all theory until I get into it all. It's possible that the smarter people that did this first did it the way they did for a good reason, or maybe they just did it that way because it's easier to use a hardware shift register than to code one up in software. I'll try to get SMB1 syncing before posting again since that seems to be the easiest, and then I'll make a new post in the Lab forum when I need to get people's input on the details. Thanks all, and I hope to check back in with something soon. Ish.
Posted: 7/7/2017 5:54 PM
Quote
Wulf2k
Experienced Forum User
Joined: 10/18/2011
Posts: 64
Fair enough, thanks.
Posted: 7/7/2017 5:31 PM
Quote
Wulf2k
Experienced Forum User
Joined: 10/18/2011
Posts: 64
This is well outside the scope of the "General" forum, but while I have your attention feos, since I often see your name involved in the more technical discussions I figured I'd ask... Is the shift register necessary for an Arduino to communicate as a NES controller? I have far more time to think about these projects than actually work on them, though I will eventually find out for myself, but the timing seems lenient enough for it to process and respond directly to the latch/clock pulses. 12 microsecond latch signal from the NES to signal preparing the data, then another 12 microseconds (6 hi/6 low) per clock pulse to actually send the data. Assuming I'm getting 193 instructions worth of time to process each bit (12,000 / 62 nanoseconds per Arduino instruction), that should be plenty, and then I should have a relative eternity between controller polls in order to read the next set of inputs and buffer it. I'll need to do the timing-sensitive stuff in ASM instead of C to be sure it's accurate, but that should be enough timing for even an amateur attempt to make it work, right? Or am I glossing over any major obstacles? This might be wishful thinking, but it should even be possible to use serial communication to feed it the inputs from PC instead of having to preload it somehow. But that's all stuff that I'll figure out as I go. Do any premade scripts exist that would play through a movie file and output the state of the buttons at each latch instead of each frame?
Posted: 7/6/2017 6:57 PM
Quote
Wulf2k
Experienced Forum User
Joined: 10/18/2011
Posts: 64
I've been reading a bit more and have been wondering, is there any way for an emulator to tell how often the controls are read? Obviously I can just try feeding every game the current movie file and assume it gets read once per frame, adjusting from there, but do any of the emulators support "per poll" inputs instead of "per frame"? It would probably be best to try running a movie file against a "per poll" emulator to see if it syncs before attempting it on real hardware, and all the extra variables there.
Posted: 7/6/2017 4:12 PM
Quote
Wulf2k
Experienced Forum User
Joined: 10/18/2011
Posts: 64
Shouldn't that be rather easy to test by getting the savestate of a working glitch setup, then memory editing the value to see when it stops working?
Posted: 7/5/2017 9:18 PM
Quote
Wulf2k
Experienced Forum User
Joined: 10/18/2011
Posts: 64
Thanks guys.
Posted: 7/5/2017 3:11 PM
Post subject: Console verifications - NES
Quote
Wulf2k
Experienced Forum User
Joined: 10/18/2011
Posts: 64
I'm halfway to putting together my own NESBot-equivalent (inspired by, obviously, but not a copy of his code/schematic) and I was wondering if there's any sort of catalog of NES-verified runs. Should I just give myself a satisfied nod when I get it working then disassemble it, or should I take some vids and confirm on the site somewhere that runs verify? I didn't go through all 17 pages of the original NESbot thread but it looks like they discussed some sort of 'console-verified' tag without actually doing anything. It's also possible that I'm blind and have completely tuned out big flashing "Console verified!!!" banners on every run I've seen.
Posted: 7/4/2017 8:55 PM
Quote
Wulf2k
Experienced Forum User
Joined: 10/18/2011
Posts: 64
The "next" stat is unlikely to be the one that needs lowering. Instead of lowering the next stat, try increasing one byte of the checksum's value by 1. You'll probably guess wrong the first time, so if that reads as corrupt, lower it, then increase the next byte until it works.
Posted: 6/27/2017 4:50 PM
Quote
Wulf2k
Experienced Forum User
Joined: 10/18/2011
Posts: 64
I'm not familiar with the current state of these bots at all, but reading this thread made me realize that you're really just attempting to 'crack the password' of perfect inputs. Do these bots take advantage of any of those sort of methods? Are there multi-threaded bots running on GPUs 'mining' for NES inputs? Or do they all just use a single emulator thread on the CPU, passing it input the normal way?
Posted: 6/27/2017 4:40 PM
Quote
Wulf2k
Experienced Forum User
Joined: 10/18/2011
Posts: 64
I downloaded the save editor and tried it out. As Nach says, it's a simple sum. Increase a stat by 1, 1 byte of the checksum goes up by 1. Give it a try yourself, compare the differences between the original save and a modified save. If you're going to be doing it all by hand, maybe start taking notes about which stats affect which byte of the checksum. Shouldn't be too hard for you to figure out.
Posted: 6/27/2017 4:23 PM
Quote
Wulf2k
Experienced Forum User
Joined: 10/18/2011
Posts: 64
It depends on how the checksum is generated. For a very basic test, try increasing one byte by one, then go 4 bytes ahead in the file and reduce that value by one. If it doesn't work, restore the +4 byte value to its original value, then try reducing the +8 byte by 1. I can dig up the code I used to generate a valid checksum for God of War's saves if you think it would help. If you're at all comfortable with assembly and debugging, I was able to decipher God of War's checksum method by setting a breakpoint right before it started reading the save data to generate it. I'd then zero-fill the memory and see what checksum was generated. After doing that a few times and changing a few bytes to see how it affected the checksum, it wasn't too difficult to work it out. For example, if you've found the checksum value, you could make a savestate, set a breakpoint on it reading a specific stat, then save and see how the checksum is altered by altering that stat and its surrounding values. Or you could just chase through the assembly, depending on your comfort level, but I usually find that far more time consuming than just poking things and seeing the results.
Posted: 3/23/2017 9:05 PM
Quote
Wulf2k
Experienced Forum User
Joined: 10/18/2011
Posts: 64
Well, there's nothing that shows the 'entire run'. In hindsight I should have done some better archiving of the mid-level stuff, like opening shortcuts and dealing with NPCs, but since it was a 24/7 thing it was hard to keep track of every bit of progress. https://www.youtube.com/playlist?list=PLGCXPDFBR0mSzOra0gshurvE2AvRoLQ1c There's a playlist of all the boss kills, and I think they should all have the boss-approaches as well, but always after any shortcuts were already opened.
Posted: 3/17/2017 4:37 PM
Quote
Wulf2k
Experienced Forum User
Joined: 10/18/2011
Posts: 64
So, they beat the game. Moon Presence is dead. They're still working on the defiled chalice, which may or may not be possible, but overall I'm rather satisfied with how it all played out. Once they're done for good, I'll take things down and try make a few more tweaks for TAS-ability rather than playability. Bloodborne was a fun game, but various factors made it not the most reproduceable. I'm thinking I might try TASing a few levels of Super Meat Boy, just to see how it works with that sort of game. Does anybody know if SMB has been TAS'd on any other systems?
1 2 3