Posts for natt


Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Aktan wrote:
great research natt! Though I don't know how to apply to our current method. creaothceann, we are doing a lot of YUV444 recently, so the color loss is less now.
Well, I think the current method is a good one; the "primary resolution" of the game is chosen as the resolution to encode to, with other resolutions being squeezed to fit. There would just be different aspect ratios used in some cases. For example, I just downloaded the encode for Symphony of the Night (Richter Path), and it's at 256x240 (the resolution that most of the game runs at, but is given a display AR tag of 1.333. My data would indicate that a display AR tag of 1.234 would better resemble how it played on the original system. (As a bonus, it seems to agree better with the clock face a few rooms before shaft, looks like a circle now).
Post subject: PSX aspect ratios (NTSC)
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
There's not a lot of hard information out there, so I made a few guesses. If anyone has better, I'd love to hear it, because I couldn't find it anywhere. Fact: PSX GPU has a 53.203 MHz reference clock Source: http://www.mediafire.com/?zbp2bhb4y117xp7 Fact: PSX GPU has 240 and 480 line heights, and 256/320/384/512/640 line widths Source: http://www.horningabout.com/jimb/psx/gpu.txt Fact: The NTSC square pixel clock (single height) is 12,306,394Hz. Source: http://lipas.uwasa.fi/~f76998/video/conversion/ Guess: Dot clocks are integer dividers off the reference clock. Justification: It would be simple and easy to implement. Guess: Dot clock dividers were chosen to give screen aspect ratios of approximately 4:3 with the usual vertical overscan (approximately 448 of 480 lines visible). Justification: There'd be no reason to have lots of overscanned horizontal pixels; developers wouldn't be able to use them. A large underscan would also mean useless black pillarboxes on most TVs. If you accept all of these assumptions, the results are easy to calculate:
Base CLK = 53.203MHz

