TASVideos

Posted: 12/1/2011 6:53 AM

Quote

Ilari

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1142)

Joined: 5/1/2010
Posts: 1217

ledauphinbenoit wrote:

The script should probably be updated to use NHMLFixup2. This (hopefully) corrects some warnings Ilari was finding.

NHMLFixup v10 should work just as well (if one doesn't need snap to fps or more advanced AR flagging).

Posted: 11/29/2011 6:31 PM

Quote

Ilari

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1142)

Joined: 5/1/2010
Posts: 1217

Warp wrote:

1) The Heisenberg uncertainty principle states that it's not possible to know both the exact position and momentum of a particle at the same time. However, what happens at absolute zero temperature, where all motion stops?

Actually, all motion does not stop, all particles just collapse to lowest possible energy state. And due to Heisenberg uncertainity principle, that energy state does not have zero energy. So there is still motion.

Posted: 11/16/2011 8:39 PM

Quote

Ilari

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1142)

Joined: 5/1/2010
Posts: 1217

CoolKirby wrote:

So theoretically a movie could be unpublished without recoding the site? I thought it was impossible.

The site interface doesn't allow removing publications, that requires directly mucking with the database.

Posted: 11/16/2011 8:06 PM

Post subject: Re: Publication number 1916 skipped

Quote

Ilari

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1142)

Joined: 5/1/2010
Posts: 1217

CoolKirby wrote:

Why was publication 1916 skipped? The publications just go 1914, 1915, 1917...

Basically, publishing 1916M hit the publication bug and the attempts to repair messed up the database. While hitting publication bug would not ordinarily cause publication number to be skipped (at least 3 such publications have been successfully fixed), Grunt thought a good way to fixing it would be to unpublish the movie and then republish. Unfortunately, doing this got the site database into some weird state where the entry for 1916M both existed (attempts to add it were rejected as duplicate) and didn't exist (attempts to look it up returned row not found) at the same time. Thus, the movie was republished as 1917M and 1916M was left as a gap.

Posted: 11/13/2011 5:35 AM

Quote

Ilari

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1142)

Joined: 5/1/2010
Posts: 1217

Master of Puppets wrote:

While you did have to modify the file for it to play properly, it still prove that the glitches/shortcut used are valid, and that if mupen 64 was fully accurate, that the run would be 100% verifiable.

I interpreted the statement about conversion differently: N64Bot (or Droid64) can't directly read .m64s, so SoulCal apparently took the .m64 file and converted it to whatever format N64Bot/Droid64 reads (most likely raw binary dump to be sent to N64 according to clocking). There is only one possible result for such conversion for each .m64. Sometimes extra frames are inserted to fix sync problems (sometimes that helps) but it doesn't sound SoulCal needed to do that here. Due to nature of .m64 format, what wasn't validated here is correctness of lag on Mupen64.

Posted: 11/13/2011 4:54 AM

Quote

Ilari

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1142)

Joined: 5/1/2010
Posts: 1217

The Wanderer wrote:

When I try to download the published run from either of the two torrents, using BitTornado, I get a "bad bencoded data" error. I get the same when I try to even display the file information using btshowmetainfo. Essentially, some clients (adhering rigidly to the BitTorrent spec) will choke on any torrent file which either includes extra data at the end or puts its fields out of alphabetical order. Was something done differently when generating these torrents? Is there any chance of updated torrent files which don't have this problem?

Oops, the torrents used incorrect webseed type (httpseeds as opposed to url-list). I edited those files by hand (hex editor!) but didn't remember to rearrange the fields. I'll edit those torrents again. Okay, done (and updated the torrent files on site)

Posted: 11/7/2011 7:18 PM

Quote

Ilari

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1142)

Joined: 5/1/2010
Posts: 1217

haslomaslo1 wrote:

Profiling shows two parts of code that eat a lot of the time: Executing microcode and running the clock. The clock looks mostly optimal, I chopped out a couple of bits that just give an informational message, but that (not surprisingly) did not result in any major speedups, if any.

Actually, one could optimize it (don't know how much) by not polling for timers every instruction, but only for known timer events: The timer would be run on: * Ucode block abort/exit * Before waiting (HALT) * After there would be known timer event. The cached next event would have to be updated after: * Ucode block entry * After any operation that can execute timer events (including HALT and polling for timers). The only thing that can unpredictably add timer events in the middle of ucode block are input events, and internally those are added by timer events, in order to guarantee that the sequence is repeatable (furthermore, there is never a long gap between two timer events, since there's always activity going on).

