Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Evoli wrote:
I edited my first post. The TASes are made with Hourglass, there is a topic about it here
Do you know if the author intends to submit them here? While it looked to my untrained eye like there were some missed gracing opportunities towards the end, the ufo run was very entertaining, and I, at least, would vote for it to be published here. Touhou has huge TAS potential if done correctly, so it is a bit sad that all the activity is happening outside TASvideos.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Ah, yes, that is the one where the score overflows (at 22:36) :-). Touhou is clearly TASable, but how is it done? Do people use modified versions of the game, or manual editing of input files? Anyway, it would be nice to see some Touhou tases here too. Why not simply accept them in the form of Touhou input files?
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Marx: Just to be clear, I liked the run overall. I hope you will go through it again and fix the issues we've pointed out, and submit a new improved version.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I voted no. Does not achieve its primary aim, which is to minimize enemy kills. This is especially blatant with the fire wheel. If you kill enemies just to save time, then that's any%, not pacifist. In the pacifist category, reducing the kill count by one is enough to obsolete a run that is 10 minutes shorter, and speed only matters if the kill counts are equal.
Other than that, I would have preferred having no damage as a secondary goal, since what makes pacifist fun is the large number of enemies that you have to avoid, and allowing damage means you can skip avoiding some of them.
Some opportunities to entertain were missed in the rising lava autoscroller. Moving with the music is always nice. That is not critical, though, and the reason why I voted no was solely due to not achieving the pacifist goal.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
You may also be interested in the GoodTools, which have lists of every version of every game for lots of consoles, and which provides tools for automatically categorizing a came based on its checksum. You can read about GoodTools here: http://en.wikipedia.org/wiki/GoodTools
There are links to the tools' homepage from that page too.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
This is from a different (but related) game, but it is one of my favorite examples of tool-assisted superplay: Full of action and entertaining situations (though one has to watch it several times to see everything that's happening). I would like to see a TAS here create similar situations at a similar tempo.
Link to video
A higher quality video can be found here
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
rog wrote:
CoolKirby wrote:
I think he's joking. He's noting the irony of the ratio of cutscenes to gameplay in this run (since a cutsceneless encode was made for the currently published any% run).
Why would i even joke about something this serious? The cutscenes in this game are just too long. I'm sure a lot of people agree that this would be much easier to watch without them. For a run as awesome as this, i think we should do whatever it takes to make sure everyone can enjoy it.
I second the request for a cutsceneless encode. I usually make these for Super Metroid, and they make a huge difference in the fluidity of the action. I haven't seen one for OOT, but I'm sure it would be a nice watch there too. Making such encodes is pretty straightforward (at least for snes9x): Just find a memory address which indicates whether you are in a cutscene or not, and set speedmode to maximum for their duration.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Bobo the King wrote:
Would it perhaps be worthwhile to create a page of checksums so that TASers can know (before running or playing back a game) if their ROM is good? I don't think that even comes within a mile of a gray area of the site's rules.
Isn't this exactly what the GoodTools are for? Here is the Wikipedia entry, and here is a link to GoodGBA. This tool will compare a rom's checksum to a database of checksums, and tell you which game and which variant of the game it is. The correct rom to use would be one with [!] in the name.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I guess I'll post mine too. My encodes are not publication quality as they don't include any subtitles or intro etc., but they are quite high on the automation scale. It only works on smv and fm2 for now, though.
After I've downloaded an .smv file, the encoding process looks like this:
Language: bash
$ smvenc2 foo.smv foo.mkv
That produces a lossless yuv444 encode at normal resolution. If I want to use a lua script with that, and perhaps have a double-sized yuv420 encode, I would do
The encode is totally headless. That is, no snes9x window pops up during encoding, and no sound is played (but of course, the output video contains sound and image), so this can be run on a system with no running X server, which is nice for making an automated encoding service as I did before at one time.
The script itself looks like this (link):
Language: bash
#!/usr/bin/env bash
# Automatic smv encode. Given an smv file and and output filename,
# produces a lossless encode in one pass
player="smv"
popts="-r 5 -mute -dumpstreams"
prefix=".smvenc"
afifo="audiostream0.dat"
vfifo="videostream0.dat"
afile="$prefix.audio.mp3"
vfile="$prefix.video.mkv"
fmt="yuv444"
double="auto"
proginterval=0.5
# My snes9x has problems with complicated file names due to the
# dchshell wrapper, so copy things to simple names in the work dir.
worksmv="$prefix.work.smv"
workmkv="$prefix.work.mkv"
worklua="$prefix.work.lua"
qp=0
function show_help()
{
echo "smvenc2: Encode smv files to mkv
Syntax: smvenc2 [options] in.smv out.mkv
Options:
-lua script.lua: Run with this lua script.
-v: Verbose mode: Show output from subcommands.
-frames: Output video will be this many frames long.
-qp: Encode with this qp. Default is 0 (lossless).
-fmt: Color format to use. Rgb, yuv444 or yuv420.
-2: Double size before encoding. Useful with yuv420.
-1: Do not double size.
-0: Determine doubling automatically based on color format.
-h: Display this help."
}
# Parse arguments
nf=0
args=()
argv=("$@")
for (( i=0; i <argv>&2; exit ;;
*) args[$nf]="${argv[$i]}" ; nf=$(($nf+1)) ;;
esac
done
case "$fmt" in
rgb) fmtcmd="--output-csp rgb" ;;
yuv444) fmtcmd="--output-csp i444" ;;
yuv420) fmtcmd="--output-csp i420"
if [[ "$double" == "auto" ]]; then double="yes"; fi;;
*) echo "Invalid format $fmt" >&2; exit ;;
esac
if [[ $double == yes ]]; then resize="--vf resize:512,448,method=point"; fi
smvfile="${args[0]}"
outfile="${args[1]}"
frames="$(bread "$smvfile" 16 4)"
frames=$((frames+1000))
if [[ $frames_override ]]; then frames=$frames_override; fi
# Prepare work directory
cp "$smvfile" "$worksmv"
if [[ $lua ]]; then cp "$lua" "$worklua"; luacmd="-loadlua $worklua"; fi
rm -f "$afifo"; mkfifo "$afifo"
rm -f "$vfifo"; mkfifo "$vfifo"
popts="$popts $luacmd"
junkdev=/dev/null
if [[ $verbose ]]; then junkdev=/dev/stderr; fi
# Be ready to clean up
trap 'kill $xvfb $ppid $apid $vpid $spid 2>/dev/null
rm -f "$vfile" "$afile" "$worksmv" "$worklua" "$workmkv" "$afifi" "$vfifo" ' EXIT
# Don't display anything
display=":40.1"
Xvfb "$display" -screen 1 800x600x24 >$junkdev 2>&1 &
xvfb=$!
export DISPLAY="$display"
function progreport
{
while true; do
s=$(stat -c %s "$afile" 2>/dev/null)
rsec=$((s/96/1024*8))
h=$((rsec/3600))
m=$((rsec/60-h*60))
s=$((rsec-h*3600-m*60))
if [[ ! $verbose ]]; then
printf "\b\b\b\b\b\b\b\b%2d:%02d:%02d" $h $m $s; fi
sleep $proginterval
done
}
# Start producing output
"$player" "$worksmv" $popts -maxframes $frames >$junkdev 2>&1 &
ppid=$!
# Encode audio
lame -r -s 32 -h "$afifo" "$afile" >$junkdev 2>&1 &
apid=$!
# Encode video
x264 --input-csp bgra --input-res 256x224 --range pc --colormatrix bt470bg $fmtcmd $resize -o "$vfile" "$vfifo" --qp $qp --preset veryslow --fps 60.0375 >$junkdev 2>&1 &
vpid=$!
# Progress report
progreport >&2 2>/dev/null&
spid=$!
wait $ppid $apid $vpid
{ kill $spid $xvfb; wait $spid $xvfb; } 2>/dev/null
# And merge them together
mkvmerge -o "$outfile" "$vfile" "$afile" >$junkdev 2>&1
rm -f "$vfile" "$afile" "$worksmv" "$worklua" "$workmkv" "$afifi" "$vfifo"
printf "\ndone\n"
This depends on a couple of other utilities. The "smv" is a script I use for watching smv files. It handles the automatic lookup of the rom and then runs snes9x (link):
There are some other short utilities that are needed, but the forum mangles them, so I'll just link to them instead:
smvcrc is used to extract a crc from an smv file, for the purpose of looking up the correct rom.
romcrc is used to compute the crc of a snes rom, wihch is used to poulate a directory of crc -> rom symlinks.
bread is used to read the frame count from the smv file.
For fm2 files I use a similar setup
fm2enc, fm2, fm2md5, nesmd5
The md5 stuff is mostly extracted from fceux.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
CoolKirby wrote:
amaurea wrote:
Since the category is "145 presses", I guess this wouldn't be obsoleted by a 144 press movie, but only by a faster/higher-score 145-press-movie.
See Brandon's Minimum Buttons page. A TAS with 100 button presses can be obsoleted by a faster TAS that also has 100 button presses. However, a TAS with 99 button presses, even if it's longer than the original TAS, can still obsolete the faster TAS. Then, a faster 99 press TAS would obsolete the slower 99 press TAS. That's how the system works.
Then the category name should have been "Minimum presses" or something, not "145 presses". But the category name is a formality that can be changed later. I like this concept, and I think this should be published.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Since the category is "145 presses", I guess this wouldn't be obsoleted by a 144 press movie, but only by a faster/higher-score 145-press-movie. This should be generalized to having a category for every press number. After years of hard competition in these categories, and thousands of smb-press-submissions, we could build up a graph of the completion time as a function of the number of presses, for the betterment of man kind.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Your progress looks good, but the desync is worrying. You have probably read this one already, but I will point you at it anyway:
http://tasvideos.org/forum/viewtopic.php?t=12484
As a side note, it would be convenient if you edited out the into in these WIP updates.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
It took a long time to watch, but I enjoyed it. Your entertainment choices were nice, moving the cursor to the music, for example. And it was fast. I voted yes.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
antd wrote:
I'm not sure how long the segments will be. It seems they will be fewer than 6000 steps.
Note that what number of steps is the effective limit depends on the specifics of how the danger level increases and what scale the encounter sequence is on, so 6000 does not have to be too much. It is probably more helpful to look at the number of encounters you would have without any tricks. This is about 20 for the 3 second example I displayed.
It would be possible to implement this in lua too. It would be a bit shorter but much slower.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
antd wrote:
This is a segment in the game. The X axis are the steps and the Y axis is the danger counter. The white lines are the battles. You get a battle when the red line hits a white line.
What we need help with is in calculating the fastest way to avoid battles. In other words, should I menu glitch, stutter (sometimes not possible, easy to see when it is or not possible) or accept+escape a battle.
So, I want to know the fastest way through the segment I just posted above. Ideally we will need to optimise the data not just for one segment but for the entire game.
Anyone that can give ideas on how to accomplish this?
How long are these segments typically? I am afraid that finding the optimal solution probably has an exponential cost, but this does not need to be prohibitive if the naive number of encounters in a segment is less than about 20. I also have an idea for a greedy algorithm that scales much better, but which is not guaranteed to find the optimal solution. It is also more complicated, so if possible I would go for the optimal one. I will make an example implementation of the optimal solution to illustrate. I'll update the post when it is done.
Edit: Ok, I have implemented my idea now. The implementation (C++) can be found here. I had to guess some of the factors needed, and I didn't have the encounter sequence available, so I generated one randomly in the program. This means that you can't just run the program and use it directly - you have to fill in the correct encounter sequence and costs. So really, this is just a demonstration of an algorithm that solves the problem brute force, but hopefully still fast enough.
It produces two outputs. One is a list of between-actual-encounter segments:
Here, the first encounter happens at step 561, and before that there have been 377 steps of stutter-walking and 3 menu-tricks, for a total cost of 1311 frames above the theoretical no-time-loss time for that distance. The next segment is from step 562 to 1277 with 677 steps of stutter-walking and 4 menu tricks, etc.
The other output is a graph like this one (or rather the text file on which it is based), showing the danger level vs. potential encounters:
Of course, I may well have misunderstood your problem here. But perhaps this will give you some ideas at least. I hope the program isn't too unreadable - I tried to include useful comments, but I didn't have time to polish it. As I said before, this is a brute force implementation, and it scales exponentially with the number of steps. The above example was 2500 steps long and took 3 seconds on my laptop. 3000 steps would probably take more than a minute, and I wouldn't go much further than that. But looking at your example, it seems like your segments will be shorter than this.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
TASeditor wrote:
Hello friends,
I did a Lua-script, which shows information about the enemies above them. The information move with the enemies movement.
With the help of a useful structure known as a loop, you can reduce this program to 9 equivalent lines:
while true do
gui.text(0,0,"")
for i = 0, 10 do
x,y,energy,rng = memory.readbyte(0x71+i), memory.readbyte(0x85+i),
memory.readbyte(0x486+i), memory.readbyte(0x413+i)
if energy > 0 then gui.text(x,y,string.format("%3d %3d", energy, rng)) end
end
emu.frameadvance()
end
This isn't tested, but if it doesn't work it should be simple for you to fix. Not only does this save you lots of work the first time through, it also makes it much easier to change it later, as you only need to change one place. Nice to see that you followed up on the advice to learn lua scripting :)
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Saethori wrote:
What level of precedent does this run establish, now that it's evidently accepted?
The publication of this TAS is a serious blow against the language rule, which this discussion has shown does not have much support in the community. It doesn't really say anything about the other rules.
Saethori wrote:
It would seem it gives the impression that it's okay to break the rules at will to get a faster time, so long as it's a popular game and/or one's a well-known TASer.
It shows that rules are not ever-perfect and set in stone, and that unpopular rules eventually get overturned. You make it sound like this publication suddenly makes it ok to, say, start from a hacked save-state. But such a run wouldn't be published because the rule against starting from a save-state has a solid backing in the community.
Saethori wrote:
I would hope it's not, that this is merely an exception, but two exceptions for the exact same game for the exact same rule violation really kind of strains things.
Actually, I rather hope it isn't an exception, but that the rule will be changed instead. As you say, needing the same exception to the same rule repeatedly strains things. It strains the credibility of the rule, and the language rule is sorely strained now.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I made a video comparing the 4 published mega man x2 any% runs:
Link to video
To my surprise, there are several instances where the newest run is actually worse than the one before it. These include the Zero battle (about 200 frames lost) and the armor upgrade dialogue (about 40 frames). I have checked the Zero battle case to verify that this is not due to some bug in my comparison script, or due to timing differences between actual frames and in-level frames. The loss is due to not employing the regain-freedom-by-getting-hit-during-cutscene glitch. So obsoleting the current run would be pretty straightforward - one wouldn't even need any new techniques, just consistently using the old ones.
Edit: FractalFusion has informed me that the previous TAS was done on the Japanese version, which has faster dialogue. That fits pretty well as an explanation for both the delays I noticed. My initial explanation was flawed because the glitch I was thinking about only works in the battle with fake zero, not the real one. So it turns out that the published TAS is pretty well optimized after all. Sorry about that FractalFusion and Graveworm!
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Here is a comparison script for Mega Man X. It works similarly to the one for Super Mario world: You use mmxrecord.lua while playing back an .smv to make a ghost file for that TAS, and then use mmxplayer.lua to compare a set of ghost files with an .smv. At the top of a script is a configuration setting, where you can control whether to skip non-level gameplay, whether to display the status line, what sort of offsets to display, etc. A change from the super mario world script is the addition of a "relative" setting for the offset display. It displays how many frames were gained since the beginning of the level, based on X-posiiton in the level.
Here is a video demonstrating the script in action:
Link to video
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
DarkMoon wrote:
Okay, so I'm working on a complete disassembly of Mega Man X right now. I suppose this could prove to be useful to some people around here in the long run, so I was wondering if anybody wanted to help me document RAM addresses? I have a WIP RAM map right now, but it's pretty small thus far.
I'll post notable findings here, if people want me to.
Thanks for the RAM map - it has been quite useful for me already. I have a script which draws graphics on top of X, and while it usually works fine (as long as I calculate X's integer position as xint = (x+0x80)/0x100, that is proper rounding for subpixels instead of truncation), on some frames the screen scroll value in address $7E:00B4, $7E:00B6 is off by one pixel. This happens a lot during the intro stage, for example, where you will see the x scroll value stand still a few times even though the screen moves every frame. This seems to happen in busy areas, so perhaps it is connected with lag. So there is probably another set of scroll values somewhere in memory which corresponds to the true scroll. Or perhaps there are scroll sub-pixel values somewhere, and the scroll must be rounded just like the X position is.
Another nice thing to have in a RAM map would be delay information. I.e. for addresses which correspond to visible changes on the screen, what is the delay between the address changing and the screen changing?
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Some arguments here seem to implicitly assume that we are trying to decide whether this TAS should be English or Japanese. But of course, the question here is whether to accept it or not. If we accept it, we get a Japanese TAS, and if we reject it it doesn't become an English TAS. Instead, we don't get a new TAS, and probably won't for a long while.
Rejecting this TAS means that we prefer the old, obsolete TAS by Blooblibla. It means that we value the Enlighsness of the cutscenes more than how optimized and entertaining the actual gameplay is. And it means that new viewers hoping to see the how fast OoT can be completed with all dungeons will be disappointed to find a TAS almost an hour slower than the modern record, and they will learn that youtube rather than TASVideos is the place to go to to find the state of the art.
More importantly, though, it means that we are telling TASers the same thing: Youtube is the place for TASing. It doesn't matter if your TAS beats all records and is made with a good eye for entertainment - should you petition TASVideos for the honor of being allowed to submit your TAS, it will be judged instead for its choice of ROM. As it is, the large Japanese TASing community already prefers Youtube to TASVideos, and I don't want this to spread, because TASvideos provides record keeping, input files and quality control that Youtube does not.
So I don't think we should be sending such a message, and I think the majority here agrees, from looking at both votes and posts in this thread. But the language rule does not. So there is a conflict between the majority of the community and the rules in this case, and one side will have to give in. Should that be the rules, or the community? I have seen several people here make the argument that the rules should trump everything because they are rules. That is backwards, I think. The rules are supposed to represent the consensus, and are there to help us reach the right decision faster, but this thread makes it clear that there is no consensus for the language rule. So the rule isn't doing its job. It should be rewritten to match the consensus (or majority if no consensus can be reached), not the other way around.
I can identify with the people who want to be able to read the text in the game, but don't know the game well enough to know the text by heart. Jumbled-up and sequence broken text is more fun than the normal kind in my opinion. However, the primary audience of a TAS are people who have played the game. These are the people who are most likely to watch the TAS, and they are also the ones that will get the most out of watching it, since they know what is supposed to happen, and can be surprised and impressed when it doesn't. People who have played the game will know what is said, and will care more about impressive gameplay than English text.
Thankfully, the inexperienced viewers, experienced viewers and Zelda TASers can all have their cake and eat it too, by including a subtitle track with the English dialogue, as has been suggested several times during this thread. And while we're at it, I hope there will also be a subtitle track with commentary and trick description, such as there was for Cave story.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
AngerFist wrote:
No doubt that this run really rocked. It's simply astonishing. But I am definitely voting no. Why? Swordless deliberately picked the J rom just to fuck with tasvideos. See when you read his description of his submission, his reasoning sounds fairly ok, right? Well, I will never forget the plethora of discussion everyone involved had with the whole J rom vs. U rom. Time after time, people with reason explained thoroughly the deal with the J rom. But no! Swordless would not budge, no matter what!
I strongly disagree with this reasoning. This is, as you say yourself, a really good TAS. It is faster and more entertaining than its predecessor, and, importantly, it is a large improvement even if we subtract the 15 minutes or so the text difference accounts to, which shows that it is measurably more optimized than the previous run. That is why it should be published.
What you are suggesting here shows exactly what the problem with the "use the U rom if possible" rule is: It leads to rejecting many of the best TASes, and alienating the large japanese TASing community. I think the rule should be replaced by one saying that either the original version (which is usually the japanese one) or the english version (since this is mostly an english site) is ok, but that the judge should compensate for any text speed differences etc. when judging the run, so that a more optimized version with slow text is never obsoleted by a less optimized version with fast text.
Finally, I don't think you're doing your argument a favor by ascribing sinister motives to Swordless Link here. He has spent a lot of effort making this run - far more effort than one would put into a prank. And even if you were right, his motives do not matter - the run should be judged on its own merits. And those merits speak for themselves.
.
Edit:
This is a segment in the game. The X axis are the steps and the Y axis is the danger counter. The white lines are the battles. You get a battle when the red line hits a white line. What we need help with is in calculating the fastest way to avoid battles. In other words, should I menu glitch, stutter (sometimes not possible, easy to see when it is or not possible) or accept+escape a battle. So, I want to know the fastest way through the segment I just posted above. Ideally we will need to optimise the data not just for one segment but for the entire game. Anyone that can give ideas on how to accomplish this?
Of course, I may well have misunderstood your problem here. But perhaps this will give you some ideas at least. I hope the program isn't too unreadable - I tried to include useful comments, but I didn't have time to polish it. As I said before, this is a brute force implementation, and it scales exponentially with the number of steps. The above example was 2500 steps long and took 3 seconds on my laptop. 3000 steps would probably take more than a minute, and I wouldn't go much further than that. But looking at your example, it seems like your segments will be shorter than this.