Posts for Bisqwit


Editor, Experienced Forum User, Published Author, Active player (296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Thank you for the answers. I recommend you put the relevant PCSX related information to the TASVideos site as well, by editing pages such as PXM.html. I have granted you the editor access, mz. Also, please specify how the "compressed" things work. And any other implicit knowledge.
Editor, Experienced Forum User, Published Author, Active player (296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
aglasscage wrote:
I used frame by frame and I was able to produce a death here (not sure if this is already known/obvious or something), it is not what I was looking for but could this be related maybe?
This one looks like the regular old "delay-death". Substituted scrolling (exit) flags due to lag, yielding a value that indicates "no down scrolling". In that situation, falling to the bottom of screen yields death. However, the scrolling flag is different from the stripe length variable. The scrolling flag is a bitmask that tells where the exits of the room (the last room of the stripe, I think) are: "can scroll up?", "can scroll down?", "shutter on the right side?". Whereas stripe length tells how many screens there are in a smooth-scrolling horizontal sequence without a shutter.
Editor, Experienced Forum User, Published Author, Active player (296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
I edited the first post by clarifying some things about the schedule and the required responsibility shifts. Re: Development -- developer access will be opened once I get the site-update system developed and finished.
Editor, Experienced Forum User, Published Author, Active player (296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Very well. As for the A/V desync, and actually everything else I've got a reply for, I'm going by the good faith and accepting this emulator as of now. Could someone please update the PXM page by replying to the questions about the version number stuff? (For now, the PXM parser ignores the version number fields.) And also, update Rules to indicate this change -- feel free to enter the proper version number things, I don't know anything of them.
Editor, Experienced Forum User, Published Author, Active player (296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
aglasscage wrote:
Bisqwit wrote:
Looks like someone edited the RAM to give the game wrong ideas about the map layout -- particularly, the room number and current stripe length, and then created a savestate-anchored movie to demonstrate the effect.
Can't be. It was on the normal "Rockman 2 Dr. Wily No Nazo" and I wouldn't know the first thing about editing the RAM. I was playing along in real time when the screen could move left to my suprise. The far right ladders work and you can continue to move upwards.
Too bad you didn't make a movie that begins before the incident to prove this claim. If this is indeed true, it could prove very useful.
Editor, Experienced Forum User, Published Author, Active player (296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
No Mega Man games? No Doom? No Space Invaders? ;) Bleh.
Editor, Experienced Forum User, Published Author, Active player (296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
aglasscage wrote:
what happened here? http://dehacked.2y.net/microstorage.php/info/1121913087/WhatHappenedHere.fcm
Looks like someone edited the RAM to give the game wrong ideas about the map layout -- particularly, the room number and current stripe length, and then created a savestate-anchored movie to demonstrate the effect.
Editor, Experienced Forum User, Published Author, Active player (296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
mz wrote:
Bisqwit wrote:
I'm not sure what you mean by this. When replaying the movie, the emulator should use whatever setting is in the movie file without considering external facts, such as the actual ROM type. Otherwise, the movie file can be faked to indicate wrong length.
You can also fake the length if you save your movie in NTSC mode but you use a PAL game, or something like that.
Yes, but in that case the error at least gets caught as people notice the game plays at wrong length speed. The issue is that it must be never possible for the movie file to contain data different from that used by the emulator. If the movie file header lets one believe that the movie length is 10 minutes and 20 seconds (based on the number of frames and the NTSC/PAL selection), then for 10 minutes and 20 seconds, precise, must the movie file play. Otherwise, no website can list PXM files and determine their play length without running the entire emulator first. And so on.
Editor, Experienced Forum User, Published Author, Active player (296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
mz wrote:
Bisqwit wrote:
Continuation to the movie length question: You replied that the FPS is constant -- 60 FPS for NTSC, 50 FPS for PAL. Can the NTSC/PAL issue be determined from the movie file? Does the emulator honor this flag? (I.e. it must not be possible to set the flag to cheat the submission system while the emulator ignores the flag and only reads the ROM.)
It can be determined from the movie file, but only to calculate the run time. The emulator works on "autodetect" normally, but it can be forced to run on NTSC or PAL. I will modify it now so it forces the "autodetect" mode while recording/replaying a movie.
I'm not sure what you mean by this. When replaying the movie, the emulator should use whatever setting is in the movie file without considering external facts, such as the actual ROM type. Otherwise, the movie file can be faked to indicate wrong length.
Editor, Experienced Forum User, Published Author, Active player (296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Xkeeper wrote:
The problem with newbies making TASes is that, well... Consider how highly you've raised the bar. Most well-known games are at the point of subpixels/halfframes/whatever optimization. To the point where assembly or extensive knowledge of emulator-external tools is known. You have basically strived for a level of perfection so high that only the people who got that far in the first place can achieve it.
That is naturally true for already competed games. Still, for new games, I wish to keep the bar lower. Unfortunately there aren't that many new games anymore...
Editor, Experienced Forum User, Published Author, Active player (296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
UI brainfarts such as "no commandline support" or "no ISO file support" are not critical to accepting the emulator. The latter does narrow down the group of encoders to the people who are willing to work with that limitation. Lack of Linux support is also not critical to accepting the emulator. It just means that the group of encoders is narrowed down to Winblows-folks. Continuation to the movie length question: You replied that the FPS is constant -- 60 FPS for NTSC, 50 FPS for PAL. Can the NTSC/PAL issue be determined from the movie file? Does the emulator honor this flag? (I.e. it must not be possible to set the flag to cheat the submission system while the emulator ignores the flag and only reads the ROM.) For many points, you replied with "the SVN version does". Fabled SVN version -- how many have tested it? You mentioned sound sync as a major problem. It has been a large problem with mupen64 as well. In my recording system, I devised my own A/V sync code into mupen64. For PCSX, I no longer have this option as I'm not going to have much time to work for these anymore. But then again someone else can do that.
mz wrote:
third-party tool, which produces perfect 60 FPS videos, even on a very slow computer.
Sounds useful. Emulation accuracy is something we have no choice with, so we just have to accept it. I'm keeping a hopeful eye on pSX, but as long as we don't have that, we must work with what we have. So in fact we have two open critical questions -- one about FPS and the other about SVN. I cannot tell whether the sound sync problem is a critical problem or not. Perhaps someone who has actually tried the AVI recording could tell?
Post subject: Re: from the squirrel's mouth
Editor, Experienced Forum User, Published Author, Active player (296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
UI brainfarts such as "lack of commandline support", "crash if select options in wrong order" are not critical to accepting the emulator. However, not being able to calculate the movie length (in seconds) automatically from movie file alone is a critical issue, because it undermines our movie verification process. Unrobust AVI recording & movie playback is also likely a critical issue. It can however be solved with a crude hack by someone with AVI encoding experience & programming skills, as I have done on many occassions. I don't know anything about FBA though, and I don't have time to study, so count me out. Otherwise this emulator seems to be close to accepting, yes.
Editor, Experienced Forum User, Published Author, Active player (296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Let's go through the approval process... What is the current status with this emulator with regards to these pages: http://tasvideos.org/EmulatorResources/Features.html http://tasvideos.org/EmulatorResources/Requirements.html Let's start with: -- Does it work on most systems by simply extracting a package, running the executable within, selecting a ROM, and clicking a "load" button, and then just playing, without need to run configuration & plugin selection? -- Are the most used options accessible on the commandline? I.e. can I launch e.g. "fba x.iso test.pxm" to have it bind "x.iso" to the emulated CD drive and playback the "test.pxm" movie, with no pointing&clicking or other types of menu navigation needed? -- Continuation to the commandline topic: Can AVI recording also be activated from the commandline? -- Does it compile with free/libris development tools (MINGW/GCC toolchain)? -- Does it work on Linux? (WINE not accepted; most plugins are high-likely not WINE-compatible) -- Is the rendering quality (audio & video) close to original? -- Do most popular games work on it? -- Is it stable, i.e. does not crash if you navigate menu accidentally in the wrong order or leave some checkbox unchecked? -- Is the movie file format stable? I.e. does it include all the necessary things? -- Continuation: Does the movie file format include a way to tell whether the movie begins from a cold reboot (power cycle), from a soft reboot (reset button) or a savestate? -- Continuation: Does the movie file format include a way to tell the FPS on which the movie runs? Is the said FPS constant throughout the movie? I.e. can the movie length in milliseconds be derived from the movie file alone, tamper-securely? -- Continuation: Does the movie file format include way to include soft reboot (reset button) events in the movie? -- Can the movie be paused and/or speed changed during playback, without these actions affecting the sync of the movie? -- Related question: Can the movie be paused and/or speed changed during playback, without these actions affecting the A/V sync or the playback speed within the AVI that is produced during the playback, if AVI recording is activated? Answers from the horse's mouth, please. :) Also, I don't have any idea how FBA works. Or how arcade machine ROMs work. Or compatibility. Or whatever. Or what kind of things the movie recording should consider. The above list is a generic one based on the list I asked about PCSX.
Editor, Experienced Forum User, Published Author, Active player (296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
I think "phonetical spelling" is the worst bad joke in English. Seriously. "a" is sometimes an /ə/ vowel (schwa, such as in "woman" or "a"), sometimes an /eɪ/ diphthong (such as in "bake", "cater"), sometimes an /e/ vowel (such as in "bait"), sometimes an /æ/ vowel (am. "cat"), sometimes an /ɑː/ long vowel (br. "task"), sometimes an /a/ vowel (br. "cat"), sometimes an /ɪ/ vowel ("break"), sometimes an /ʊ/ vowel ("boat"), sometimes an /ɔ/ vowel ("pause"), sometimes an /i/ vowel ("beak")… How's that phonetical, when you can't make heads or tails how a letter is to be pronounced? Using English spelling rules is extremely unsuitable for expressing pronounciation. You need to add extra letters such as "h" to work around the inconveniences of the spelling system to express what you want. And still you cannot express how to pronounce the Finnish name of Yliluoma (IPA: /yliluomɑ/), for example. That's why I always use IPA. Letters in IPA pronounciation keys are always pronounced the same way no matter what surrounding context or what language they represent (with exception allophones, which are miniscule variations in the phoneme).
Post subject: Re: The big PUSH!
Editor, Experienced Forum User, Published Author, Active player (296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
andymac wrote:
P.S.Also can anyone tell me the correct pronunciation of TAS? I always pronounced it tazz.
Like so: IPA: /ˈtæs/ As in the English word "task" but without "k". TASVideos: /ˈtæsˈvɪdˈɛəʊz/
Editor, Experienced Forum User, Published Author, Active player (296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Running MySQL repairer. Should be fixed in a moment. Thanks for reporting.
Editor, Experienced Forum User, Published Author, Active player (296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
mega_man_3 wrote:
In the game I know that Mega Man's pixelation goes like this: 1-1-1-2-1-1-2-1-1-1-2-1-1-2-1-1-2-1-1-1-2-1-1-2-1-1-2 then it starts from the beginning.
Well, almost, it is 01.4C (hex) pixels (1.296875 in decimal) per frame as indicated at http://tasvideos.org/RockmanTricks.html#SubpixelPositionOptimization . So the cycle is not 1-1-1-2-1-1-2-1-1-1-2-1-1-2-1-1-2-1-1-1-2-1-1-2-1-1-2- but 1-1-1-2-1-1-2-1-1-1-2-1-1-2-1-1-2-1-1-1-2-1-1-2-1-1-2- 1-1-1-2-1-1-2-1-1-1-2-1-1-2-1-1-2-1-1-1-2-1-1-2-1-1-2- 1-1-1-2-1-1-2-1-1-2- :) Your guess implied a movement rate of 1.296296[...] (1.4BDA12F684BDA12F68[...] in hex) pixels per frame, which isn't accurate. Which is anyway completely irrelevant if you can track the actual numeric subpixel position from the game's RAM. :)
Editor, Experienced Forum User, Published Author, Active player (296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Randil wrote:
Truly an awesome run. Entertaining from start to finish. My favourite part was Wood Man's stage. :) I think I'll give this 8.9/9.3. A question though: What's up with the missed shot on frame 61660? The shot goes above the enemy and doesn't seem to hit anything. Is it to manipulate luck?
Looks like luck manipulation for the weapon refill drop. More commonly they were to induce the right lag conditions for substituted screen scrolling.
Editor, Experienced Forum User, Published Author, Active player (296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Phallosvogel wrote:
doesnt the emulator have to be open source to get official?
No, if it has all the necessary features. Famtasia was one such example (though on today's scale, it doesn't have all necessary features ;) )
Editor, Experienced Forum User, Published Author, Active player (296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
CtrlAltDestroy wrote:
All I have to say is that the Mecha Dragon battle was the best boss battle I have ever seen in a TAS, ever.
It encapsulates the "screw you, I'm going home" attitude quite well.
Editor, Experienced Forum User, Published Author, Active player (296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
I like the double Special Thanks list :) I watched this submission before submitting, and I must say it is a very satisfying result to the years' plight on this game. I'm giving out a rare 10/10 rating.
Editor, Experienced Forum User, Published Author, Active player (296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
nineko wrote:
Just out of curiosity, what is the NES game with a bitrate of 9.8144029716529?
Metal Storm. It has a multi-layer parallax background and it was encoded with DIVX, which means that there was little to none chances for motion encoding. http://tasvideos.org/MovieStatistics.html#LowestAviCompressionRatio http://tasvideos.org/MovieStatistics.html#HighestAviCompressionRatio
Editor, Experienced Forum User, Published Author, Active player (296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Everything I should say has probably already been said, but here goes anyway. The 4 MB/minute limit was invented with a modified Harrison&Stetson method, i.e. an arbitrary value was chosen with intuition and verified against a few cases, to determine whether it is a good limit. For different consoles, the average varies. Actually, why not do the math here.
mysql> select s.abbr, min((filesize/1e6)/(length/60))mi, avg((filesize/1e6)/(length/60))av, max((filesize/1e6)/(length/60))ma from movie_file mf,movie m,filetype t,system s where mf.movieid=m.id and m.systemid=s.id and t.filetype=mf.typech and filetypeclass='T' group by s.abbr;
+---------+-------------------+------------------+------------------+
| abbr    | mi                | av               | ma               |
+---------+-------------------+------------------+------------------+
| GB      | 0.572175849272519 |  1.4087359767177 | 2.33612181818182 | 
| GBA     |  1.34804613861386 |  2.8145274068148 | 6.20754240674907 | 
| GBC     | 0.767979931209014 |  1.2569075060325 |  1.8114107364037 | 
| Genesis | 0.975704864864865 |  2.9559998754507 | 6.30503649295637 | 
| N64     |  2.35566726298707 |  2.9585978329765 | 3.87445178347063 | 
| NES     | 0.646402777777778 |  2.1354393788815 |  9.8144029716529 | 
| SGB     |  0.60576729658376 | 0.90576560167766 | 1.43155425373134 | 
| SMS     | 0.870126857142857 |  1.6502879425395 |  2.4848148482854 | 
| SNES    |   1.1508051414501 |  2.8344977178136 | 5.48289923076923 | 
+---------+-------------------+------------------+------------------+
The above is for all publications, including obsoleted AVIs. Here's the same table for currently published movies.
+---------+-------------------+-----------------+------------------+
| abbr    | mi                | av              | ma               |
+---------+-------------------+-----------------+------------------+
| GB      | 0.572175849272519 | 1.3884989196617 | 2.33612181818182 | 
| GBA     |  1.38530359840954 | 2.9467362692611 | 6.20754240674907 | 
| GBC     | 0.767979931209014 | 1.2139071291976 |  1.8114107364037 | 
| Genesis | 0.975704864864865 | 2.8845012522829 | 6.30503649295637 | 
| N64     |  2.57872355200365 | 3.0857642439087 | 3.87445178347063 | 
| NES     | 0.661616585365854 |  1.837647967182 |  9.8144029716529 | 
| SGB     |           0.84024 | 1.0699646815687 | 1.43155425373134 | 
| SMS     | 0.870126857142857 |  1.714521622153 |  2.4848148482854 | 
| SNES    |   1.1508051414501 |  2.724627874046 | 5.48289923076923 | 
+---------+-------------------+-----------------+------------------+
This graph tells us, that for every console, the average encoded AVI/MKV/whatever size has been about 2 MB/minute, give or take some 1.1 MB/minute. For SNES, GBA, Genesis, and surprisingly, NES, exceptions have been made sometimes over the 4 MB/minute limit, with the highest bitrate for SNES having been 5.5 MB per minute. These exceptions usually need to be made for movies with lots of full-screen movement that is not compensated by either motion estimation or frame history referrals, because the screen contents change entirely, and for movies that contain colour schemes that are particularly difficult because of chroma supersampling (for example, black objects on a blue or red background). In general, the visual and aural quality of our AVIs has been very good. ShinyDoofy's most recent encode of Shinryuu's Mega Man 6 movie is an outstanding proof of this claim. Even with a trained eye, I cannot find encoding artifacts in his video with casual inspection. His movie uses 2.2 MB per minute. There have indeed been some movies with not so good quality. In those cases the blame lies either on the too modest bitrate that the encoder used, or on too lazy settings the encoder used for the fear of consuming too much CPU time in the encoding. We encourage our encoders to use the strongest possible encoding settings of the codec in order to produce the best quality per bit value. The MEncoder mantra that I use ifor my encodings with x264, is this: partitions=all:me=umh:frameref=15:me_range=64:subme=7:mixed_refs:trellis=2:ratetol=60:subq=7:direct_pred=auto, together with multi-pass encoding to produce the most optimal distribution of bits within the file. This does not even include B-frames. I don't think B-frames are particularly useful with NES, but they may be useful with 3D content on N64 and PSX (and vector/scaledbitmap content on SNES and GBA). We also encourage our encoders to visually inspect their result and to see if there are encoding artifacts that should be addressed (by changing the codec settings and re-encoding) before the AVI is published. In the rare cases that a larger bitrate is indeed needed -- this happens usually for racing games and for some 3D games -- a developer of the TASVideos site needs to be contacted by the publisher to manually disable the limit temporarily for the duration of filling the publication form. For now, the only person that can do that is me, but I'm hoping to change that fact soon. Regarding Johannes's claim that the ratio is too low for N64...
+---------+-----------------------------------+------------------+
| movieid | gamename                          | mbpermin         |
+---------+-----------------------------------+------------------+
|    1029 | Tony Hawk's Pro Skater 3          | 3.87445178347063 | 
|    1190 | Super Smash Bros.                 | 3.82257774859752 | 
|    1211 | Mischief Makers                   | 3.62135403109398 | 
|     975 | 007 - The World is Not Enough     | 3.49640452173913 | 
|     886 | Wetrix 64                         | 3.43624058924595 | 
|    1229 | Legend of Zelda - Ocarina of Time | 3.35597524190427 | 
|     530 | Tetrisphere                       | 3.30907050706493 | 
|     957 | Duke Nukem 64                     |  3.2286800456013 | 
|    1197 | Super Mario 64                    | 3.14568689450763 | 
|    1238 | Chameleon Twist                   | 3.10092146788991 | 
|    1007 | Goldeneye 007                     | 3.02810797342193 | 
|     962 | Glover                            |       2.96598544 | 
|     963 | Legend of Zelda - Majora's Mask   | 2.81573428140494 | 
|     808 | Gex 64 - Enter the Gecko          | 2.79031657176988 | 
|     946 | Diddy Kong Racing                 | 2.77021529065256 | 
|     850 | Super Mario 64                    | 2.72489028646749 | 
|     759 | Mortal Kombat 4                   | 2.70063864713825 | 
|     576 | Legend of Zelda - Ocarina of Time | 2.69789365087056 | 
|    1095 | Turok - Dinosaur Hunter           | 2.68556397802107 | 
|    1237 | Gex 3: Deep Cover Gecko           | 2.65161661921689 | 
|    1229 | Legend of Zelda - Ocarina of Time | 2.57872355200365 | 
+---------+-----------------------------------+------------------+
Is it indeed the limit that has been too low, or has it been the encoders who have been too modest? I guess Tony Hawk's World Is Gray could have used an exception. Super Smash Bros is a suspect. Zeldas and Marios look quite fine, though if they needed to be encoded at a higher rate, it could be done without offending the threshold. My verdict is: Thus is good.
Post subject: Dual movie of Mario classics: Wrecking Crew & Mario Bros
Editor, Experienced Forum User, Published Author, Active player (296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
A dual movie for a dual movie's sake... Here's another contribution of mine to the list of unfinished WIPs. https://files.tasvideos.org/bisqwit/bisqwit-marioclassicdual.fcm (length: <2 minutes) (AVI: 3 MB : https://bisqwit.tasvideos.org/pending/bisqwit-marioclassicdual.avi )
Editor, Experienced Forum User, Published Author, Active player (296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
ShinyDoofy wrote:
/Edit: are there really two seperate threads about the same emlator? I was referring to the other thread by mz and PCSX 0.005.
Seems that way.