Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
My experience is that mkvs are gaining rapidly in popularity. Furthermore, from the discussion on IRC, it seems that MP4 is inferior as a container, lacking support for features that have already been used in published encodes. So I think we should continue using mkv. If people need the video in mp4 format in order to play it on specialized hardware, then converting from mkv to mp4 is a quick operation that doesn't require reencoding:
ffmpeg -i video.mkv -vcodec copy -acodec copy video.mp4
Why not use mp4, and let people who want mkvs convert instead? Because mkv's features are a superset of mp4's.
As for the codec settings, I think being pretty aggressive is ok. If the resulting file follows the standard, then players should be expected to be able to play it. Non-conforming files shouldn't be allowed, though.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I'm no expert encoder, like the publishers here, but I use this script for my SNES encodes:
http://pastebin.com/f48c418c0
It uses ffmpeg to encode a raw audio and video dump from snes9x to an mkv file with h264 video and aac audio. If the script is called snes2mkv, the usage is pretty simple:
snes2mkv -vr rate first video.dat audio.dat output.mkv
snes2mkv -vr rate second video.dat audio.dat output.mkv
Where "rate" is the video data rate you want. But this basically assumes you want to encode movies form snes9x on linux, which is unlikely.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
scwizard wrote:
Hmm, judging from that youtube video, namespoofer could work together with Taco and Kriole and save at least 50 frames.
Obviously it's not that simple though.
No, it isn't quite that simple. The sort of time one is trying to minimize makes a big difference. The video I linked to above used in-game time for timing, and here Namespoofer gains consistently on Taco and Kriole for as long as their routes coincide. For example, by the time they take the elevator up from the power bomb area, Namespoofer is 21 in-game frames ahead.
But if you instead use realtime for timing, the situation is quite the opposite, and by the time they reach the same elevator, Taco and Kriole are 92 realtime frames ahead.
I mostly prefer to watch movies with only in-game frames in them, since that means cutting out boring room tranxitions and item aquisition screens, which really break up the action. Therefore, I also think it makes sense to use these frames for timing.
But I could easily produce a variant of the movie with real frames for timing if people want to see that. Or you could just use the comparison script, and see how it looks yourself. So far, I know that atleast one other person has gotten it to work, as I discovered through a video on niconico.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
This sounds really good! We should get to testing this, and hopefully replace snes9x as the default snes emulator here, as soon as possible. Once we have LUA in place (this should be easy to add ourselves, without bothering byuu with it), it should be better than snes9x in every way.
By the way: What is the resolution of the stepping in bsnes? Most of the time frame-stepping is enough, but as the Chrono Trigger movie showed, one sometimes wants instruction level stepping etc. too.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Here is an encode of the comparison script comparing the recently published run by Taco and Kriole with it's predecessors:
Part 1: http://www.youtube.com/watch?v=0y0-73n5BE8
Part 2: http://www.youtube.com/watch?v=97crP9jsb5w
Part 3: http://www.youtube.com/watch?v=h92PXmRZ2l0
The movies it is being compared to are:
Purple: Cpadolf's in-game oriented any% v2
Red: Herooftheday's realtime oriented any% v2
Blue: Cpadolf's in-game oriented any% v1
Green: Herooftheday's realtime oriented any% v1
Gray: Namespoofer's non-glitched speedboster low%
As usual, only in-game frames are displayed and used for sync, and the runs are re-synced at room entry to ease comparison. The numbers at the top of the screen display how many in-game frames behind a movie is compared to the current submission. This number makes most sense when the routes are similar.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Oh, how did I let another Super Metroid submission pass me by unnoticed? This will not do; I'll have to make up for it with another comparison video:
Part 1: http://www.youtube.com/watch?v=0y0-73n5BE8
Part 2: http://www.youtube.com/watch?v=97crP9jsb5w
Part 3: http://www.youtube.com/watch?v=h92PXmRZ2l0
The movies it is being compared to are:
Purple: Cpadolf's in-game oriented any% v2
Red: Herooftheday's realtime oriented any% v2
Blue: Cpadolf's in-game oriented any% v1
Green: Herooftheday's realtime oriented any% v1
Gray: Namespoofer's non-glitched speedboster low%
As usual, only in-game frames are displayed and used for sync, and the runs are re-synced at room entry to ease comparison. The numbers at the top of the screen display how many in-game frames behind a movie is compared to the current submission. This number makes most sense when the routes are similar.
Nice! With this, I can use Luigi for 96 exit ghosts, and mario for any% ghosts, for example. Even better, though, would be to have one sprite set for each of the ghosts. It could be mario, luigi, the princess, toad, sonic, etc. But making them would be a lot of work..
I have tested the script on 96 exit runs too, but it ended up less interesting imho, mostly because of very different overworld routes, and too few runs to compare with.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Here is a comparison of this run with its predecessors. They are again resynced at each room to avoid some of them lagging too far behind for comparison to be possible, but I will encode a version without that resyncing later.
http://www.youtube.com/watch?v=yEJhrU1EAhk
Edit: The quality will hopefully improve as youtube has more time to process it.
Edit2: Here is the one without room resync:
http://www.youtube.com/watch?v=GZtEqONzuwk
Not as informative as the video above, in my opinion, but still interesting.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Mister's SMW run compared to itself. Repeatedly, with a different delay each time:
http://www.youtube.com/watch?v=CAAf4o3nnO8
Probably not useful, but shows mario's motion through the levels in a new light, I think.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I haven't tried the latest version, but my experience from a not that old version is that the desyncs happen because of non-deterministic emulation, not because of save/load problems (or perhaps because of both). I think I got desyncs even if I didn't use any savestates at all. Or does the memory leak stuff have something to do with the non-deterministic emulation?
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Here is the result of running my Super Mario Wold comparision script on the published any% runs:
http://www.youtube.com/watch?v=ieFFCRQBIeohttp://www.youtube.com/watch?v=imsRpZ-WEds
See here http://tasvideos.org/forum/viewtopic.php?t=6539&postdays=0&postorder=asc&start=175 for a description of the script.
Note that the runs are re-synced at the beginning of each room. Otherwise, the fast runs would quickly outpace the others, and there would be much less action. The overworld shows the true timing, though. The runs shown are those by (in order of speed) Mister, Fabian, JXQ, Flagitious, Neuhaus, Volkov and Bladegash. The number of frames each run was behind Mister at room entry is shown at the top of the screen.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I have adapted the old Super Metroid TAS comparison scripts for Super Mario World. Here is an example of the script in action:
http://www.youtube.com/watch?v=ieFFCRQBIeohttp://www.youtube.com/watch?v=imsRpZ-WEds
And here are the scripts themselves, along with two resource files:
http://folk.uio.no/sigurdkn/smwrecord.luahttp://folk.uio.no/sigurdkn/smwplayer.luahttp://folk.uio.no/sigurdkn/smwdb.maphttp://folk.uio.no/sigurdkn/smwdb.png
Surprisingly, making the super mario world version of this script was much harder than making the super metroid version, mostly because of inconsistent delays between when values appear in handy memory addresses and when things update on screen, as well as many composite sprites (the yoshi portion of the script is still somewhat hacky).
Most of the options from the super metroid version are still there: You can choose between realtime and in-game modes (which make much less difference here than in super metroid. The video above was made using realtime mode.) both for displaying and syncing, and you can turn per-room resyncing on or off. Note that room syncing is not used on the overworld, so you can easily see the runs' relative position there.
For using the script yourself, the procedure is the same as before:
1. Generate ghost files, which are text files containing destilled information about a run. This is done by loading the script smwrecord.lua, and then loading the movie file. Once you are done (fast forward does not disturb the script), exit the emulator, and a file named ghost.dump has been generated. Rename this to something sensible. Repeat this for each run you want to compare to.
2. Edit smwplayer.lua. What needs editing is only the the topmost portion. Edit the ghost_dumps list to indicate the dump files you generated earlier.
3. Load smwplayer.lua in snes9x, and either try playing against the ghosts yourself, or load a movie file.
You will require the gd library for lua for this; otherwise you can only display hitboxes etc.
Edit: The script now supports continuous offsets instead of just room offsets, and the offsets displayed can be controlled independently from the offsets actually used for the ghosts. The offsets used for the delays at the top are now calculated to sub-frame precision based on the ghost speed and distance from closest ghost pixel to the current player position. The status display has been corrected and expanded to show more useful information. Here is a demonstration of the script in action:
http://www.youtube.com/watch?v=gRSVOPzxsKQ
The new version can be found at the same locations listed above. Note that the ghost dump format has been changed, so you will need to rerun smwrecord.lua to generate new ghosts.
Edit: Fixed room transition issue which sometimes happened when the same room was vistited multiple times. The smwplayer.lua linked above has been updated.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
It is a bit delayed, but here is the low% comparision video, comparing NameSpoofer's (normal Samus), Saturn's (red Samus) and Terimakasih's (blue Samus) low% runs, as well as the current any% run (green Samus) as an extra bonus.
http://www.youtube.com/watch?v=WIf1onFWe2Ihttp://www.youtube.com/watch?v=D6BNYt6jasIhttp://www.youtube.com/watch?v=wxkqRbZ4YII
As usual, I only display in-game frames, and use these to sync the runs. And also resync them at room boundaries so that room strategies can be compared. Unfortunately, the oldest run is left behind almost immediately in each room, so it is not simple to compare strategies with it. This is mostly due to the lack of arm-pumping there.
The numbers at the top of the screen show how many frames behind NameSpoofer the other runs are. Techincally, it show how many frames needed to be delayed to make them enter the room at the same frame. When paths diverge, this number makes less sense.
In general, NameSpoofer is barely faster than the any% run (Taco & Kriole) in most rooms until the route difference starts to become an important factor. He is noticably faster than the low% ice (Saturn) in almost all rooms, with the major exception of bosses and metroids. The same applies vs. the old run (Terimakasih), but to a much larger degree.
I think this comparision would have been useful in the run's thread in the workbench, but since it already is in gruefood, I'll just post it here.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
hero of the day wrote:
why not just compare the 3 existing 14% runs? The routes are damn near identical, so it makes for the most accurate comparison.
1. Teri's
2. Saturn's
3. Spoofer's
Comparing to Terimaki's would be ideal, but as I said, it is too old, and I don't know of a lua-equipped emulator capable of playing it back.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Thanks for an impressive and entertaining run NameSpoofer! I was surprised that such an aggressive play style was possible with that little health. I also liked the use of the bomb spread.
Going from watching the run to reading this thread was a bit of a let down, though, with all the sad bickering going on. I definitely think this run should be published, and I don't see the problem with many categories. If bandwidth or disk space is an issue, then make it an smv-only publication if you must.
Anyway, since people seem to have a hard time noticing the improvements, I thought I'd make an encode using my comparison script. I am not quite sure what to compare to, though. Right now I'm thinking:
1. This run.
2. Current glitched any% or the current normal any% (ingame)
3. Saturn's ice low%
4. Fastest RBO run
5. The oldest possible run. The idea is to have one with as low optimization as possible, but it is better the closer its route is to this one, as the comparisons make more sense then. Terimakishi's runs are too old for the emulator, so I guess herooftheday's first attempt is the prime candidate here.
Other suggestions are welcome! The list probably shouldn't be longer than 5 though, otherwise the screen will just be a forest of Samuses.
Edit: In case any of you don't know what such a comparision video looks like, here is one I made a while ago, for the any% runs:
http://www.youtube.com/watch?v=QdFUMRFpn74
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Making a rerecording PC emulator is possible. But it is hard. First of all, most popular PC emulators use various speed tricks which involve passing instructions through to the underlying machine, or using its interrupts etc. This breaks the encapsulation of the emulated machine, and makes it nondeterministic. Not all PC emulators do this, though, and for those that do, it should be possible to rewrite those parts (a huge project, though smaller for somebody already deeply familiar with that emulator).
Secondly, a PC has lots of different parts: Network interfaces, com ports, sound cards, graphics cards, various buses and bridghes on the mainboard, etc. etc. Even if the emulator actually emulates these, instead of using those of the underlying system, saving the state of all of these correctly is difficult unless the emulator was designed with savestates in mind from the bottom up. And incomplete savestates lead to desyncs, just like nondeterministic emulation does.
Thirdly, the state of a PC is larger than that of a typical console. By a factor of a million or so. This means that, unless differential savestates are implemented, each savestate will take up gigabytes, and take significant time read and write. Which would make tasing irritating. On the positive side: If differential savestates are implemented, the step to non-linear rerecording, with a branching tree of savestates you can jump between, is pretty short.
Fourthly: The concept of roms is more complicated here, but as discussed in a (relatively) recent thread, it is still possible to reach a setup that will allow movies to sync without having to distribute the whole state of the VM (which would contain copyrighted software). However, the presence of license keys etc. prevents this from working, so this could only legally be done with license-key-less software.
Fifthly: The movie would have to contain a set of inputs for every device on the emulated PC which could accept input from the outside, for example the network card, mic, mouse, keyboard, power button, dvd eject key, etc. This isn't a big problem, though.
That said, I would also like to see such an emulator. I recall speaking to somebody who was making a rerecording version of JPC, which he said was already deterministic (which is the greatest hurdle in my opinion). I haven't heard anything since then, though.
Do any of you know of any other rerecording PC emulator projects?
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
FractalFusion wrote:
amaurea wrote:
Change byte 0x14 from 1 to 0.
That should not work. At least one joypad should be recognized.
Oops, you're right. So there is nothing wrong with the smv file: That byte being 1 means that joypad 1 and only joypad 1, is enabled. Adetque: There is no player2-input in that SMV at all. I agree that this sounds like a simple joypad swap configuration issue.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
ElectroSpecter wrote:
Thank you SO so much amaurea. I was able to "finish" the script thanks to you. It follows Diddy perfectly but it doesn't update the graphics very well.
Anyway:
while true do
x = memory.readword(0x7e0b1d)
y = memory.readword(0x7e0ff9)
memory.writeword(0x7e1a62,x-0x80)
memory.writeword(0x7e1a4c,0-y+0x6f87)
gui.text(10,10,"" .. x)
gui.text(10,20,"" .. y)
snes9x.frameadvance()
end
How I got that formula for the camera's y-position was a little iffy. There's probably a better formula for it (which maybe won't mess up the graphics?). Basically, I'm pretty sure that the character's y-position is inverted from the camera's y-position. I believe they equal each other in the center of the map.
For example, in the first level, Diddy and the camera can both be at 176 for a y position (176 being the horizontal center of the map) and at the extremes it would be either Diddy at 0 and the camera at 352 or Diddy at 352 and the camera at 0 (note that these are THEORETICAL values for the first level as I was never able to actually get Diddy to 352 or 0, but I'm pretty sure I'm correct on this point).
The water level that Tompa needs the camhack for has different extremes for the y values (ranging from 0 to 28551). This is where I derived my formula (6F87 in hex). This also means that this camhack will only work on Croctopus Chase and no other levels.
If there's anything wrong with this (which I suspect there may be due to the brutal graphical errors), I would love it if someone could point me in the correct direction or figure out where I went wrong.
Again, thanks for helping amaurea.
The y address looks pretty strange. It is suspicious that it is so far away from the x address, and the strange inversion you describe is also very odd. When I get back from work, I'll have a shot at finding the proper addresses. Also, setting the screen scroll to wrong values will lead to the background not updating properly. That also happens with the x-only script I made if you replace 0x80 with 0, for example.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Adetque wrote:
I was TASing a romhack of SMW when the game switched my character to player 2. I never set my movie to be able to record player 2 actions, but I tried switching to player 2 anyway. And then somehow I glitched out the replay to make Snes9x think the entire replay is player 2 input and not player 1 input. How can I hex edit this out? Please help.
Here's the video: http://dehacked.2y.net/microstorage.php/info/677323728/Total%20Kaizo.smv
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
It's amazing that some of the simple questions in this thread haven't been answered yet.
ElectroSpecter: To read 16 bits instead of 8, use memory.readword.
The basic structure of a simple emulator lua script is:
initialize if needed (usually isn't for simple scripts)
while true do
do everything you want to do every frame here
Snes9x.frameadvance()
end
If you don't have the loop, then the script will do stuff only once, and terminate after one frame.
Here is an example:
while true do
x = memory.readword(0x7e0b1b)
memory.writeword(0x7e1a62,x-0x80)
gui.text(10,10,"" .. x)
snes9x.frameadvance()
end
This sets the camera's x position to equal Donkey Kong's x position - 128, as well as displaying the x position. So to get the script you want, you would add the y parts, as well as a check for which character is active, and use appropriate addresses for that character.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I don't have any experience with that game or emulator, but it sounds like frame skip is acting even when frame advance is used. I think I remember a similar problem in zsnes. Perhaps you need to manually set the frameskip to 0? On the other hand, if that is the problem, then I wouldn't expect it to affect just one game.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
QEMU is far from deterministic enough, and making it so seems very difficult. On the other hand, I spoke to somebody in #tasvideos who was almost done making a deterministic (and hopefully rerecording-enabled) version of JPC, which is another PC emulator. So getting this is perhaps not too far fetched.
There is no reason for there to be any cans of worms involved either, no matter whose worms those would be. The way to do this is just like how we handle sram now: When a movie needs to start from sram, one has to provide a movie that generates said sram, right? Here is how a TAS of some windows game would work:
Instead of one having a rom of the game (which would be a can of worms, as you say), runs of the game would start from a standardized savestate. This savestate would be one where windows and the game itself + dependencies have been installed, and the game exectuable just started. This would serve as a common starting point for all runs of the game.
This savestate would ofcourse not be distributed, since that would, again, be a can of worms. What would instead be distributed is an emulator movie which generates this savestate. This movie would start from another savestate (the "windows just installed" savestate), and would contain input like "eject CD tray", "insert CD with hash 5bba729dcfe9", "close tray", "move mouse to X,Y", "click right button", etc. etc., which would lead to the game being installed and configured.
The savestate the "install game"-movie started from, which is the "windows just installed"-savestate, would be generated in much the same way, but this one would start from a standardized plain state (downloadable from tasvideos, and without anything installed), and not from another savestate.
So each user would have to make sure they have the correct CDs, and would then have to play back the "install windows" and "install game" movies once in order to generate the standard savestate from which tases of the game would start. And since nothing but input is distributed, there can be no problems with this.
The only conceptually new thing needed for this is an emulator movie instruction to insert a specific CD on a given frame.
Just like the ROMs are checksummed to make sure the right one is being used when playing back a movie, so would the starting savestate be. In fact, the starting savestate plays almost exactly the same role as the rom, does now, except that one has to generate it oneself (by playing back a movie).
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Well, a script for just skipping non-ingame-frames is just a few lines long, and can also be found in the snes9x lua scripting thread, which would also be a better place to ask in the first place.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Yes, it was in the script. If you read the description of the script, it has several options for how to synchronize them and what sort of things to display. So if you run the script with the default settings, it only displays in-game frames, i.e. frames where the in-game timer changes.
So to be clear: I did not use any video editing software to change the video: what you see in that video is just a recompressed version of what you get when running the script.
Be aware if you want to do this yourself, though: There is a bug in the current snes9x-rr that makes produce buggy audio output in the dumped video if frames are skipped during recording. I fixed that bug in my version of snes9x-rr.