haslomaslo1 wrote:

Nothing that I can take out of the microcode part, not without deep thinking anyway.

If you want to deal with some real black magic code: The JIT CPU core from original JPC, that should be much faster, but unfortunately making it work is far from trivial (I tried to make it work today, got lots of cryptic runtime errors). Here is rough listing of things that have been done to the CPU core: - CodeBlockManager has dummy methods to save/load it: * void dumpSRPartial(SRDumper output) * CodeBlockManager(SRLoader input) * This class implements interface SRDumpable. - New ucode op: INSTRUCTION_START. * This ucode is emitted as first ucode op of every instruction (by both x86 to ucode compilers (one for real and one for protected mode). * It advances the clock (if HALT is not in progress, as otherwise halt being aborted would advance clock twice), checks for self-modification of current block (aborting the block if it finds one if certain CPU flag is set). - FPU handling is split to FPU class itself. - Modifications to HALT in protected mode to cut down message spam from some games (those call HALT a lot from CPL != 0, which would normally trigger a message). There are two new processor exceptions, neither of which is to be passed to the quest: TRACESTOP and SELFMODIFY TRACESTOP is raised by INSTRUCTION_START if cpu.eflagsMachineHalt is set. This causes block to abort, with cpu.eflagsLastAborted being set and CPU instruction counter backing one place. SELFMODIFY is actually handled the same way as TRACESTOP by the CPU core. It is raised by INSTRUCTION_START if current ucode block has been modified.

Posted: 10/31/2011 4:36 PM

Post subject: Re: Need help about editing movie.

Quote

Ilari

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1142)

Joined: 5/1/2010
Posts: 1217

Joebloe wrote:

Every time im finished, i have to stop the movie (like everyone else i presume)and when i want to work again on it i have no idea how to start from the same point on the same movie.

I have never really used Visual Boy Advance, but I think it goes this way: * Before exiting the emulator, save a state * Exit the emulator * Start the emulator again * Load the same ROM * Load the save state you made.

Posted: 10/29/2011 1:36 PM

Quote

Ilari

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1142)

Joined: 5/1/2010
Posts: 1217

I did C++ version of this program (All ISO C++11 except for use of expat): http://www.elisanet.fi/ilari_l/NHMLFixup2-v2.zip It lacks audio delay feature (omitted because that feature was a bad idea) but otherwise has all the features of NHMLFixup v10 (and more). It hasn't been tested as well as the original NHMLFixup, so it is probably still buggy. Command line syntax is a bit different Syntax: NHMLFixup2 [<options>...] <nhml> <nhml> -s / --tvaspect : Use DAR of 4:3 -w / --widescreen : Use DAR of 16:9 -d <x>:<y> / --dar=<x>:<y> : Use DAR of x:y -r <x>:<y> / --resolution=<x>:<y> : Use resolution x:y for AR purposes -a <x>[/<y>] / --assume-fps=<x>[/<y>] : Use fps of <x>/<y> -t <file> / --timecodes=<file> : Use <file> for timecodes.

Posted: 10/28/2011 10:40 PM

Post subject: Re: I need help with SoX Sound Exchange.

Quote

Ilari

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1142)

Joined: 5/1/2010
Posts: 1217

The Mario with Famtasia wrote:

SoX somehow just won't work, it appears on the screen for like half a second, then it disappears, can somebody please help me?

Run it from command prompt so any possible error message will stay on screen long enough to copy (instead of just disappearing immediately) Also if you are just double-clicking it on explorer... That won't work because that program is command line based and needs arguments to tell it what it is supposed to do.

Posted: 10/28/2011 12:20 PM

Quote

Ilari

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1142)

Joined: 5/1/2010
Posts: 1217

sikomatik wrote:

Ok but why DeDup dont work when i try to load it ? That mean that the pass= 2 line also not work or ?

You get some error about dedup.dll not being found or somesuch? As far as I know, that is usually caused by not having the libraries dedup.dll itself requires.

sikomatik wrote:

