Nice. :)
I wonder if there's a codec optimized for dumping - it should spend as few CPU cycles as possible to keep the output data rate just below the drive's write speed, leaving the rest of the CPU time to the emulator. (Or just create enough worker threads to leave one core for the emulator.)
There's also MSU, ffdshow's FFV1 and ffdshow's DV (both in RGB mode).
You could also try compressing a video dump with ZMBV after using ConvertToRGB32.
Seeing that x264 was similar to AVISynth in that it wasn't it's own seperate program
It is a separate program, unlike Avisynth (which is a DLL) - it just has no graphical user interface. A command-line interpreter like cmd.exe is ideal for passing parameters when starting programs, and observing their text output.
FionordeQuester wrote:
[...] so much as it was something that gave your Notepad to do way more than it otherwise could
Notepad isn't involved in that, it's just an editor for text files.
FionordeQuester wrote:
I opened up Virtualdub and chose the "Run Script" to run the script above that I had saved.
VirtualDub's scripts are not the same thing as Avisynth's scripts.
I prefer 1x resolution, but at least point resize is the one that looks like it.
1x will always be wrong when YV12 is used as the color space, regardless of if it's via Youtube or separate download. It needs at least 2x.
@ThatGugaWhoPlay:
It's called BilinearResize, not Bilinear.Resize, and yes it'll probably be rejected because all other HD encodes use PointResize.
PointResize is even faster than any other resize method, by the way.
OK, I'll try that. :)
This is how a HTML version of the manual might look like:
http://www.mediafire.com/?tucden2yv0ff4
(done with Frontpage Express, so it shouldn't be used for an actual release)
That would require buiding a build with compatibility core. There is currently no support for switching cores at runtime (that would require pretty much putting the core with some extra API into shared object / dynamic link library and loading that stuff at runtime).
Runtime switching isn't really needed, especially if it'd be slower than static linking... Only those who would create/dump movies for Air Strike Patrol would need another build.
Ilari wrote:
creaothceann wrote:
Supporting ROM files with headers is kind of iffy - you may as well add support for all kinds of compressed archives. (Using uncompressed files for everything would be helpful, imo.)
I have function that just blindly strips first 512 bytes (--headered-rom and friends, headered checkbox in the wx version).
Currently it supports .zip archives. .7z could be useful, but that is likely fair amount of code, even with likes of liblzma and so.
It's just that byuu has a certain stance on the issue (ROM headers are worse than useless (patching problems), archives don't have enough benefits today and needlessly complicate the code) and I agree with him. You can even include a build of snespurify, in addition to the source.
Ilari wrote:
It is not something I can even test
VirtualBox / VMWare with a Windows installation? Anyway, it's just that uncompressed / barely compressed AVI files are a bit too space-wasting (and maybe slow?) for my taste, especially when the ZMBV codec or ffmpeg's RGB codecs are already available (uncompressed video would be at least ca. 10 MB per second). But it's something that can be lived with, I guess.
It would be really helpful to default to the faster compatibility core. The accuracy core is only needed to show a graphical effect in one or two games. Using the same key input file for both cores should never result in a desync.
Loading ROMs with spaces in the file didn't work until I figured out that lsnes-sdl "--rom=%~1" in a batch file works. Wouldn't it be more intuitive for lsnes to assume that the first parameter (that is not a switch) is the ROM file?
Supporting ROM files with headers is kind of iffy - you may as well add support for all kinds of compressed archives. (Using uncompressed files for everything would be helpful, imo.)
The need to press Pause to start playing is kind of unintuitive - SNES9x uses the "play" and "record" program states for that.
The manual is kind of unusable - wall-of-text alert! The best solution imo would be *.htm files (one for each section) with hyperlinked indices for quick navigation.
It really needs an easy way to change keys, at least a list of the default keys (I eventually found them in the log) and a list of all available key names.
Don't worry about Avisynth's "AVISource" command, there are much more modern ones available (FFIndex+FFVideoSource and DSS2). Btw. a window popping up with the installed codecs (like in SNES9x) would also be good.
Another topic for discussion is what version of Snes9x should be used for future runs. I see that there is a 1.53 version now. It looks like it fixes the graphical issues that plagued the game in the 1.43 version. I would also assume that the timing is now more accurate. Anyone have any thoughts on this?
Unassisted speedrun = done in realtime on the console with no "cheat" devices
Tool-assisten speedrun = as long as the result is a sequence of button presses, anything is allowed - emulators (with savestates, slowdown, frame-by-frame progress, ROM & RAM viewing, ...), debuggers, ...
Wouldn't it be easier for encoders to just dump at 640x480, knowing that a game can switch graphics modes at any time? Especially if the result is going to be YV12.
(width stretched to 640, height doubled if not interlaced, then padded to 480 if necessary)
* Oh, and it is somewhat slow: You need pretty fast computer to run compatibility accuracy core (really the only core that matters with rerecording) at full speed.
My post was about complexity, not quantity. Of course there's a lot of work, but it can be divided into these parts.
I'm not a C++ programmer, I work mostly with Object Pascal. My codebase would not find many contributors, and my GUI would be different - and at that point using SSNES would have more advantages.
Or you could just switch to bsnes (or SSNES, or libsnes with the SNES9x interface) and be done with this issue.
Wait... Really, we can just switch to a bsnes core with Snes9x GUI?
I mean 'you' as in 'the members of TASVideos', i.e. including the programmers who are maintaining SNES9x builds.
You'd basically go through the code and comment out everything that accesses the emulator core, until all that's left standing is the "skin" (input/output drivers are initialized, windows and dialogs appear as usual, buttons can still be clicked etc., but all the main window shows is a black screen).
Then add the code that creates/destroys and accesses libsnes, using the source code of SSNES for comparison.
