For the sake of temporary encoding, I highly suggest using Lagarith. It's fast and lossless while keeping the initial AVI's filesize reasonable.
There's also the ZMBV codec which is included in DOSBox and shows up in BizHawk as "Zipped Motion Block Video". It records only the changes from one frame to the next, saving some space, which in the end may be faster.
Samsara wrote:
Language: AviSynth
AVISource("(your video file)")
PointResize(last.width * 8,last.height * 8)
"last" isn't strictly needed... Here's some code that automatically calculates the necessary zoom level:
Language: Avisynth
file_name = "video clip.avi"
AVISource(file_name)
i = Get_ZoomLevel(Height, 1)
PointResize(Width * i, Height * i)
function Get_ZoomLevel(int h, int i) {
# 720 lines enables Youtube's HD mode
(h * i >= 720) ? i : Get_ZoomLevel(h, i * 2)
}
Samsara wrote:
PointResize, to put it simply, resizes your video. There are many resizing filters available in AviSynth, but you'll almost always want to use PointResize for your TAS temp encodes. Anything sprite-based with clearly defined pixels will benefit more greatly from PointResize, which is... well, 90% of the content on this site.
If the video is from a TV-based system then "BilinearResize(960, 720)" might look better.
But you can have separate ROM collections: one for seeding and one for playing/TASing/etc.
This also means that the torrent files can be in newer archive formats (e.g. *.7z) that not every emulator or tool supports.
I am trying to create a temp encode of a WIP TAS i'm creating in PSXhawk. When I try to append the segments, I get an error on VirtualDub saying that the resolutions are different.
A video file can have only one resolution, but PSX games can switch between several resolutions. Just do something like this:
increases the amount of text calls by a factor of 9
How about increasing the background font a bit and moving it so that it's centered in the actual text? It won't look perfect but that's not really needed here imo.
I also wanted to pop in and say outstanding job to the encoding crew! It looks like you guys have been hard at work getting all of the old runs upgraded to HD.
Time to replace every single movie's YT video with a 60/50fps version?
The data in OAM would not be correct, so sprites could have the wrong position, use the wrong color palette or the wrong bitmap data, have the wrong priority (i.e. appear behind/in front of the wrong background layers), or might be horizontally and/or vertically flipped when they shouldn't be (and vice versa).
Of course most of the time not all 128 hardware sprites are on screen (most are 'parked' beyond the right or bottom screen border), so even if the wrong data ends up in OAM it might not be visible.
If the game is really starved for memory then theoretically it might use part of the OAM as additional RAM - just like some games had SRAM in their cartridges (not backed by a battery) for that purpose. If the data read back from OAM is wrong then the game might show all kinds of glitchyness or even crashes.
APU: Audio Processing Unit. Inaccuracy on this emulation will cause the audio and sound effects to play imperfectly?
Probably. (Though there's also the case where ZSNES' failure to emulate the echo buffer allowed the creation of Super Mario World hacks that crashed in emulators that did emulate the buffer, and of course on real SNESes.)
Gamer Maiden Sonia wrote:
SNES OAM Test (3-high): no idea. Can someone make this one clear to me?
OAM is a 544-byte buffer for the attributes of the hardware sprites that are on screen. Like the video RAM it's loosely connected to the main CPU, and the connection has some quirks. For more info see anomie's register doc, register 0x2104 ("OAMDATA").
Gamer Maiden Sonia wrote:
SNES ADC SBC: From what I found, seems to have to do with latency. Does it have to do with how accurately the emulator emulates the lag from games?
ADC is the "add with carry" instruction and SBC is "subtract with borrow". When these instructions are not emulated correctly, calculations done with them will create incorrect results. As you might expect this should be easy to detect (games would most likely crash even before showing any graphics), but there are lots of parameters that can influence the instructions, and emulator bugs may affect only some rare variants.
program Variant_List_Creator; {$mode objfpc} {$H+}
procedure p(const tmp : String; const i : Integer);
begin
if (i > ParamCount) then begin
WriteLn(tmp);
exit;
end;
p(tmp + ', ' + ParamStr(i), i + 1);
p(tmp + ' and ' + ParamStr(i), i + 1);
end;
begin
if (ParamCount < 2) then begin
WriteLn('Error: need at least 2 parameters');
Halt(1);
end;
p(ParamStr(1), 2);
end.
Lazarus (i.e. FreePascal) project with binary: link
- This page gives a list of bugs caused by inaccurate emulation. The page also says that "roughly 2/3rds of them also exist in Snes9X v1.52 and earlier".
(EDIT: byuu archive link updated to one without broken images. --Mothrayas)
