All programs can have bugs, or could be more optimized (though that user GuidMorrow saw could have been downloading something else).
µTorrent wrote:
-- 2010-03-05: Version 2.0 (build 18488)
- Fix: Fixed half-open limit on Windows 7
-- 2010-02-22: Version 2.0 (build 18296)
- Fix: uTP sampling error (caused speed drops every 60 seconds)
-- 2010-01-12: Version 2.0 RC3 (build 17774)
- Change: Improve downloading/uploading performance with mixed-mode TCP and uTP
-- 2009-12-21: Version 2.0 RC2 (build 17668)
- Fix: disconnect issue with seeds
- Fix: uTP over Teredo at high speeds, and MTU problems on some kinds of networks
-- 2009-11-03: Version 2.0 Beta (build 17127)
- Fix: Accounting of halfopen https connections would cause uT to stop making new connections
- Fix: sometimes the &ip= parameter sent to trackers would be incorrect
-- 2009-09-04: Version 2.0 Beta (build 16394)
- Fix: Fix startup race condition between network and disk I/O thread
-- 2009-08-10: Version 2.0 Beta (build 16126)
- Fix: tracker requests are not invalid anymore
-- 2009-08-04: Version 2.0 Beta (build 16081)
- Fix: fixed uTP selective ack bug (would cause connections to stall and time out)
- Fix: fixed uTP fast re-send bug (would sometimes re-send packets that shouldn't be re-sent)
- Fix: uTP recovers faster after timeout
- Change: reduced uTP overhead slightly by ramping up packet sizes at lower rates
- Fix: http seeds would not reconnect after stopping and starting torrent
- Fix: http seed for multifile torrents
- Fix: uTP issue on low-latency high-throughput networks
...
Btw. NTSC is 60/1.001 fields per second, which becomes frames per second due to the console's video signal. I'd think the emulator would match that framerate?
I'm disappointed in Youtube regarding the scanlines. The encoded files show them as intended, but YT's encoder smeared them together - maybe it uses a smaller internal resolution.
I'll update the description with a disclaimer. (EDIT: Done. Sorry about the delay :/)
Simulators generate their output without doing the same steps as the original system. Emulators re-create the system's components, the input is forwarded to them, their operation is simulated, and their output becomes the output of the system.
For example the Asteroids arcade game had analog circuits and a vector display. It can be simulated with sprites, recorded sound samples and modern game code, but emulation requires a virtual vector display and virtual circuits, and the interaction of those re-creates the game.
There can be chips on the cartridge that intercept read/write requests (much like the Game Genie); they can be programmed to map a section of the entire ROM data into an "adress window" that is then directly accessible by the base system.
http://en.wikipedia.org/wiki/Bank_switching#Video_game_consoles
Sure, you could get rich, stop crimes and do the Y sign, but in the end those actions have more troublesome consequences. "With great power..." etc.
So I'd probably just use it to secretly prevent accidents happening to the people I know - much less of a headache.
MUGG wrote:
Then that would put single-star improvements and complete runs into two different categories. The former shouldn't be used as a reason to reject a complete run submission.
convert_VGA.avsiinfo.txt
AviSynth script to convert video clips to a common resolution. Optionally it can add scanlines and/or remove the 9th column of text characters (disabled, enabled).
version v0.2: download link
changelog:
- fixed: more than one compression selection dialog
- fixed: compression selection dialog being behind the console window (increases system requirements to Windows XP)
- added: help/info text
- added: second parameter can be "onlyindex" to simplify the output filenames
- added: TimeSeq info for each frame
- added: AviSynth script "convert_VGA.avsi" to convert AVI files to a common resolution, either 640x480 or 960x720
As with the previous version the standard interaction methods are available: redirect text output with > or |, pause with the Pause key, halt with Ctrl+C or Ctrl+Pause. (Halting the program will most likely corrupt the current AVI file.) Processor priority can be set by starting with the standard "start" program.
This should be the final version unless there's a bug or missing feature.
- framerate is currently fixed at 60 fps (which is just a dummy value)
- the timestamps are not used in this version, so the frames will have the wrong timing; this needs more code or a container format like MKV
For R10 dumps, this is mostly OK, as r10.x versions have framerate fixed to 60fps (assuming single-segment source).
Here's a tool that converts video dump files to AVI files:
http://www.mediafire.com/file/0fubwmb38j365lx/
- needs one parameter which has to be the video dump file name
- video files will be created in the current working directory, one AVI file per resolution
- at the moment, each AVI file pops up its own compression selection dialog; will be fixed later
- all frames are dumped, regardless of their timestamp
- framerate is currently fixed at 60 fps (which is just a dummy value)
- the timestamps are not used in this version, so the frames will have the wrong timing; this needs more code or a container format like MKV
- my own code (for Delphi 2009) is public domain as far as I care; for the other files see their content
Afaik JPC-RR r11 will have a different dump file format and different tools, so this one won't work with it then.
If you scale eg. a 320x200 original video material (which is supposed to have an aspect ratio of 4:3) into, let's say 1024x768 (using stretching), then you will be basically emulating what a CRT supporting the latter resolution is doing when the graphics card is sending it a 320x200 pixels image. The blurriness/pixel doubling caused by the uneven stretching is minimized when the final image has a much higher resolution than the original.
Of course it also means that the video would then have to be distributed in that 1024x768 resolution (scaling it down to eg. 320x240 would "antialias" the image, probably in an undesirable way).
Naturally, though 960x720 (720=3*240) is a bit better for HD.
As much as I may agree with you on the fact that adding black bars is a bad option (it looks hella ugly), I don't feel that adding scan lines is a good option as well. Mostly due to the fact that it makes the encode look inconsistent, as it will have parts with, and parts without scan lines. I therefor feel that stretching is the best option, using whatever algorithm most resembles the actual result on a computer. It may not look as pretty, but it will look a lot more consistent.
On a real CRT there is a transition period: when the monitor goes blank for a second.
I'm sure we can simulate that too quite easily. :)
But joking aside... different modes will always look slightly different from each other, no matter what solution is chosen. In the end the decision over "which poison" would then lie with the encoder.
How do you play the TAS in the emulator, by the way? When I click "Snapshot"->"Load"->"Movie" and select it, this message appears:
http://img840.imageshack.us/img840/6500/loadsavestatefailed.png
The files "BIOS", "VGABIOS", "floppy.img" and "EpicPinball" are in the "disklibrary" directory.