What is better ? ConvertToYV24(chromaresample="point", matrix=(hd ? "Rec709" : "PC.601") ) ConvertToYV12(chromaresample=(hd ? "point" : "lanczos"), matrix=(hd ? "Rec709" : "PC.601") ) or the lines in the encoder guide HD? ConvertToYV24(matrix="Rec709", chromaresample="point") ConvertToYV12(matrix="Rec709", chromaresample="point") And is that part important for HD encoding ?

If hd is true, these two are precisely the same thing (this can be seen by simplifying the code with assumption that hd = true.)

sikomatik wrote:

or is this only for handheld ?

When it comes to AVISynth script, the resolution computation is different for handhelds, otherwise there is no difference. Hypothetical handheld with 256x224 resolution would give 1536x1344 HD resolution, where non-handheld of the same resolution (NTSC (S)NES) gives 3584x2688.

sikomatik wrote:

factor = hd ? ((sourcevideo.height > 540) ? 1 : \ (sourcevideo.height > 270) ? 2 : \ (sourcevideo.height > 180) ? 3 : 4) \ : 1 b = sourcevideo.PointResize( \ sourcevideo.width * factor, sourcevideo.height * factor \ width= (b.width > b.height * 4 / 3) ? b.width : b.height * 4 / 3 width = (width % 4 == 1) ? width + 3 : \ (width % 4 == 2) ? width + 2 : \ (width % 4 == 3) ? width + 1 : width height = (b.width > b.height * 4 / 3) ? b.width * 3 / 4 : b.height height = (height % 4 == 1) ? height + 3 : \ (height % 4 == 2) ? height + 2 : \ (height % 4 == 3) ? height + 1 : height c = handheld ? b : ( \ hd ? b.PointResize(width, height) : b.LanczosResize(width, height, taps=2) \ ) g = hd ? c.PointResize(c.width * 2, c.height * 2) \ : ((pass == 0) ? c : sourcevideo) multi = g.height / 224 multi = (multi > (g.height / sourcevideo.height)) ? multi : (g.height / sourcevideo.height)

This is the scaling/AR precorrection code. From looks of it, it uses the older method for HD.

Posted: 10/28/2011 8:32 AM

Quote

Ilari

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1142)

Joined: 5/1/2010
Posts: 1217

EEssentia wrote:

What does confuse me, though, is the two passes. x264 can be done in one pass, but perhaps DeDup needs two passes?

That is internal AVISynth architecture limitation. The architecture requires streams to be seekable, which necessitates two passes (first to get what frames are "identical" and second to actually drop the frames). Actually, with modern encoding methods (especially for N64) one needs three passes (both 2nd and 3rd are done with 'pass=2'), because x264 requires complete timecode file right at the start (or at least used to). Dedicated dedup filters (like dedup.c) can do this stuff in one or two passes (vs 2 or 3 required by AVISynth).

EEssentia wrote:

If so, you can save a lot of time by removing those lines (at the expense of some bigger files).

Only, for downloadable HD, which I think isn't actually used (dedup is hostile to flash and to streaming sites). For normal downloadables (which are currently the only thing using dedup) the first pases are done with very fast settings (usually getting hundreds of fps) and only the last one is slow.

Posted: 10/23/2011 6:39 PM
(Edited: 6/4/2022 4:56 PM)

Post subject: Re: Sound emulation problem, tassing God of Thunder in JPC-rr

Quote

Ilari

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1142)

Joined: 5/1/2010
Posts: 1217

Svimmer wrote:

When I do include that module in the assembly, the game thinks there’s a SoundBlaster (as it probably should). However, this means that I first have to run the sound setup executive. But here’s the snag. The sound setup requires a restart to be effective!

Nope, setblast is not needed. That tool just edits autoexec.bat, but the command it stuffs there can just be executed manually. On DOS prompt before starting the game, issue command: "SET BLASTER=A220 I5 D1 H5 T6" before running the got.exe. No restart needed (even if the emulator is capable of recording system restart, system -> reset). I experimented with the game a bit, and it seems that it depends on phase of the moon if it detects the sound card or not. Be careful and check that the game really detects the sound card (trying to set sounds to digitized could be useful check). Using / not using I/O delay is useful for perturbing stuff here. Edit: I actually modified the emulator to print the I/O traffic with the sound card. The game seems to use nonstandard method for detecting Soundblaster. Instead of resetting the card and checking like it should, it tries to detect the OPL chip on card, and that is notoriously hit-or-miss when I/O delay isn't emulated.

Posted: 10/21/2011 6:31 PM

Quote

Ilari

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1142)

Joined: 5/1/2010
Posts: 1217

sikomatik wrote:

Ok Im finished the vid but it doesn't look so ingenious like the 1080p HD TAS´es on youtube...?!?!?! I don´t know what Im doing wrong...

Very difficult to say without even seeing the video.

Posted: 10/21/2011 5:28 PM

Quote

Ilari

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1142)

Joined: 5/1/2010
Posts: 1217

sikomatik wrote:

@Ilari set rate contol to qp 0 or crf 0 where can i do this ? Is this to control the Bitrate or...? :)

Those are rate rate control options (and indeed control the bitrate used), so I presume those are in 'rate control' part. Don't know, because I have never seen what that tab actually contains.

Posted: 10/21/2011 4:28 PM

Post subject: Re: ffdshow HD encoding ?

Quote

Ilari

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1142)

Joined: 5/1/2010
Posts: 1217

sikomatik wrote:

Hello, can somebody tell me please : what are the best settings in ffdshow to encode the best possible HD quality ?

To get best possible quality, both dumping and encoding must be done right. For dumping, you need to use codec that is: * Lossless * Has RGB or 4:4:4 ITU Rec.709 TV-range colorspace. The usual ones are (in RGB mode): * FFV1 * Camstudio codec (this is always RGB). * Lagarith * HuffYUV Avoid h.264 / x264 for dumping because the colorspace that would have to be set (4:4:4 ITU.709 TV/non-full range) is pretty exotic and it might not be possible to set it to use that. Then on encoding, set rate contol to qp 0 or crf 0, colorspace to ITU.709 TV range (4:2:0 because Youtube does not support 4:4:4). The rest of the settings don't matter for quality (only resulting file size and encoding time). Sorry, I don't know to set this in ffdshow, as usually the encoding for HD is done using x264 command-line tool with avisynth. Also, for best possible sound quality, use FLAC for encoding the sound.

Posted: 10/21/2011 9:49 AM
(Edited: 10/21/2011 10:11 AM)

Quote

Ilari

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1142)

Joined: 5/1/2010
Posts: 1217

Warp wrote:

Btw, can CD loading times be ever perfectly emulated?

I would say no, already because emulating that would lead to "multiple oscillators problem", which already renders perfectly accurate emulation impossible. Worse yet, the second "oscillator" in this case is a motor, which are not exactly accurate with rotation speed. Sure you could probably get it near correct (and some games may even rely on loading times being there). The "multiple oscillators problem" is as follows: If there is only single oscillator in synchronous digital system. Then it is possible to compute future states of the system from the current state and logic-level description of the system. The oscillator may jitter, but speed of everything else will jitter with it, canceling out the effects of jitter to system state. If there are OTOH multiple oscillators, those oscillators can jitter with respect to one another, and these may have effects that don't cancel out. You can't simulate the jitter because jitter depends on all sorts of factors that aren't known (like noise from the power supply).

Posted: 10/15/2011 9:00 PM

Quote

Ilari

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1142)

Joined: 5/1/2010
Posts: 1217

(Soig asking where to get the hack) The IPS patch is here: http://acmlm.rustedlogic.net/ips/SMB1fast.ips Seems like the submission notes were missing that piece of info. Added.

Posted: 10/12/2011 9:57 AM
(Edited: 6/4/2022 4:57 PM)

Post subject: Re: Help with JPC-rr dumpconvert!!

Quote

Ilari

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1142)

Joined: 5/1/2010
Posts: 1217

c-square wrote:

Hi, I'm working on a PC speedrun using JPC-rr 11.2. I've created a dump file of my WIP which I can watch using playdump. However, when I try to use dumpconvert, to encode it, it fails. <snip> After it crashes, it creates an avi file that is 4 gb in size! That happens even if my dump is only a few seconds in length.

After back and forth by PM, it looks like that crash is caused by command line syntax change in x264 / direct264. Now, unfortunately r11.2 is too old to use the newer syntax. Now that I have proper cross-compiler available, I built new version of streamtools for Win32: Streamtools r11.6 (rev A). --output-x264 now assumes new syntax (use --output-x264o if you have very old x264 that uses the old one). But, this version adds --output-cscd=<filename> . This is output to .avi using Camstudio Codec for video and PCM for audio. The files should be directly usable for: * Youtube uploading * Processing using AVISynth (you also need to install Camstudio codec for this).

