i wonder though, why you don't take 10 ring TVs. i know they aren't necessary, but they aren't harmful either, right? they would even be useful to take sometimes, to gain time which is lost by avoiding them.
Yes, some do save time, but others time-wasting. It has its advantages and disadvantages.
If your goal had been "Priority: Collect all the rings as fast as possible; don't collect ring monitors except when it's faster to do so" then it would've been a better run, is what people are saying.
Wouldn't it make more sense to treat different regions as different games? Their names may be the same, but the game code & data can be vastly different. It would be a lot of effort to prove for every changed byte that it does not affect the timing. Quite the contrary, as using the wrong ROM for a movie often causes a desync.
It's still possible to exchange tricks as with (E)<->(U) versions or TAS<->unassisted speedruns, but they have to be adapted into new runs.
Well, the network IS an input... but it's not one you normally have direct control over during play.
Exactly. Manipulating the packets directly would be something like savestate hacking. Players cannot do this in real life even if they had slowdown and rewinding.
But it's something completeley different (imo) if you emulate 2 or more connected virtual machines, and control their button input.
For some reason IE plays the video very poorly. Firefox and chrome are fine though.
Same here, and also works fine in Opera.
antd wrote:
x264 --preset veryslow --bitrate 1000
What audio codec (if at all)? You could also try a game with fast-changing graphics (Sonic, Sparkster, Biker Mice From Mars, DKC2, F-Zero or Super Turrican), a long TAS with occasional heavy movement (Seiken Densetsu 3) or a fast 3D game.
Yes, play at 1/4 speed.
Set "Video | Display Configuration | Automatic Frameskipping" (max=0), and see "Input | Customize Hotkeys" for the "Speed -" and "Speed +" keys.
Space wouldn't be an issue:
One video (30 minutes, video @ 1000 kbits/s, audio @ 192 kbits/s) would need ca. 255.78 MB, and 500 of them would need ca. 124.89 GB (plus file format overhead).
As for the bitrate, it depends on how much CPU time you have available. Slower presets allow for more quality (lower CRF) at the same size.
Sounds like the best solution is for bSNES to store, in a known location within the save state files, the offsets at which RAM, VRAM, etc are stored in the file. Then tools like vSNES or a dedicated sprite ripping program would be easily able to look up the graphic data in memory.
Yes, exactly. (SNES9x stores the most meta data than any other emulator, and it's still not for every single variable. Would be nice if one did...)
Rena wrote:
How about adding the canvas layer coloring option? It's the layer that's normally black and comes behind all other layers. Changing its color is necessary for ripping sprites and maps. For now communities are using hacked savestates of bsnes IIRC.
[...]
I think they just hack some palette color. Don't know if this can affect syncing (probably badly), but one doesn't need syncing non-hacked palette movies on hacked mode.
http://www.vgmaps.com/forums/index.php?topic=821.0
EDIT: Oh, vSNES it is called.
vSNES can't load bsnes savestates because they can change with every new emulator release and have no meta information themselves.
For the SNES the "canvas" is called backdrop and fills every pixel on MainScreen with palette color 0 where BGs & sprites are transparent or disabled for MainScreen. (MainScreen can have color math applied to it, using either the color constant or SubScreen pixels.) So it might be as simple as setting the first 2 bytes of CGRAM (and writing to register $2132 for the color constant if necessary).
I actually don't remember how I found the site, but it was early enough that when I registered the Super Metroid thread had only 17 pages.
Looking at the profiles it was 42 days after michael flatley registered and 76 days before his last post...
The best compressing+capable lossless codec is CamStudio. Second place if after Lagarith.
ThatGugaWhoPlay wrote:
Lagarith Lossless, no doubt about it!
You should also mention what your criterium is.
CamStudio is very fast and achieves a nice compression for the little time it spends on it.
Lagarith compresses more but when you're editing all that usually matters is speed, so I don't see it as that useful.
natt wrote:
At the moment, x264 RGB lossless is not recommended.
Did you mean h.264?
natt wrote:
Camstudio - kind of slow, VFW codec is 32 bit only.
There's a faster one (that involves compression and a harddisk)?
natt wrote:
Lagarith - much faster than Camstudio
Only if you have enough cores, afaik. On a single-core machine it'd probably be slow.
natt wrote:
ZMBV - no 24 bit input option, only 32 or 16, so mostly only for psxjin.
What would be interesting is a "fake" codec that converts everything to 32-bit (or 16-bit, if the end result is the same) and passes it over to ZMBV.
