VBA can't emulate it, but there is link system support in an unofficial version of VBA that seems to work by letting an application start as the server, then multiple instances of VBA (possibly on different computers, I assume) can connect to that server and think they're linking with other GBA systems. But it would be difficult to record such a thing into a movie and allow it to play back - certainly possible, but the modifications required would be substantial. (How to represent playback, 4-way split-screen by emulating 4 GBA systems simultaneously? My computer can barely emulate 1 at a time.)
I've been thinking about this. I don't really like the way VBALink does multiplayer. You have to open separate windows, meaning that for recording you would have to worry about keeping them synched up so they all start at the same time, receiving the same inputs from the system; but I don't think you can even use savestates the way it is now. And that may be okay for just playing a game with friends online. But the multiplayer in NO$GBA seems much more stable, and I would advocate mimicking that emulator when designing link support.
I actually tried playing it (VBALink) online. It was a pain in the ass. The one time I actually got it to work, it started chewing up CPU time and slowed to a snail's pace.
Utilizing such a system to make a TAS with linked GBAs would require additional coding to deal with not only making a movie file that controls more than one GBA, but also (possibly) a "master" instance of VBA or some kind of server to facilitate synchronizing the other VBAs and recording/playing them.
I decided to do some tests. I tested CRF first. I set CRF to 40 (so I could get a good amount of artifacts for comparison), then ran ABR three-pass using the same average bitrate, which came out to be 334Kbps. The left frame is CRF, while the right is ABR three pass. All other settings are identical.
The quality difference speaks for itself. Note that CRF isn't like this the whole time. This happens after the background flashes white, and it tends to look like crap for the next 10-20 frames. It also doesn't get the benefit of analysis that multi-pass encoding does, so the encoder logo, for example, suffers visually. In fact, most of the video tends to suffer visually. The background also tends to "shimmer" in CRF, while the ABR encode manages to maintain background quality throughout the video.
I really can't recommend CRF after this.
EDIT: I re-ran the test using CRF 40 on the newest x264 binary, and the resulting bitrate was much lower (94.75Kbits). ABR three-pass with similar bitrate ended up with very similar if not identical quality.
I was bumping heads with someone in #x264 on our fair (not) freenode, and he made some points that I thought I'd mention:
* Three-pass is probably unnecessary, as the quality gain would be negligable. His actual words were "you only need to use pass=3 if you intend to use more passes after the second; if you intend to do that, you're probably confusing x264 with an MPEG-2 encoder" and "[three passes instead of two max] isn't a very good suggestion; the time is better spent doing something else".
* I use umh with range 64, whereas he suggests esa with range 16 "might be better", and would probably be faster, and "on your kind of footage esa might be particularly useful, dunno".
* qpel is useless (but is forced on in x264 anyway).
* qp_step (which I set to 50) is only used in VBV mode (while I use average bitrate).
Then I was told to RTFM. The mencoder manual didn't count, and the x264 manual (which he linked to) was similarly useless.
NOTE: The ROM is recognized by GoodGBA as "WarioWare - Twisted! (U) [f1].gba".
I voted yes because I learned that it is easier to take down a troll than angry bees!
Also how to punch drops of water.
The problem with trading from another game is that you would either need a predefined save (which would put a run doing so into the same category as the New Game+ run for Chrono Trigger) or you'd need to play the second game from the beginning too, which (from what I can work out) would defeat the point.
Or maybe run both at the same time a la the Megaman runs.
I have an idea, what if it's a close up of megaman, with his index finger pointing up and a ballon as if he was saying the message? It would emphasize better on the whole point of having megaman as the information boy.
Look what I did using this amazing fanart from this guy (I would notify/ask him for permission if using it officially)
There is quite some confusion here.
H.264 is not a codec, it's a video format standard. x264 is a codec which can encode and decode the H.264 format. (It's one of many codecs which support the format in question.)
We don't "use the H264 codec", we "use the H264 format". Also, effectively saying "I use x264, not H264" is wrong. You are creating H.264 videos when you use x264.
I never said "I don't use H264". I said "I use x264".
In any case, I'll remove the stars temporarily (as in, indefinitely until something different comes up), as they have not been verified for some time and there may be discrepancies in them that I am not able to off-hand justify.
SELECT * FROM movies WHERE numberofyesvotes > 0 SORT BY numberofyesvotes LIMIT 10; and then sort alphabetically or something.
Oh god I hate SQL.
I had a screenshot picked out, but it's 40KB. Unless Bisqwit makes an exception for it, I'm letting you, the viewers, pick the screenshot! :D Because I'm lazy.
Is there gonna be some documentation on the format for the video/audio streams when using -dumpstreams (and possibly a new MakingAVI guide in Linux on the wiki).
First off, to those using software firewalls...they suck. Get yourself a hardware one.
What good is a hardware firewall? They only stop inbound attacks, something a software firewall can do as well.
The largest problem are not inbound attacks. I don't have hard numbers, but I bet less than 0.1% of hacker problems is caused by hackers attacking from the outside and finding a security hole.
99.9% of hacking problems happen from the computer itself, in the form of spyware, trojans and backdoors. A hardware firewall is not going to stop those and, what is absolutely worse, they won't even inform you that something is connecting to the internet that shouldn't. A software firewall will. And that's the point: If it so happens that your system gets infected by a spyware you will *immediately* get notified of the fact when that spyware tries to contact the outside. You can stop it, and you can immediately run something to remove it. A hardware firewall is completely useless for this purpose.
Not having a software firewall in Windows is just madness. You are asking for trouble. Just running ad-aware or spybots S&D from time to time is not enough: By that time your computer may have already been compromised (and used eg. as a spam server).
Common sense wins over spyware detection software. Oh, I win a million dollars if I click this attachment? SCORE! ...wait, WHAT?!?!?!?! (I mean, honestly...how much spyware is caused by complete stupidity? Don't download unexpected attachments and get a fricken adblocker software for your firefox browser.)
It's also a case of computational complexity. The added quality-per-bit isn't 100% free; it costs more decode time. This can/usually is compensated by a faster CPU (or, even better, h.264 hardware decoding on the GPU.
There's also multipass encoding, which DeHackEd can explain better than I can.
The quality difference speaks for itself. Note that CRF isn't like this the whole time. This happens after the background flashes white, and it tends to look like crap for the next 10-20 frames. It also doesn't get the benefit of analysis that multi-pass encoding does, so the encoder logo, for example, suffers visually. In fact, most of the video tends to suffer visually. The background also tends to "shimmer" in CRF, while the ABR encode manages to maintain background quality throughout the video.
I really can't recommend CRF after this.
EDIT: I re-ran the test using CRF 40 on the newest x264 binary, and the resulting bitrate was much lower (94.75Kbits). ABR three-pass with similar bitrate ended up with very similar if not identical quality.
I haven't gotten any complaints yet.
EDIT:
