3. I'm attempting to find things like x/y speed using RAM search, but I keep getting about a dozen possible values. As in, I'll move a few pixels to the right and search for memory locations higher than before, then move a few pixels to the left and search for memory locations lower than before, and I come up with about a dozen locations that all seem to correspond to my x position. Any tips on narrowing that down?
Try setting the locations to a specific value and see if your position becomes fixed.
Some minutes of googling, I haven't personally used them myself:
A capture card is something like this; you put it into your desktop PC, connect the video source (e.g. VGA/DVI/HDMI) and start recording on the PC.
It can have a video output that passes the video signal from the input through, so you can see what you play without any lag.
There are also stand-alone units (see link above, or e.g. here) that connect via USB to a PC. (Theoretically they could also have a built-in HDD/flash memory, connect to external HDDs or USB sticks...)
is it considered valid user input to unplug and replug controllers? Particularly, in mtap case, for fastest playback this would probably imply unplugging mtap and instantly plugging in a controller. I'm not sure that is a valid input case, at least as far as TAS is concerned. (Are we TASing the game, or the emulator? What I mean is, if an instant swap could not be reproduced, then would it be valid? I would say no...)
We're TASing the game, not the emulator or the hardware. If a controller can be unplugged and replugged, it's going to be instant because we're inhumanely fast gods.
Yeah I saw that, and I know what a m3u file is, but I didn't know how to create one (or that is was so simple), and most regular users will probably not know either.
Afaik the CD ripping software is supposed to create it.
But people have to realize that they'll be spoiled if they watch a TAS... You also don't go to Wikipedia and read the plot of the movie you're planning to watch that day either.
re: SNES
Another way to do it would be to use tabs, a la vSNES' scene viewer.
The screen and BG info and the palette, while nice to see, are probably only necessary for ROM hackers / emulator devs. Making them visible only via checkbox / menu option / tab would speed up the game nicely.
(I'd also remove the dropboxes and use only radiobutton groups.)
Using separate windows for each category is definitely interesting, as long as the layout can be saved. (The windows snapping to each others' edges a la Winamp would be nice too.)
Regarding the palette options: AFAIK ZSNES (and SNES9x?) simply shifts the color values 3 digits to the left (XXXXX to XXXXX000), while bsnes uses the topmost 3 bits to fill the lower bits. This "spreads" the colors a bit and makes it possible for a color channel to have the value 0xFF.
Yeah, had an idea about creating them and also wanted to see if they still look good on Youtube. (I think for my next encode I'll add some black bars to get the height to an even 240, should make the residual line pattern more uniform.)
If you don't like the scanlines and don't want to dump the video yourself I could upload it "raw", but that would take a while.
Since any% is by definition the shortest percentage, "any% longer than (x)%" is by definition impossible. It just means that the any% is 100% in that case.
Any% is just how much of the game was completed.
Example: A game has 10 levels and 10 optional treasures per level. If the player completes with less than 100 treasures, the game shows a lengthy "bad ending" sequence (e.g. shows unskippable tutorial screens) before requiring the last possible input. If the player completes with all of them then the game shows a rather short "good ending" sequence. All "100%" TASes would end up with a shorter completion time than any "any%" TAS.
So the slower it renders the better quality will get?
Yes, unless you select a quality instead of a bitrate - then a slower speed preset will create smaller files.
Kurabupengin wrote:
I have a couple of issues with playing the .avi files
The file format (AVI/MKV) is just a container. Think of it like 7z/RAR/ZIP archives: there are some extra features you get with newer formats (for example "solid" archives with RAR), but this doesn't change the data they contain.
You can put a BMP file into a ZIP archive and a PNG file into a RAR archive (both with minimal compression settings), but that doesn't mean that displaying the picture in the RAR archive is slower because it's a RAR file. No, it's slower because the data stream inside is compressed much more.
Likewise you can put a h.264 stream into an AVI file or into a MKV file, the playback speed will be exactly the same. The overhead of parsing the AVI/MKV file format is a very low fraction of the CPU power spent on decoding the h.264 stream.
Kurabupengin wrote:
However it plays fine when uploaded to YouTube, so that's kinda weird.
Youtube re-encodes the videos you upload, so they're not comparable to the ones on your harddrive. Use taskmanager or Process Explorer to see if your CPU or your harddrive is maxed out during playback.