Posted: 10/11/2011 6:46 AM
(Edited: 6/4/2022 4:55 PM)

Quote

Ilari

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1142)

Joined: 5/1/2010
Posts: 1217

franpa wrote:

From the sounds of it it's just simple DOS commands needed to get it working.

Yup. It is DOS command prompt (and other DOS) stuff. But not everyone has used computers long enough to have used that stuff (or just has used it so long ago they don't remember it anymore).

franpa wrote:

Is Hourglass based on DOSBox?

Hourglass? What that has to do with this? And the answer is no. And if you are asking what emulator JPC-RR is based on, that's JPC.

Posted: 10/10/2011 4:30 PM
(Edited: 6/4/2022 4:55 PM)

Quote

Ilari

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1142)

Joined: 5/1/2010
Posts: 1217

Tailz wrote:

I'd recommend updating the guide and adding what you told me so others aren't confused like I was.

I added that stuff to the guide.

Posted: 10/10/2011 10:59 AM
(Edited: 6/4/2022 4:55 PM)

Quote

Ilari

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1142)

Joined: 5/1/2010
Posts: 1217

Tailz wrote:

Another weird issue is the keys stick, like it'll keep moving to the right as if the button was being held and then it just locks up.

Yeah, another known emulator quirk (I would need to do proper keyboard reading to fix that). Hitting the key second time releases it.

Posted: 10/10/2011 10:41 AM
(Edited: 6/4/2022 4:55 PM)

Quote

Ilari

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1142)

Joined: 5/1/2010
Posts: 1217

Tailz wrote:

Now it says I don't have enough memory.

You seem to skip config.sys (F5). Use F8 (confirm each command) and you can run config.sys but skip autoexec.bat. This configuration has much more memory.

Tailz wrote:

What should I try to set the tracks to?

Image track count? Should be left at default of 16 unless that is too small (and it obviously isn't given you managed to successfully import the image).

Tailz wrote:

I'm trying to run Wolfenstein 3D.

That game has rather nasty tendency of not detecting the sound card (if it shows it found soundblaster in the first screen, then it should work). I/O delay might help (probably just preturbs the timings). Oh, the hardware FPU has problems with that game (causes graphical glitches). Disabling the FPU (JPC-RR versions earlier than 11.5 also need NO_FPU hack to avoid Wolf3D from crashing on startup) fixes the graphics.

Posted: 10/10/2011 10:10 AM
(Edited: 6/4/2022 4:55 PM)

Quote

Ilari

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1142)

Joined: 5/1/2010
Posts: 1217

Tailz wrote:

I can change to 'c' but how do I run the game? Typing the image name doesn't do anything, just gives a 'bad command or filename' error

The startup command is game-specific (look for files with extension .com, .exe or .bat, it is one of those without the extension). Without knowing what game it is, impossible to say.

Tailz wrote:

Also, how do you get it to recognize the actual keyboard so I can stop using the virtual one? Or is that not possible?

Well, the idea is to do the command prompt using the virtual one and then have accelerators for often-used keys (see the 'extra' menu, datafiles/Extramenu and Wiki: EmulatorResources/JPC/KeyNumbers)

Posted: 10/10/2011 9:45 AM
(Edited: 6/4/2022 4:55 PM)

Post subject: Re: JPC-RR won't start?

Quote

Ilari

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1142)

Joined: 5/1/2010
Posts: 1217

Tailz wrote:

I skipped autoexec.bat like the guide says, and it takes me to an A:\ prompt. Am I doing something wrong?

Nope. Since the system boots from the first FDD, the default drive is A:, so the first command prompt will be 'A:\>' (at root directory of drive A:). Typical next step (keyboard is buffered, so the input has already been entered when the prompt appears) is to switch to first hard drive (command is 'c:') and then start the game (command varies). Steps some games additionally require: * Running setup program (usually 'setup') * Setting BLASTER variable (SET BLASTER=A220 I5 D1 H5 T6). * Loading DPMI extender (since HXDPMI is the only known compatible extender). Here's a screenshot from my Alien Carnage run (the A:\> prompt can be seen):

Posts for Ilari