Posts for Nach

Post subject: Battle of Megaman Helmets
Emulator Coder, Experienced Forum User
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Which user do you think has the more impressive Megaman Helmet for an avatar? Bisqwit or Shinryuu .
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Emulator Coder, Experienced Forum User
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Thanks Shinryuu.
Bisqwit wrote:
Nach wrote:
I noticed though that recent Cygwin (and recent Linux) has a more direct way of getting the pipe size. Can you try this for me please?
It does not compile in my Cygwin installation (which I just upgraded). F_GETPIPE_SZ undeclared.
Odd... Google Search: site:cygwin.com F_GETPIPE_SZ
alden wrote:
Nach wrote:
Thanks Alden, and cool architecture you got there.
Oh, haha, I didn't even notice that. It's theoretically some IBM PowerPC something or other, I guess?
No idea, Google says nothing on that serial number.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Emulator Coder, Experienced Forum User
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Thanks Alden, and cool architecture you got there.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Emulator Coder, Experienced Forum User
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Thanks guys, this is helpful. Bisqwit: Cygwin not being a power of 2 scares me... Is something wrong somewhere? I noticed though that recent Cygwin (and recent Linux) has a more direct way of getting the pipe size. Can you try this for me please? Download pipesize2.c
Language: c

/* Linux 2.6.35+ and recent Cygwin only */ #define _GNU_SOURCE /* Raaaaaaaaaaaaaaaaaaaaaaaaaaaaa */ #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <fcntl.h> #include <sys/utsname.h> #include <errno.h> #include <limits.h> void output_system_id() { struct utsname n; if (!uname(&n)) { char *p = n.release; unsigned long major, minor, patch; major = minor = patch = 0; major = strtoul(p, &p, 10); if (*p == '.') { minor = strtoul(p+1, &p, 10); if (*p == '.') { patch = strtoul(p+1, &p, 10); } } printf("%s %lu.%lu.%lu %s\n", n.sysname, major, minor, patch, n.machine); } } int main() { int pipefd[2]; output_system_id(); printf("PIPE_BUF size: %d\nPipe size: ", PIPE_BUF); fflush(stdout); if (!pipe(pipefd)) { int size = fcntl(*pipefd, F_GETPIPE_SZ, 0); if (size != -1) { printf("%d\n", size); } else { perror("Failed to get pipe size"); } close(pipefd[0]); close(pipefd[1]); } else { perror("Failed to create pipe"); } return(0); }
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Emulator Coder, Experienced Forum User
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Bisqwit wrote:
CYGWIN_NT-5.1 1.7.9 i686 PIPE_BUF size: 4096 Pipe size: 65540
I'm quite surprised by that last size... Probably have a bug in my code?
Bisqwit wrote:
Enough?
For Linux yes, Linux is well documented. "man 7 pipe".
   Pipe Capacity
       A pipe has a limited capacity.  If the pipe is full, then a write(2) will block or fail, depending on whether the
       O_NONBLOCK  flag  is  set  (see  below).   Different implementations have different limits for the pipe capacity.
       Applications should not rely on a particular capacity: an application  should  be  designed  so  that  a  reading
       process consumes data as soon as it is available, so that a writing process does not remain blocked.

       In Linux versions before 2.6.11, the capacity of a pipe was the same as the system page size (e.g., 4096 bytes on
       i386).  Since Linux 2.6.11, the pipe capacity is 65536 bytes.
   PIPE_BUF
       POSIX.1-2001 says that write(2)s of less than PIPE_BUF bytes must be atomic: the output data is  written  to  the
       pipe  as  a  contiguous sequence.  Writes of more than PIPE_BUF bytes may be nonatomic: the kernel may interleave
       the data with data written by other processes.  POSIX.1-2001 requires PIPE_BUF to be at  least  512  bytes.   (On
       Linux,  PIPE_BUF  is  4096  bytes.)
The standard is also documented well. Unfortunately the man pages of other UNIXes out there contain little or no information on their implementation details. So I still want this survey for those to continue. Thanks for posting Cygwin! :)
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Post subject: UNIX users wanted for "pipe" survey
Emulator Coder, Experienced Forum User
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
If you use or have access to different flavors of FreeBSD, DragonFlyBSD, NetBSD, OpenBSD, Mac OS X, Solaris, or some modern UNIX, I'd appreciate your help. Some information is sorely lacking in documentation regarding pipe implementation details (except for in Linux), and I'd like to conduct a survey with your help. Please download, compile, and run the following code: Download pipesize.c
Language: c

