I'm currently working on Duke Nukem 3D, and I am astonished by your capture quality. You have a very impressive frame rate, resolution, and quality. I have been using TV out to my mpeg2 encoder so that I would net get lag from, for example, Camtasia, but you seem to not have the DAC->ADC loss nor the frame loss of a software solution.
How'd you do it? :)
Half Life demos can be dumped directly to lossless frames directly. They didn't record it off the TV or anything.
So basically, if you happen to fight a Starman Super, try to get the sword, to add a "holy shit" effect. Plus, it'll be some extra damage for Poo, and might help for the next bosses. (Unless Flash Omega kills everything)
If you don't fight a Starman Super, don't get it.
In TAS manipulating luck is a given, so getting the Swords of Kings isn't much of a "holy shit" effect.
You'll have to try a lot harder in TAS to get such an effect.
I suppose that if it was all about speed and nothing about entertainment and looks, kill Jeff.
But since it's all about the art, keeping Jeff alive would paint a much cleaner, better picture.
My $0.02 from the ATM anyway.
I don't understand how speed isn't entertainment. I've seen so many comments on how you should "sacrifice some speed for entertainment". I think anything that sacrifices speed becomes less entertaining.
Well, you wouldn't have to decode all of it.
Besides, I was thinking more in lines of modifying the enumulator to have a debugging feature where you can halt the game at any point and have the enumulator display the assembly at that point.
Actually, is there any enumulators that can already do this? It sounds like an obvious feature to have...
I just realized something. Wouldn't it be easier to figure out what the game is doing exactly by looking at the rom?
We have the rom, we have an enumulator (with source code), so shouldn't it be easier to find the memory addresses used in the algorithm there instead of looking at what changes in memory?
thanks for comments, it will help the next version, although i don't know if anyone would have the patience to redo this.
If you have the patience to do it, you have the patience to redo it!
I don't know is that evil or good encouragement ;)
Anyways, keep it up FODA. I havn't watched any of your wips, but I know it'll be awsome. I am ready to be in total shock once your done :)
JXQ does it again!
Its cool to look back at how many times this movie has been obsoleted
SNES Super Mario World (USA) in 11:06 by Julius Grinto (aka. Bladegash).
SNES Super Mario World (USA) in 10:52 by Josh Brooks (aka. Volkov).
SNES Super Mario World (USA) in 10:51 by Alexis Neuhaus.
SNES Super Mario World (USA) in 10:36 by Darren Smith (aka. flagitious) and Tim Offermann (aka. VIPer7).
SNES Super Mario World (USA) in 10:32 by JXQ (?).
If you are not going for the fastest time possible, then I would doubt your run will be accepted at all.
Remeber, TAS means Tool-Assisted Speedrun
Otherwise you are just playing the game with tools...
Well, I am not saying Google video would replace the AVI, but rather it would just be another means to get the content.
The beauty of it is, the bandwidth is free!
Ah yes, it would be harder for somebody to manually hex edit if he had to worry about a frame field...
Thus, dummy records would be best solution for all (expect it takes the most space, but as I said before, space is a non-issue at the moment.)
You might be able to deduce when what input is happending, but that requires intimate knowledge of what the movie/player is done at what point.
I am not saying that you don't need knowledge of what the player is doing if you knew the frame number, but I am just saying it would make things a lot easier for somebody trying to edit a movie to know, "Oh, so then I didn't input anything for this long"
Unless I am mis-understanding something, you can't figure out how many frames has passed between inputs unless you emulate the rom, or had the frame number.
Not from what I understand.
N64 doesn't read input for every frame, therefore input isn't recorded in the movie for every frame.
Input is recorded in a movie only when N64 reads input.
Therefore there may be frame in between input where N64 doesn't read input.
Well, right now it uses 4 bytes per input.
We just need about 2 bytes to record the frame number. 2 bytes can represent a frame for a movie 18 hours long at 60 frames/second.
So we would increase the movie size by about 150%
Considering that movies are highly compressable and are not that long right now (in the magitudes of kilobytes right now), it wouldn't be bad to increase movie sizes by 150%
Since you only record input when N64 reads the controller, why can't you output the frame number as well?
For frames that don't use input, just don't record them at all...
Would this solve the problem of not being able to calculate the movie length using the input, and wouldn't it also make an external hex editor more useful?
If the order the stars within a level are gotten is still up in the air, I'd recommend getting the 100-coin stars first, so you'd only get the 'A new record' message for coins once per level. Just another thing to think about when planning it.
I think its been pointed out by spezzafer, that that message doesn't take any more time than usual.
If you look at the 16-star run, it does seem true. But I think that's something we need to test. Even if its 1 frame, its worth it.
His samus, MM, and hand were all pretty good.
Everything else sucked. But he obivously didn't have solid goals, so that is why.
I am not convinced that Fox is the fastest after seeing Kirby. That suck, hold, split strat is not too slow.
I think this should get a star if you didn't get hit by that ball in Scape Brain 2. I know what did was the fastest, but new viewers might be turned off by it. (Since star'd runs are intended to get new viewers started)
And...
Next: Super Mario Bros. 3 (no warps)
Can't wait =)