W   Divider PAR (240p)  DAR (H=224)
256    10     1.157       1.322
320     8     0.925       1.322
384     7     0.810       1.388
512     5     0.578       1.322
640     4     0.463       1.322
For 480i resolutions, you just double the pixel AR. Then you use that pixel AR with whatever actual width/height the engine requested to get the display AR. Example: 256x240 has AR=1.234 Note that the extra width of the 384 resolution (5% more than the others) can easily be observed in practice. There's additional evidence supporting these dividers in the PS2: It has access to the same video resolutions, and the MAGH register values correspond to these dividers exactly. Without more understanding of how the clock select works though, it's not proof of anything.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Rena wrote:
More difficult than getting the game to jump to SRAM would be getting a useful program there just by button presses... :)
Super Mario Land 2 glitched TAS writes RAM addresses by out-of-boundsing the play area and then having the RAM appear literally as blocks on the field. Chrono Trigger glitched TAS writes RAM addresses by corrupting the item list to hell. Both of these methods have limitations, but the idea certainly isn't impossible.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Rena wrote:
I'd be satisfied to know that emulators used in TAS videos initialize all memory to random noise on any power cycle, but if you want to really nitpick, I could stick Mario Kart in my N64, then quickly switch it off, replace it with another game, and switch it on again... the data takes more than a few seconds to deteriorate, so I could essentially control the initial contents of RAM that way... and of course uninitialized SRAM probably contains pieces of older save files... then I could make a run which "beats" a game by just tricking it to jump into some uninitialized memory where the previous game left a subroutine, which survived power cycle and conveniently jumps to this game's end sequence... or by hitting new game, saving, and quickly resetting after the game has written just enough data to mark the save file as valid, then loading a previously erased save in which the game is beaten...
I wouldn't get too sad about it. Even with garbage in memory at startup -- if the game is properly written, it won't be affected by it. It might use the garbage in ram for its starting RNG seed, but you'll generally need a buffer overflow/out of bounds exploit to do anything else with it.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
VLC version "VLC media player 1.3.0-git-20111212-0003 Rincewind" plays it back fine. MPC-HC version "1.5.2.3456" with lavf "0.42 - 2011/11/30" plays it back fine. Colors look slightly different in the two cases, but that's probably my fault. MPC-HC ignores the AR metadata in windowed mode (bug?), but that appears to be specified wrong anyway.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I asked about bsnes a few months back http://tasvideos.org/forum/viewtopic.php?t=11426 Ilari had a few good points, but more important than his response was the fact that he was the only one who responded. I just don't think there's much community interest here in more accurate emulation. And not to get the -rr coding work done; one sufficiently crazy dude could handle that. To get tases made! No point making bsnes-rr when people are still using snes9x 1.43 to record.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
FractalFusion wrote:
gocha used AviSynth to insert input and stuff in his encode for Castlevania: Dawn of Sorrow (scripts are here), but I find it awfully hard to decipher.
Well, in short, he uses a LUA script running in the emulator to dump various informations to a text file when the emulator plays the movie: http://pastebin.ca/1548787 Then he loads that data into a LUA script that runs under AVIUTL which prints the information to the frames of an AVI file: http://pastebin.ca/1548781 The basic idea is pretty simple, but you wouldn't be able to make it happen without some good documentation on AVIUTL, which doesn't appear to exist in english. I would think for an english speaking encoder, it would be better to look into using one of the numerous avisynth text overlay filters to accomplish what you want to do directly in avisynth.
Post subject: Re: Well, fellow TASers! We're doomed! :O
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Billy wrote:
I called Nintendo of America customer service yesterday
That sounds like a bad idea. There are a lot of bad places to get your legal advice from, but I think "from the opposition" is one of the worst. And from a customer service line? They're just low level employees with scripts to read. They have neither a legal background nor any knowledge of the company's desires and intents beyond what makes it on to their scripts. If you want real legal advice, retain a lawyer recommended to you by the EFF. Otherwise, just stay off the radar. Regardless of the actual law involved, they will start litigation against you if they don't like you and you're big enough of a pest (intimidation by legal threats).
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Lex wrote:
It's impossible to synchronize keystroke playback with the game's logic rate without hooking anything.
Didn't say it would be easy ;) but I personally wouldn't consider a simple timing hook to be forbidden for such a program; as long as you aren't actually changing any of the values returned by QueryPerformanceCounter() or similar.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
DarkKobold wrote:
#2, it is a wrapper - someone could claim that alone invalidates it.
With good reason; I don't think there's anything particularly wrong with Hourglass, but I don't see how you could prove conclusively that with all of those hooked functions and replaced libraries, the game is running exactly the same as it would otherwise. I see a very clear analog to the console-verified status for Hourglass though: Make a program which plays back the keystrokes in the movie file without mucking with the target executable at all.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
IMPblackbelt wrote:
What about a charged item? I think a wand/rod/staff in the spare weapon set might provide an extra skill that could help with entertainment or efficiency. Maybe something with charges of Bone Wall could provide a better enemy lineup or some interesting entertainment? Perhaps curses, or extra elemental attacks?
Can't get Bone Wall on magic/rares. Might be on some uniques (I know bone prison is on some unique boots). Can only get these skills on magic/rares (item type, level, etc may vary): magic arrow fire arrow inner sight cold arrow multishot power strike exploding arrow ice arrow charged strike freezing arrow lightning strike firebolt charged bolt ice bolt telekinesis frost nova ice blast fireball nova lightning enchant chain lightning teleport glacial spike meteor blizzard frozen orb teeth dim vision weaken poison dagger terror confusion life tap bone spear attract lower resist poison nova bone spirit sacrifice holy bolt zeal vengeance blessed hammer bash stun concentrate grim ward firestorm fissure twister volcano tornado
Post subject: Re: libsnes
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
* Savestates can be only made on certain spots, no idea how frequent. * Sub-frame input may be possible (apart from problems it causes with emulator movie code), but what looks to be the most useful such input (sub-frame reset to corrupt SRAM in specific way) doesn't look to be so.
I can't find the source offhand, but I believe byuu said that snes_serialize () runs at most a handful of extra cycles before reaching a "saveable state" This would make frame-level advance easy and while cycle-level advance isn't possible, you'd still have an improvement over snes9x with that. Other than the sync-stable issue, which as you say, no one knows either way, the other points seem rather minor.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I've been reading through the featureset of libsnes recently (a good in-depth is at http://gitorious.org/bsnes/bsnes/blobs/51c1d242eae7271b55e61d488e00359c154bf180/bsnes/ui-libsnes/libsnes.hpp), and it seems to have all of the basic requirements for tool assisted recording, as well as features its competitors lack (subframe input and best-in-class emulation accuracy). Google and forum searches of tasvideos don't seem to bring up much discussion about it though; a few hits for bsnes but they all seem to be outdated. I'm wondering what the scoop is currently and if there are any plans to move to libsnes TASing.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
nanogyth wrote:
Yes Does anyone have the PC version? The pixels would have to be square there, so it should be an easier target to aim at than analog captures.
That would require assuming that the developers of the PC version understood the exact specifics of the aspect ratio on the Playstation version and replicated them accurately; seems unlikely.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
nanogyth wrote:
The 320x224 represent square pixels. The 368x224 don't, they have a pixel aspect ratio of 10/11 and take up a larger section of the screen.
I am interested in reading your source for this, because I couldn't find it anywhere.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Dada wrote:
So how does overscan affect this? For example, the main gameplay is dumped by the emulator as 320x224, is that simply because it was 240 but got cropped by overscan to 224? I don't know much about how overscan works, so I need some guidance here, particularly in determining how we will treat the source material. The video on the previous page is my attempt at positioning things based on what looks good, there's no science behind that effort. At this point, however, I don't even know if we should correct the 320x224 material to 4:3.
I googled long and hard for the actual pixel clock/dot clock values for the PS1, and couldn't find anything. (I figured it'd be pretty easy to find, but apparently not.) Without a precise measurement of that, all you can do is look at how a capture appears and fudge values from that.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Dada wrote:
I need to check whether any of these resolutions are letterboxed. For example it could be that when switching from 320x224 to 320x216, all that really happens is the top and bottom are padded with 4px each.
There are only two vertical resolutions for the ntsc PSX: 240 and 480. 240 is ~60p; 480 is ~60i. Any other supposed vertical resolution is in effect a cropped version of one of those. Practically speaking, you didn't see more than about 450 lines or so on actual hardware (overscan). Similarly, there are only 5 horizontal resolutions: 256, 320, 384, 512 or 640, corresponding to 5 different selectable pixel clock rates. Anything in between is one of those with cropping. I don't know what the appropriate aspect ratios are, but I'd imagine it's similar to other NTSC output devices (256 has a similar pixel clock to nes/snes, 320 gives approximately square pixels with 240 height, etc...)
Post subject: Encoding settings (ffmpeg)
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
This sounds like a silly place to ask this, but I think you guys are rather knowledgeable about these sorts of things. I am working on a modification to a doom source port for direct video capture. My motivation was to get something with the same capabilities that the emulators used here have: non-realtime frame-exact capture, with sound perfectly synced to video. I didn't want to use anything platform specific (eg AVI output like visualboy advance), nor did I want to use anything that adds additional dependencies at build time (linking in something like libavcodec directly). My solution is to use popen() to spawn encoding processes. The power user is then free to plug in any encoder he wants to that can read raw video or raw audio from stdin. I'd like however for the not-so-skilled user (especially under Windows) to be able to automatically dump videos that are of reasonable file size and quality while being uploadable to places like youtube directly. So I can bundle a free encoder with the download, set default command lines, and it all works presto gizmo. Here are the default invocations in the current beta version:
#audio pipe: stdin is 16bit signed stereo audio at samplerate %s
"ffmpeg -f s16le -ar %s -ac 2 -i pipe:0 -acodec libvorbis -f ogg -aq 5 output.ogg"
#video pipe: stdin is 24bit rgb raw video at size %w x %h, 35fps
"ffmpeg -f rawvideo -pix_fmt rgb24 -s %wx%h -r 35 -i pipe:0 -vcodec libx264 -f mp4 -fpre ./libx264-baseline.ffpreset -crf 22 output.mp4"
#mux command: run after recording is complete.  %f was specified by user on commandline
"ffmpeg -i output.ogg -i output.mp4 -vcodec copy -acodec copy %f"
When %f is somefile.mkv, this has the problem that the output mkv is somehow damaged; it doesn't play right, but remux it with mkvmerge and it plays perfectly. There are no other output containers that ffmpeg will put both avc and vorbis into (I thought you could put avc into ogg, but apparently not). I could use avc+aac in mp4, but ffmpeg's aac encoder is marked experimental. I could bring in extra dependencies (like mkvmerge); but I'd like to keep the distribution size down; static link ffmpeg.exe is already 11MB. So I guess my question is; can anyone recommend default encoding settings for a one-pass automated situation like this. If ffmpeg absolutely isn't up to the job, I am willing to consider replacements. Remember that doom footage (especially with glitz like 32 bit color, hires, opengl, texture filtering, and hires texture replacements) is not going to compress well under ZMBV or anything similar.