Finally I was able to watch the video, phew. (My parents got themselves AOL for their ISDN line. Thanks mom. -_- This means that I can't download the video from rapidshare. Oh well...)
And it was worth the wait. =^_^=
Btw. why did Samus have to fall into the lava at ca. 3:31?
I still dont understand how you would go about making a TAS on a console. I think it's kind of a weird thing to be doing, since you cna already make one easily.
As for not resetting memory when doing a reset, yes, that is a problem, but it's not so bad if you understand it more. On a cold boot in which the system has been off for a short time or more, RAM will effectively consist of entirely FF bytes due to how RAM chips work (at least the ordinary kinds).
Recently byuu (the author of bsnes) has changed the initial value to 55h, to "fix" a game that relies on this value. There's some posts about it in the last few pages of his thread on the ZSNES board (see the "Emulation" subforum).
One of the suggested solutions was to include the startup value into the movie file.
Reproducing speedruns on the hardware would be silly, ie. fun. :) Probably not possible though.
Regarding the emulator stuff:
An SNES emulator would just have to provide the controller data when registers $4016 or $4017 are read, not every frame.
This would of course make creating TASes a bit more complicated - you could record frame-by-frame and wouldn't be able to get the results of real-time recording. The emulator would have to pause at each register read, not each frame.
On most old consoles, the controller knows when it is being queried. The NES and SNES, for example, have a pulse you send to the controllers over a particular hardware port. The next several reads will get that data. The controller is doing a 16-bit hardware transfer to the host when those pulses come.
Emulators' movie formats should be modified. Rather than store the input state at each frame, they should be storing the input state at each controller read. Whenever it reads from the controller port, record the button state.
That sounds like good idea, if that pulse or strobe is indeed always required to get the button status. (I should read up on that...)
I don't remember the exact wording, and it was translated anyway. The meaning was "they will be bad".
In TAS terms: Not usable since everybody who knows the game sees where and how it could be improved.
Reminds me of something I read in the book "Game Design" (afaik); one of the game developers said "Your first ten games will be garbage."
So no matter what you do, only time and experience will get you good results.
Better quality of gameplay doesn't have to result in more goals. If both teams have very good defenses then 90+ min. might be not enough to show the difference.
EDIT: I'm not saying Germany was the best though - don't follow the game close enough to judge.
As far as the metroid hacks are concerned, I think there should only be 1 allowed.
Why only one? And why only one "as far as the metroid hacks are concerned" - maybe two for Zelda and three for SMW?
I'd treat each hack as its own game, as long as the gameplay is changed, ie. new physics or new levels etc.
Unpopular (ie. unknown) hacks are not different than unpopular games. The levels of interest are comparable.
EDIT: See romhacking.net for an extreme example: Dragoon X Omega II is a hack of Final Fantasy AND a completely new game.
</$0.02>
>You don't have cameras either when you play with some friends.
That's true. But how is that relevant?
Informal ice hockey games don't have cameras either. But professional games do.
It keeps the professional level closer to the amateur (w?) level, hence the audience can better identify with the players. IMO that's a good thing. If it introduces more errors to the results then so be it... At least you can say that it keeps things more interesting. ;)
http://vsnes.aep-emu.de/vSNES/vSNES292_beta1.rar
This is a Beta of the next version... you need the files of v2.91 for it.
I'm currently working on ZMV stuff, but the SMV section also got some bugfixes.
It's the price to pay for simple GUI development...
It is perfectly possible to make a windows binary which performs that operation, full GUI and all, in less than 10 kilobytes.
Yes, but then you'll have to deal with the raw WinAPI stuff. Which can be done in Delphi too (and you get an 16 KB EXE, which is the smallest the compiler bothers with). ASM programmers on the other hand will be horrified by the amounts of space you're wasting, and so on etc. ...
Warp wrote:
However, using a separate binary for a division is still an overkill IMO.
Yup. But there's an audience for everything. :)
EDIT: I'm sure it's possible to implement such a display into SNES9x in ten minutes, if you know the source.
I just noticed that newer videos (eg. the newest Contra 2 video) don't seem to follow this format description - at offset $16 there should be the Sync Options, but they don't seem to be stored there. Does SNES9x load the info from somewhere else?
(Btw. I'll read the entire thread later - don't have time right now...)
EDIT1: Is it at offset $17 ???
EDIT2: OK, off to read the source... :|
EDIT3: Fixed, was at offset $15... :/
