What do you mean by "I hope you have a verified clean set, e.g. No-Intro"? You mean the rom?
Yes. A clean ROM has no copier header and is not modified in any way (no dumping errors, not interleaved, no random bit-switching errors, no hacks or modifications) and preferably has the .sfc file name extension.
There are two major ROM sets that are in circulation: the old "GoodSNES" set (file names have stuff like "[!]" in them) which includes anything that looks remotely like a SNES ROM, and the No-Intro set which includes only the actually good ROM files.
speedrunner wrote:
You say me to first record video, and after to record in AVI while it's playing?
Yes. If you record the entire TASing process, you'd also record the frames that are eliminated by rewinding. It wouldn't make sense.
speedrunner wrote:
What do you mean by transcode to lossy codecs?
When you have finished creating the TAS (the .smv file), you record to a lossless format so that you have a clean base that you can do video editing with (e.g. adding text and logo, trimming off the end at a good frame). After video editing you transcode (encode from one codec to another) the lossless video clip to a lossy one: e.g. video from Lagarith to h.264 and audio from uncompressed PCM to Ogg Vorbis. This removes a lot of fine detail, but means that the file can be uploaded and downloaded in a reasonable time (the lossless encode will almost certainly be several gigabytes in size).
Both files play back without any problems in MPCH; of course in the browser it's without Vsync but still watchable.
CPU usage (with lots of background tasks, most of them idle though):
MPCH, NVIDIA CUVID, 08-bit file: 9%
MPCH, NVIDIA CUVID, 10-bit file: 34-40%
MPCH, software decoding, 08-bit file: 15%
MPCH, software decoding, 10-bit file: 35-40%
Browser, fullscreen: 20%
Browser, small window: 60-70%
System info:
- 8-core AMD Phenom II X6 1050T "Thuban" @ 2.8GHz / 8GB DDR3
- NVIDIA GeForce GTX 460 (GF104 A1) / 1GB GDDR5
For best results use DSS2 for video input. (You can get it either by installing the Haali splitter manually or simply letting the k-Lite codec pack do all the work. Then copy avss.dll to the Avisynth "plugins" directory or write a one-line "LoadPlugin(...)" script for that directory that loads the DLL from its location.)
For audio you need a different function; depending on the project I either use DirectShowSource(FileName, video=false) or NicAC3Source (for DVD tracks).
AVI isn't a codec (compressor/decompressor), it's a container.
Examples of the former include h.264, Indeo, RealVideo. Examples of the latter include AVI, MPG, MP4, MKV and WMV.
You could even put a high-quality BD rip into an AVI file, or the video and audio streams of the earliest AVI files into a MKV file.
The failures in console-verifying Super Mario World glitched run[1] likely point to that the autopoller timings in bsnes core are incorrect.
These timing errors are not severe enough to cause failures or even desyncs in any even remotely well-programmed game, but really mess up things when run probes these timings to extreme degree, like the SMW glitched run.
[...]
Unfortunately, I have none of:
- SNES programming skills.
- SNES flashcart.
- SNES console.
AUTO JOYPAD READ
----------------
When enabled, the SNES will read 16 bits from each of the 4 controller port
data lines into registers $4218-f. This begins between dots 32.5 and 95.5 of
the first V-Blank scanline, and ends 4224 master cycles later. Register $4212
bit 0 is set during this time. Specifically, it begins at dot 74.5 on the first
frame, and thereafter some multiple of 256 cycles after the start of the
previous read that falls within the observed range.
Reading $4218-f during this time will read back incorrect values. The only
reliable value is that no buttons pressed will return 0 (however, if buttons
are pressed 0 could still be returned incorrectly). Presumably reading $4016/7
or writing $4016 during this time will also screw things up.
- Pretty sure N64 crooked cartridge can be emulated. I mean, why not? It's just electrical wires not connecting properly.
I'm pretty sure it can't. Emulation isn't about mimicking the electrical properties of a system.
Besides, electrical circuits are extremely hard to emulate properly. When you start using a system in a way it was never designed to be used, anything can happen.
Emulators do emulate reading bytes from the cartridge. Console CPUs don't have all their address space mapped to the ROM, so at some point there's a decoder that looks at the address requested by the CPU and passes it on to the cartridge. Cart connector pinouts are well-known, so I don't see how the decoder couldn't turn off specific Data Bus lines.
EDIT1: But technically that should count as altering the game code (unless a TASer can prove that only save RAM data is modified), i.e. like a hack.
EDIT2: I believe the true spirit of TASing could be summarized as beating the original game code as fast as possible. This doesn't have to include any hardware at all (which is why we can use emulators); it's like a theoretical mathematics problem. The game is like a labyrinth, and the goal that is hidden in the middle is the ending - the last, final state the game can assume (though some games may restart automatically). In other words, a TASer needs to beat the game creator and his code into assuming this last state (usually visualized by the ending).
You are supposed to be the master of the game, not the slave of the game. Aim for the impossible. Think outside the box and do not give up if your ideas do not work right away. Just because you cannot get something to work right away does not mean that it is not possible.
