Experienced Forum User, Published Author, Player
(33)
Joined: 2/16/2012
Posts: 282
Hagane is affected by uninitialized memory in a variety of ways. The main thing it changes is the RNG seed (it is 0 in most cases, but is not initialized), however I have had several instances of very odd behavior with no other changes to the system (ie, just from a soft reset or quick hard reset). For example, gameplay playing at roughly 1/8 speed, collision detection being just plain wrong, and other things. I have a video somewhere if necessary.
Experienced Forum User, Published Author, Player
(33)
Joined: 2/16/2012
Posts: 282
True wrote:
Was thinking of that too, but involves controller connectors and such...but I could modify some shitty third party NES or SNES extension cable to do this.
This is how it is done in much of the streaming community at present, built according to guides for NintendoSpy or otherwise. There are software and hardware limitations with the standard implementations of NintendoSpy that prevent it from being an accurate logger (typically only used for input displays, which don't need accuracy). That was why I started this up; to see if I could rearrange it into an accurate recording system. The playback portion was an expansion on that.
In any case, modifying extension cables is a fairly simple and cheap exercise so long as you have a soldering iron and some good wire strippers. The issue at present is that many of the folks selling prebuilt adapters conform to different software revisions which have different wire requirements. My current implementation also optionally uses the +5V line to indicate when the console is powered, but I don't believe any other implementation uses this.
Experienced Forum User, Published Author, Player
(33)
Joined: 2/16/2012
Posts: 282
Just as a minor update, I reworked a lot of things such that:
-The user interface and firmware files for logging/playback are the same. This means you can log a file, then play it back without having to reflash firmware.
-Incorporated my Stepmania-like input viewer into the program as an optional view.
-When I remade it, I migrated to a bit-banged SPI so it wouldn't be necessary to swap wires when switching modes. I think this actually made it less consistent, so I'm in the progress of reverting it back to hardware SPI.
That said, it isn't uploaded to the sourceforge and probably isn't quite ready for a release yet. My time has been taken up by other things lately, but I should be able to patch it up the rest of the way in a couple weeks.
Experienced Forum User, Published Author, Player
(33)
Joined: 2/16/2012
Posts: 282
Samsara wrote:
I noticed that right at the end of the fight, actually, but since most bosses take 50 frames to become vulnerable again after being hit, using the Hard strategy didn't lose me any time there.
Thanks for the positive feedback, everyone!
Experienced Forum User, Published Author, Player
(33)
Joined: 2/16/2012
Posts: 282
I posted in the workshop thread, but just putting here too:
Difficulty also affects the final boss's invulnerability cycles. On lower difficulties, the core spends more time vulnerable. In the encoded TAS it looks like you still use the Hard difficulty strat, which can only hit the boss once per cycle. Normal should be able to hit 2-3 times per cycle. Not sure how much time removing those extra swipes saves though.
EDIT: Samsara replied in the submission thread, but the gist is that the invulnerability period after hitting the boss negates any benefit from trying to get more hits in a cycle.
Experienced Forum User, Published Author, Player
(33)
Joined: 2/16/2012
Posts: 282
Looks great! Slight note for possible further improvement though:
One of the other changes from difficulty is the final boss. His vulnerability cycle length changes depending on difficulty. It looks like you were using the Hard strategy, which can only get one hit per cycle. Normal should be able to get 2 or 3 hits per cycle before the core goes invulnerable again, which should chop out a small amount of time to swipe at the mouth between hits.
Experienced Forum User, Published Author, Player
(33)
Joined: 2/16/2012
Posts: 282
For Jodvalley boss, I'm not sure if it makes sense compared to your strategy, but I believe for real-time there was some benefit in using a bomb at some point in the attack cycle. IIRC it saved some amount of time, but depends on whether you've found a better strategy than "repeatedly screw attack into boss."
Experienced Forum User, Published Author, Player
(33)
Joined: 2/16/2012
Posts: 282
Quick improvement note: I looked into how the "Powerup Get!" animation works as far as positioning. The short version is that you get moved to absolute coordinates (128,128) of your current area. For boss rooms that are multiple areas, this makes the center a bit more ambiguous after accounting for screen scrolling.
This means that the TAS is improvable in the following boss fights:
-Water: this one is actually taken into account during the TAS, but there may be a better positioning to get to other than the corners. For example, abusing the water currents to get to a better spot.
-Wind: about a second is lost here from being far from the vertical center. There are other strats for the stage now that may be faster as well, but that is separate.
-Dragophant: horizontal center is a fair bit off here, again wasting between 30-60 frames.
-Dragon: Falling off the bottom of the screen is actually the worst option and guarantees a maximum delay of 128 frames. Horizontal positioning is not an issue, but hitting vertical center is still ideal.
So just from that, probably some 3-4 seconds worth of savings. Not quite enough to redo things, but just wanted to have it written somewhere in case somebody picks it up in the future.
Experienced Forum User, Published Author, Player
(33)
Joined: 2/16/2012
Posts: 282
Reminds me a bunch of the following, although with different goals and methods. There are a few more videos of his software playing other games too.
Link to video
Experienced Forum User, Published Author, Player
(33)
Joined: 2/16/2012
Posts: 282
Put everything up on SourceForge. Go get it, if you'd like. If you'd like to help out, let me know.
https://sourceforge.net/projects/inputcontrol/
I included some basic sample programs for both logging and playing back. Playback is a bit more iffy at this point, but it has worked on a handful of things that I've tried.
I reworked everything to completely ignore actual frame-sync and focus entirely on syncing to controller latches. This means that the new logs are not immediately compatible with BizHawk, but I threw together a lua script that would play the input logs in the same manner. One way or another, I have a handful of test movies that sync on both BizHawk and console.
Some current limitations:
-Resets and power cycles are not currently logged. Power cycles are used as delimiters of sorts between separate logs, and there's just no way to monitor for or exercise soft resets from the controller lines.
-Some games initialize RNG or otherwise via uninitialized memory values. Just like in emulator, you won't necessarily be able to force the same memory state for console playback.
-The pins on the Arduino seem to be unreliable sometimes. Too much noise or some motion can cause them to miss inputs, which desyncs all of the serial communication.
-Right now, you have to swap firmwares depending on whether you're doing logging or playback. Ideally it would just be one firmware and the host program would direct its operation.
-I don't know why, but most times when starting up playback the Arduino has 4 bytes already in its read buffer. I don't know if this is an artifact of the connection code, but right now I just toss the data into the bitbucket to get ready for the actual data. If there's ever more or less than 4 bytes to throw out, it will start off desynced.
Experienced Forum User, Published Author, Player
(33)
Joined: 2/16/2012
Posts: 282
So a few developments:
-Much-improved microcontroller code that should accurately and more efficiently capture input frames using SPI.
-Timer method for capturing no-latch frames. Can still desync if 1000+ consecutive no-latch frames occur, but that should be pretty unusual.
-Switched around some of the communication protocols so that the recording client should be more stable.
-Recordings now start at power-on rather than at the first latch.
Long-term sync issues are somewhat dampened, but not completely eliminated yet. A bigger issue is that occasional glitches appear on the 5V line I'm using as the power signal, so I will need to adjust my logic a bit more to account for 1-frame instances of signal loss.
On the other side of things, I've been thinking more about dealing with sync from the perspective of re-orienting movies so that latch-less frames are not recorded. This means that inputs are directed per latch instead of per-frame. There may be some other issues with this that I need to work out, but it could simplify both emulator sync and console playback issues. I need to understand better how emulators handle the controller latch signals though. Making a console-playback program should be pretty straightforward though if the movie is structured just to operate on latched frames.
As a side-point, does anybody have any information on how lagframes are determined in BizHawk or others? It makes sense if it's related to expected clocks per frame and counting assembly ops, but if there's a more trivial way of picking up on it that would be good to know.
Experienced Forum User, Published Author, Player
(33)
Joined: 2/16/2012
Posts: 282
Warp wrote:
FatRatKnight wrote:
One thought that comes to mind is console -> console. I know, you just played it on console, but this would be a good test to see how stable the input log itself may be when played back on the console again.
This makes me wonder how well consoles would sync between themselves. They might actually not sync in the long run. Sure, they may work identically in all respects, except perhaps one: Their CPU clocks might not tick exactly at the same rate. If there's even a tiny fraction of a difference in their clockrate, that will probably cause a desync eventually.
(On the other hand, that might not be the case if they sync to the TV's refresh rate. In other words, if they do some work to calculate the next frame, wait for the TV to start vertical retrace, do work to calculate the next frame, and so on. Since the TV is synced to the 50 or 60 Hz mains, that ought to keep all consoles in sync. Or at least this was so in the past. With current TV's I have no idea, really.)
The sync points for this implementation at least are certain signals in the controller serial protocol, which should be stable at least until the point of environmental effects having an impact on processor operation. This means that even if the clocks between different consoles are slightly different, the controller input latching happens at regular intervals with a far longer period than the source clock. Unless lag frames are mysteriously skipped here and there, it should sync on one console just as well as the next. The only other factor would be subtle differences in the console hardware (such as PPU) that have a visible effect on gameplay such as here:
Link to video
Experienced Forum User, Published Author, Player
(33)
Joined: 2/16/2012
Posts: 282
Hello all,
I made this as a bit of a side project to an input viewer. The concept is fairly simple: record inputs while playing on original hardware, then have it saved as a BizHawk movie for playback afterwards. There are still a lot of kinks to be worked out for proper syncing and some other timing inconsistencies, but it didn't take too long to come up with the PoC below:
Link to video
This is currently based on heavily modified NintendoSpy code, with inputs recorded based on a combination of serial communication and host-side timing events. I'll eventually set it up on github or something when it doesn't look like such a steaming pile and is a bit more consistent.
This is useful for a few reasons:
-Alternative playback of standard RTAs. Simple enough, it just gives a more precise way to play the latest run with more insight into the system state and player errors.
-Testing for emulation inconsistencies for specific games. The usual approach of "make a TAS movie sync to console" is just reversed; if a correct recording of console inputs can't sync on emulator, there may be things worth investigating to iron it out.
There are some limitations with the current approach. The code is currently only designed for SNES, although it can be easily adapted to most of the other controller protocols. The second is that it syncs based on power-on; resets do not have an identifiable event across any of the controller signals. Runs requiring resets or power cycles will need to be explored further.
In any case, I'm still chugging away with this. The current code is ugly and has a lot of sync issues, but I'm redesigning the microcontroller code to get around a lot of the problems. For perfect consistency, I plan to set it up to log to mass storage devices as well which will help issues relating to not having a host RTOS. Any comments, suggestions, or questions are welcome.
Thanks,
~Omni
Experienced Forum User, Published Author, Player
(33)
Joined: 2/16/2012
Posts: 282
Are there any available references or documentation for the current .bk2 file format? Just trying to determine if there's anything more straightforward than trying to piece it together from the source code.
Edit: v Much appreciated.
Experienced Forum User, Published Author, Player
(33)
Joined: 2/16/2012
Posts: 282
I made a few TASes aimed at real-time that are by no means optimized towards a full TAS, but probably worth showing off. I did find out several very important things through the playthrough, such as the Eyeball boss picking his pattern in phase 2 based on whether his HP is odd or even. This makes him much more manipulable.
Any%:
Link to video
True End:
Link to video
I have the movie files available too, if desired.
Experienced Forum User, Published Author, Player
(33)
Joined: 2/16/2012
Posts: 282
grassini wrote:
useless category imo,i don't mean any disrespect to the author i just don't see the relevance myself,specially after watching the 2player run,i guess people don't find the 2player run a comparison to normal speedrunning
In this particular case, the 1-player stages are unique and different from the 2-player stages. So this is not directly comparable with the 2-player branch.
Experienced Forum User, Published Author, Player
(33)
Joined: 2/16/2012
Posts: 282
Very well done! A couple things though:
Inner Works 2: During one section, you have to ride the bubble elevator up to an entrance, but there is a second elevator that spawns alongside it on the way up. I've gotten the second elevator to be in a much better position before, and it might be possible to manipulate it to happen at a more convenient time. Not sure if the time tradeoff for manipulation is worth it though.
Dino Graveyard 1: Similar to above, you might be able to get a more advantageous animation cycle from the jumping bone if you can manipulate it into spawning at a different time via jumps or otherwise.
Jungle 2: You should be able to freeze the spikeasaur right during its spike attack to get the same height. I could be wrong on that though. For Sethron, it might be worth manipulating him to do the charge pattern, which leaves him vulnerable for a long period of time and can be used to set up triple flame. He essentially freezes in place on the ground for double/triple flame as you hit him, so it works really well and you can likely "1-cycle" him. IIRC you can manipulate him with a slight delay or different positioning at the start.
Overall, excellent run! It was a blast to watch and see things I could only dream of doing.
EDIT: As you mentioned in the thread, skipping the really long flame powerup is probably best for Hell Hive. I couldn't really evaluate it until watching just how far out of the way it is, but I'm pretty confident that with lvl 4 flame you can kill the Hive a few seconds faster than it would take with going out of the way to get the flame for lvl 5. The opening cycles after that one long waiting phase are actually fairly quick, and you should be able to decimate the bottom openings with double/triple flame.
Experienced Forum User, Published Author, Player
(33)
Joined: 2/16/2012
Posts: 282
I remember messing with that one when I tried to casually play through that stage on hard mode. I did manage to get it eventually, but I should note that there should be one other flame powerup in the stage somewhere (maybe in the bonus area?). I'm not even sure that its freezebox changes when it gets up; I feel like I didn't need it to be standing.
Experienced Forum User, Published Author, Player
(33)
Joined: 2/16/2012
Posts: 282
Oops. No idea why that might have happened. Only thing I can guess is that sometimes parts of the boss have odd interactions with Roar when they're closed.
As for the flame powerups that you mention, that's really unfortunate. I think Level 4 Flame might be reasonable so long as you have multi-flame going, but I don't know what the time costs are for the out-of-the-way powerups. The orifices do open on a set timer and the top two should be easy to destroy, but laying a lot of damage on those bottom ones can be tough, especially if you want to clear it before the long invuln cycles.
Experienced Forum User, Published Author, Player
(33)
Joined: 2/16/2012
Posts: 282
Posting as a heads-up. I think it might be a slight improvement over the published TAS, especially if done optimally. I haven't considered any of the routing for magic refills, though.
Link to video
Experienced Forum User, Published Author, Player
(33)
Joined: 2/16/2012
Posts: 282
Very well done! Any chance we could get to see a TAS of Prototype Mode in the future?
Also, I'm not sure of precedent, but since this is a "Max Score" run instead of for time, I wouldn't mind if the movie were extended out to add in initials.
Experienced Forum User, Published Author, Player
(33)
Joined: 2/16/2012
Posts: 282
ALAKTORN wrote:
“There are about 1000 values out of the 43534”
I’m actually confused by this: why are there 43534 values total? If the RNG is 2 bytes, shouldn’t there be 65536?
Based on whatever initial seed there is, some values are likely impossible to get to. Not many games use PRNGs that cover their full space, so it's not too surprising that this one has a period less than the full 2-byte space. If anything, I'd say it's surprising they managed to get more than 50% of the space.
Experienced Forum User, Published Author, Player
(33)
Joined: 2/16/2012
Posts: 282
Yeah, I noticed that when I played some of the levels on Hard. It's not that the flame powerups are missing, but they move them to other locations. So the route for the later stages won't be comparable to what I used in the Easy route. On the other hand, some of the locations are better. For example, stage 10 has them placed in much easier to access spots.
For the double flame, you should try setting it up in the water section before the boss. You should be able to get a triple or quad flame going pretty easily by timing when you take damage from enemies. You should blow bubbles, and then as soon as you take damage blow bubbles again. This is enough to set up the bug, and you can maintain it once you jump out of the water. It's probably only useful for level 5 flame though; level 4 you can do a double flame, but it's a much smaller window to maintain. In either case setting it up in the water should be easy.
Experienced Forum User, Published Author, Player
(33)
Joined: 2/16/2012
Posts: 282
I'm trying to set up a script that can, ideally, start and stop movies as needed. BizHawk right now only has a movie.stop() function documented, so I'm left to try to come up with some workarounds, and I'm hoping some of you can help.
The primary issue is that I need to be able to sample a movie periodically to fit the use case. As far as I can tell, BizHawk stores its temporary movie data in memory as opposed to in a temporary file somewhere (please correct me if I'm wrong). This means that the only way I can make a copy of the current movie and send elsewhere is to stop the movie. But if I stop it within lua I have no way to restart it, and thus automation is lost.
With that in mind, what's the best way to get around this? I could potentially grab all of the inputs from each frame and store them away in my own file format, but that feels like a few too many unnecessary steps for what it gets me. Same thing with trying to hack a movie.start into the source code. Is there some way to force BizHawk to dump the temporary movie to a file without ending the movie, or alternatively is there some way to start movies within lua?
General idea:
start movie @ save state -> record actions -> send movie file -> return to save state & repeat