#include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <fcntl.h> #include <sys/utsname.h> #include <errno.h> #include <limits.h> void output_system_id() { struct utsname n; if (!uname(&n)) { char *p = n.release; unsigned long major, minor, patch; major = minor = patch = 0; major = strtoul(p, &p, 10); if (*p == '.') { minor = strtoul(p+1, &p, 10); if (*p == '.') { patch = strtoul(p+1, &p, 10); } } printf("%s %lu.%lu.%lu %s\n", n.sysname, major, minor, patch, n.machine); } } int main() { union { int pipefd[2]; struct { int read; int write; } command; } u; output_system_id(); printf("PIPE_BUF size: %d\nPipe size: ", PIPE_BUF); fflush(stdout); if (!pipe(u.pipefd)) { int flags = fcntl(u.command.write, F_GETFL, 0); if (flags != -1) { if (fcntl(u.command.write, F_SETFL, flags | O_NONBLOCK) != -1) { size_t amount; for (amount = 0;; amount += sizeof(size_t)) { ssize_t w = write(u.command.write, &amount, sizeof(size_t)); if (w != sizeof(size_t)) { if (w == -1) { if (errno == EINTR) { amount -= sizeof(size_t); } else { if ((errno == EAGAIN) || (errno == EWOULDBLOCK)) { printf("%zu\n", amount); } else { perror("Failed to write to pipe"); } break; } } else if (!w) { perror("Pipe unexpectedly closed"); break; } else { amount -= sizeof(size_t); amount += w; } } } } else { perror("Failed to set pipe nonblocking"); } } else { perror("Failed to get pipe flags"); } close(u.command.read); close(u.command.write); } else { perror("Failed to create pipe"); } return(0); }
Example of how to compile and run:
/tmp> gcc -Wall -o pipesize pipesize.c
/tmp> ./pipesize
Linux 2.6.32 x86_64
PIPE_BUF size: 4096
Pipe size: 65536
/tmp>
Please post your output here. Thanks.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Emulator Coder, Experienced Forum User
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
adelikat wrote:
It is a false positive. There is nothing malicious about any lua dll hosted by fceux.com or tasvideos
Any reason why other lua51.dll files out there are a different file size?
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Emulator Coder, Experienced Forum User
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Warp wrote:
Nach wrote:
Stop getting worked up by extra input at the end of a run. Once you see the actual end, anything that does or doesn't happen is of no consequence. Worry about how many frames there were to reach the end, that's where the competition needs to be, not what happens after.
This is a bit in odds with the rules, which state: "It should end with the last input. Don't leave any blank input at the end of the movie."
If you submitted such a movie, we'd just trim the null input for you, no big deal. The idea is not to make extra work for us. Also recall the fight of four opinions on movie end.
Warp wrote:
Sure, you are not talking about blank input, but I believe the spirit of the rule is "the keypress file should end where the game ends".
Yes, but there can be exceptions. Battletoads in Battlemaniacs is one of them. The rule is talking about 99% of the time where there is no game after the game.
Warp wrote:
And that makes sense for practical reasons: If a keypress file could be as long as one wants (iow. have any amount of stuff after the end of the game), it would mess up with the automated movie length calculations. Suddenly you could have a 1-hour movie obsoleting a 10-minute one, yet still being claimed as being faster.
And indeed, such issues come up when switching between versions, which have happened before. We deal with it on a case by case basis.
Warp wrote:
Everyone here, judges or viewers, are intelligent enough to differentiate between the actual ending and further playing around that can be done during credits roll.
But the server software isn't. It would be confusing and raise questions if a seemingly significantly longer movie obsoletes a shorter one, yet still was claimed to be "x frames faster". It makes automatic timing reporting easier if the keypress file ends when the game ends. Moreover, it requires less work from the publishers and editors because they can see the length of the movie from the keypress file (which is what the server reports) rather than having to figure it out by estimating at which frame the game actually ends. With some games this might even be heavily a question of interpretation. The length of the keypress file is unambiguous.
You are correct. But we've already had to deal with ambiguous times differences due to changing between U to J and J to U in the past. In cases like this, it's also easy to figure out, just subtract actual game end time from what happens later. Also recall that once in our history, sgrunt's double obsoletion Metroid run obsoleted a movie which was a few frames faster than it. We've also had FCEU(X) runs obsolete *faster* Famtasia runs where we had to calculate if it was faster or not by differentiating the PAL at NTSC speed difference. None of us here are that stupid that we can't deal with a couple of extra seconds at the end of a run.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Emulator Coder, Experienced Forum User
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Just for the record, if you beat this run by submitting something 10 seconds *faster* by stopping to record sooner, we judges will just subconsciously add 10 seconds onto your "record" anyway. Stop getting worked up by extra input at the end of a run. Once you see the actual end, anything that does or doesn't happen is of no consequence. Worry about how many frames there were to reach the end, that's where the competition needs to be, not what happens after. If the credits roll allowed you to do all sorts of funny stuff during it, we'd love you to keep recording at that point. Remember, the movie we make shows the entire ending+credits, and full loop of the ending/credits music. It doesn't stop exactly when input stops. Everyone here, judges or viewers, are intelligent enough to differentiate between the actual ending and further playing around that can be done during credits roll.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Emulator Coder, Experienced Forum User
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
<nitrogenesis> um.. <nitrogenesis> hey look, a unicorn * nitrogenesis points to window <-- nitrogenesis has left this server (Quit: made you look.). <dada_> damn. made me look. <FractalFusion> that never gets old Maybe I should go outside and glue a tube from a roll of paper towels to a horses head, just so I can say I haven't looked in vain.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Emulator Coder, Experienced Forum User
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
<nitrogenesis> look over there, a pony! * nitrogenesis points to the window <-- nitrogenesis has left this server (Quit: made you look). The funny part is, I actually have a pony outside my window as I write this. Edit: A photo:
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Post subject: Per movie RSS API
Emulator Coder, Experienced Forum User
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
For those of you writing software to interface with our site, there is now an RSS feed generated per movie. These feeds aren't classic "feeds" where info is posted periodically, rather they are XML data conforming to RSS 2 and Media RSS 1.5 specifications which the publications feed is already using. With these feeds, you can get the same kind of info you would normally pull from the publications feed for any published movie, and not just those published recently. The feeds are located at http://tasvideos.org/<number>M.rss, for example: http://tasvideos.org/1000M.rss Enjoy!
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Post subject: Traffic Lights
Emulator Coder, Experienced Forum User
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
<ais523> sometimes pedestrians can cross when the lights are red for traffic, like in the US <ais523> (jaywalking is legal and pretty common in the UK, especially in central London, where the traffic system is heavily based around the 50% capacity theorem) <Nach> ais523: as an American, I find any notion of a pedestrian needing to wait for the light to change, or to cross with a cross walk to be completely absurd <ais523> Nach: I think the reason is that in the US, intersections between major roads are more common than in the UK <ais523> in the UK, typically most of the roads in an area are so minor that installing traffic lights on them at all would be a waste <ais523> and the only traffic controls they have are triangles on the road, that tell people to give way to traffic going in a different direction <ais523> people just walk across the road by hand when there are no cars coming <Nach> by hand? <Anonycat> they walk on their hands, of course
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Emulator Coder, Experienced Forum User
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
<Shinryuu> Hey Nachlion how's your soup <Nach> plenty of cotton and sweat in it :D <Shinryuu> :D <Nach> I have a unique soup design <Nach> it's sock soup, freshly ground <Nach> served in an electric sock to keep it warm <Nach> you can even taste the recursion
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Emulator Coder, Experienced Forum User
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
ALAKTORN wrote:
RaijinXBlade wrote:
Mothrayas wrote:
Really? I never noticed anything like that.
Yep. It's like as soon as the box finish fading onto the screen, and until it begins to fade out of the screen, that the whole box itself is like part of the text, or something. So basically, when the box is done fading in, you should hold start, and as it is fading out, start does nothing to speed it up. But as long as it is fully on screen (not fading in anymore) start will speed it up, this includes when the text is finished, as long as the box isn't fading out, you should be holding start to speed it up. I'm pretty sure I'm talking pretty stupidly right about now so all of what I say will be very veigue. That's what I get for not going to bed. I hope you can make that out.
does that mean there are many frames that could be saved?
If the text boxes could be sped up, I wouldn't say "many frames", there aren't that many conversation in this game. You have the conversations in the intro level. Bit, Byte, and Vile. Then against Doppler, Sigma, and the ending. And of course those with Dr. Light.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Emulator Coder, Experienced Forum User
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Glad to see this. The run was all around excellent. But it's really the small stuff that stand out. I appreciated approaching each boss with their own weapon. I loved watching how you dealt with enemies as you whizzed by them, and how active you were in the boss battles. The way you exploited the AI and new glitches really made it feel like you controlled the reality of the game. The wild jumping all over, and bypassing spikes and lifts were also enough to brighten up a dim day.
Jungon wrote:
Never thought there was another possible boss on Doppler Stage 1 .. o.o I'll be reading the author's comment to see if I can do it too someday .. xP
Read.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Post subject: Metal Slug X Nomination
Emulator Coder, Experienced Forum User
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
When the new Metal Slug X gets published, I nominate that it gets a new star. I don't think we have any starred runs which are of a similar nature that should lose a star to it. The run is of a popular well known game, has tons of intense action, competitive time, great two player coordination, and smart weapon management. I think it would greatly benefit TASVideos to place it among our elite movies recommended for first time viewers.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Emulator Coder, Experienced Forum User
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Flygon wrote:
I'd imagine that if the staff team was going to use VP8, they'd trial by publishing two encodes at once or something. I don't claim to know how the site works anymore, I just claim to say that VP8 is a risker technology to use than the current tried and tested technology, particularly since the results seem quite variable. It is worth noting that the VP8 videos on YouTube for a given video mode do tend to have a worse video quality.
We're not going to use VP8 on the site till extensive research is done. This is just a call to do some testing to see where the technology stands.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Emulator Coder, Experienced Forum User
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
<Mothrayas> actually, nukes are too boring. i'll try a more fun option instead. * Mothrayas sets up kill satellite <Nach> Mothrayas: we have bioweapons too <Nach> and we can enter target DNA patterns into them for selective killing <Nach> Patryk1023: have you ever donated blood? <Patryk1023> Nach: no <Nach> Patryk1023: mind donating a saliva swab? <Patryk1023> Nach: also no <dada_> when someone asks you "do you mind", then saying no means you agree <Patryk1023> :P
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Emulator Coder, Experienced Forum User
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
X2poet wrote:
No voters make no sence and didn't give their opinion.
Probably because they felt what they said previously regarding the other recent BA2 submissions apply to this too, and no point reiterating it.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Emulator Coder, Experienced Forum User
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Flygon wrote:
The point of encodes are generally to provide a high quality media playback file that's also widely compatible. Unless things have changed internally since I retired, this is the reason the H264/AAC for MP4 and H264/Vorbis for MKV combinations are so widely used.
The point of encodes are to provide high quality videos for our viewers to enjoy. We use H264/AAC for MP4 and H264/Vorbis for MKV because that's been giving us the best file size combination in recent years. All the up to date video players can already play WebM, and last I checked, we like to be at the head of technology. We used Bit Torrent and H.264 before most people ever heard of these technologies or were in mainstream use.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Emulator Coder, Experienced Forum User
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Flygon wrote:
Otherwise, I don't foresee it being particularly useful, factoring the compatibility risks.
If the quality turns out to be the same, if for some systems (games), the WebM file we produce can be half the size, you don't think that's useful?
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Emulator Coder, Experienced Forum User
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
This may not be indicative of anything, but I just spent some time grabbing some stats from YouTube. I looked at some medium sized and large (labeled 720p) auto encodes there for H.264 in MP4 versus VP8 in WebM. The results surprised me a bit. For MSX, NES, SNES, CGB, and SGB, the VP8 ones were generally a bit smaller. In some cases, I found VP8 to be half or a third of the size of H.264 one. For DMG, AGB, PSX, and N64, H.264 generally had the superior file size. In the case of DMG it was on average 30% larger, in other cases, 10-15%. I didn't check quality in any of these cases, and this is not at all indicative of the results we'd get with manual encodes where we can tweak the settings. But if this is not just a case of YouTube's H.264 encoder settings for some games being lousy, then there may be something useful here that we can learn. Any encoders want to look more into this?
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Emulator Coder, Experienced Forum User
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
I agree with Pasky13, I don't find entertainment in this run either. I'd much rather have the music you're trying to play in a separate wav file, or in a video of a normal piano program. If I knew what I was listening for, maybe it would help... I recognized some famous tune which I don't know the name of, and I think something from Zelda and Metroid, but it's hard to make out with the other tune being played at the same time, and how limited you are with this piano. Perhaps instead of pictures at the beginning, you can write down what to expect later music wise? It would make the run a bit more cohesive.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Emulator Coder, Experienced Forum User
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
<BrandonE> DrNach: Did you notice that Journey to Silius is now Console Verified? <DrNach> BrandonE: why isn't that marvelous, wake me when you have real news <BrandonE> <_< <BrandonE> >_> * DrNach pats BrandonE on the head
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.