Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
LOL, well, but your little experiment didn't prove anything (except the obvious notion that nobody looks at the author field), because it is common technique in the traditional TASing method to start improving old movies by replaying the existing file and switching to Read+Write near the frame where a potential timesaver is noticed. Naturally, the previous author name is often left in the new run (until you deliberately change it later), as well as some initial Input (e.g. the titlescreen and everything until the Level 2), which is not important, because you still have to put a lot of effort into making your new improvement and then rerecording the remaining parts of the movie (since the old movie does not sync after you've made the improvement, and there's no easy way to resync the old Input using traditional TASing method, in fact it was often easier to just reproduce the old strategy by recording totally new Input). So, it does not matter if some parts were copied literally (using copypaste) or indirectly (using human memory and a reference movie), the main question is: was the new contribution significant enough. That's what influences judging decision the most. And analysing the author field doesn't give any useful information about the "authority" of the submission (I think you meant "authencity").
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
Too bad there's no detailed description of route and items planning. Also I wonder if the number of random encounters could be reduced further (by using the "Call" for other team), because near the end there was a bit too much of those repetitive battles, but I assume it's necessary for some levelling.
Anyway, I was pretty entertained (because the game itself is incredible), so I vote Yes.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
Input resyncing is not TASing. Ideally it should be done automatically, with minimum human involvement. In fact, in TAS Editor 1.0 you can already do it semi-automatically, so once it's ported to Bizhawk (TAStudio) you can expect an avalanche of dummy submissions, which take only a couple of hours to produce.
This submission definitely can not be "accepted as an improvement", because it fails to beat the old record. It only makes the old record sync with another emulator, similar to how the author of NESBot had to pad FM2 movies with blank frames in order to sync with the real NES.
However, such kind of submissions can be accepted as "movie conversions" (so that old authors remain, and the new author is only mentioned in the description).
Well, seeing as here the new author didn't simply copy the old Input but recreated the Input while trying to improve it (thus wasting more than ~2 hours) I wouldn't object against adding him to the end of the actual authors list as a consolation.
Just, when writing the judge decision, make it clear that you are not encouraging submissions that fail to improve.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
Hah, I think, feos was trying to say that the "Auto-adjust Input according to Lag" feature has evolved dramatically since the time you saw it in 2.1.6! Although maybe it won't be as obvious when using traditional way of TASing...
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
Pasky13 wrote:
There appears to be a bug in svn 2837. If you record a movie using the new ppu, save the movie and play it back, the movie file will claim the old PPU was used when this is not the case.
So, as we figured out in IRC, this was not a bug, but the case when changing the PPU type mid-recording caused the confusion. I guess the best decision is to forbid modification of the setting while a movie is being played/recorded. Now, as of r2843, this is done by graying respective menu items, so in future there shouldn't be confusions anymore. PAL/PPU/Input type settings must be set up before starting a movie recording.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
Warp wrote:
If there was even the slightest mentality of deceiving the viewer by concealing the methodology, even if for just innocent fun, it can still be accurately called "fake".
You forget that SMB3 wasn't his first movie, it's only the most famous one. Do you honestly think that he kept making different movies hoping that people will continue to perceive every one of them as a realtime playthrough? I doubt he was that stupid. It's more like he didn't know/care about the western concept of legality in speedrunning, he considered his methodology to be obvious and exoteric.
Anyway, this second-guessing leads you nowhere. The animator guy just casually called SMB3 video fake because he felt like it, and you're trying to rationalize emotions.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
The tunneling is possible for any balcony with the height of 1 block (16px).
Language: lua
function draw()
CamXPos = memory.readbyteunsigned(0x072A) * 256 + memory.readbyteunsigned(0x072C);
XPos = memory.readbyteunsigned(0x003B) * 256 + memory.readbyteunsigned(0x004D);
YPos = memory.readbyteunsigned(0x0029);
x = XPos - CamXPos;
y = YPos;
CamXShift = CamXPos % 16 + 1;
-- draw grid of level blocks
for i = 0, 16 do
for j = 0, 16 do
gui.box(i * 16 - CamXShift, j * 16, i * 16 + 16 - CamXShift, j * 16 + 16, "#00000040", "#00000090");
end
end
-- draw Link collision points
-- vertical
gui.line(x + 12, y, x + 12, y + 32, "cyan");
gui.line(x + 20, y, x + 20, y + 32, "cyan");
-- horizontal
gui.line(x + 9, y + 6, x + 23, y + 6, "red");
gui.line(x + 9, y + 26, x + 23, y + 26, "red");
-- draw wall signs depending on current result of collision detection
wallFlags = memory.readbyte(0x00A7);
if (AND(wallFlags, 1) > 0) then
gui.box(245, 0, 255, 240, "gray");
end
if (AND(wallFlags, 2) > 0) then
gui.box(0, 0, 10, 240, "gray");
end
if (AND(wallFlags, 4) > 0) then
gui.box(0, 220, 255, 240, "gray");
end
if (AND(wallFlags, 8) > 0) then
gui.box(0, 0, 255, 20, "gray");
end
end
emu.registerbefore(draw);
Hey, that's rather awesome demonstration of the nonlinear TASing method! Feos' videos mostly showcase the semiautomatic method, which I consider to be more limited, but more fast-paced (result-oriented, so to say), but you seem to handle nonlinear as quickly, so I'm glad to see that nonlinear method can be fast too.
On topic of rerecords, yes, here you're editing frames after they were emulated, so you're essentially rerecording (in the traditional TASing you would need to load a savestate in order to edit previous frame, so rerecord counter would increment).
Even in cases when there was no previous buttonpresses (and by holding FrameAdvance you emulated blank frames), this is still considered an Input (all buttons released), so when you begin filling the blank space with new buttonpresses, the rerecords counter increments, because you've already seen what happens in the game when all buttons are released, and now you're changing this outcome (rerecording).
MESHUGGAH wrote:
I get a random bug regarding the follow cursor @ ~0:41.
That's not a bug, but a new behavior of the "Follow cursor" checkbox. Now the Piano Roll doesn't follow Playback while it is seeking. If you don't like this innovation in TASEditor 1.01, we should discuss it thoroughly (better in PM, not in this topic).
MESHUGGAH wrote:
If it wasn't clearly visible, I will make another version with microphone and maybe doing it a little bit slowly to understand better. edit: and better encode and find a better video hosting site that doesn't gives random ads and errors.
If you have time, please record such a video, not just for me, but for newbie TASers too. But better upload it to Youtube. Microphone comments would be great addition as well!
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
MESHUGGAH wrote:
I think I didn't explained it well. This time I TASed the game somewhat differently: I made the "basics" of a route and optimize it everytime I could, and when I had to make an improvement that will only "shows up" later (for example grappling at a frame and see it will catch the wall) I made simultaneous use of frame advancing and drawing the input in the same time.
I'm not sure I understand this method... Could you record a video capture with an example how you do it? You can record desktop using CamStudio. Maybe you've seen how feos recorded his TASing sessions.
MESHUGGAH wrote:
This means, that I get as many rerecords as I gave input to it. This basiaclly means that some rerecords were'nt actually rerecords but "records".
This is not possible. Let's see.
"Rerecording" is when you first watch a future event and then change the Input that leads to this event (this doesn't necessarily change the event itself, but still attempts to change the known future).
So, for example, if you frame advanced (emulated the game, greenzoned the Piano Roll) up to the frame 000200 and then change Input of the frame 000199, the rerecord counter will increase by 1, and the state of the frame 000200 may be different now. But if you advanced up to the frame 000200 and you change Input at the frame 000200 (or 000201-etc), then rerecord counter does not increase, because you haven't seen the state of the game after the frame 000200, so you've edited the Input blindly, and this is a "recording".
So, it does not matter if you're using Frame Advance simultaneously with drawing or you're using "Auto-restore last position" or any other way of advancing the game emulation. What matters is, are you drawing the Input inside the Greenzone or outside it. If you're frame advancing and drawing the Input above the Playback cursor then you're effectively rerecording (and in the traditional TASing you would need to load an old savestate in order to access the frame above the current frame). But if you're frame advancing and drawing the Input at the Playback cursor (or below it) then you're recording, and the rerecords counter will not increase - no wrong statistics!
MESHUGGAH wrote:
And the "consecutive rerecording" thing is checked.
You mean the "Combine consecutive Recordings/Draws" option? It doesn't affect rerecords counter, it only makes History log less bloated.
MESHUGGAH wrote:
I have to admit, that I'm still didn't check the branching thing, mostly because I'm not 100% sure that it won't get corrupted. I had 3 random bugs during this run, and didn't wanted to miss an improvement (every frame is important for me =) ).
You mean, in case of emulator crash? Then just configure the autosave feature in the Config menu! Being afraid to use advanced features you're losing more time than you would lose in case of a potential crash.
Built-in branching is more convenient than having dozens of project files. You switch between branches instantly, and you get nice graph of relations between all branches, etc.
MESHUGGAH wrote:
One of the random bug is actually because of this technique I used (holding the spacebar (bound to frame advance) while holding mouse1 to draw in TASEdtor) and for whatever reason (couldn't replicate it), FCEUX tried to frame advance while I was in "windows resize" mode on FCEUX. What I saw was intense blinking and couldn't do anything with it (force close).
If it's what I think it is, then this bug was fixed recently. Use the latest SVN build: http://fceux.com/zipMESHUGGAH wrote:
The second one is maybe has something to do with the ~300MB files, is sometimes corrupts at saving the FM3 (non-compact). When this happens, I just hex edit the part until the end of the input section.
Oh yes, the bug with project saving while unpaused... fixed 2 months ago, see 2.2.1-interim.
MESHUGGAH wrote:
The third one is maybe ROM dependent and maybe has something to do with greenzones. I first TASed the streemerz v01 and when I replaced the ROM header (dialog came up in TASEditor) and saved it (non-compact), the greenzones were not updated. For example, I watch the run for the first 500 frames, but if I just click on the first few frames, it will erronously loads up an invalid memory state (I think it just starts from the beginning, like I was inputted a reset which I didn't included or available in the input file).
This is not quite a bug. Since you've essentially changed the game (not just the name of the ROM), you should have created a new fm3 project (File->New, and check the "Copy current Input/Markers" checkbox) instead of just fixing the ROM name and trying to apply the old fm3 to the new ROM.
MESHUGGAH wrote:
So the reason of multiple files is 1. check the difference (advancing through a level faster doesn't means I get an improvement overally).
This is exactly what Branches are made for! You create a playthrough for a level, save it into Bookmark 1, then make another playthrough and save into Bookmark 2, and now you can switch between two movies instantly, instead of reloading two FM3s. To check the difference, sometimes it's not enough to just compare frame number (maybe in the first playthrough the frame number is less, but subpixels are worse), so you'll need to switch between the two playthroughs several times (back and forth) - this is when you understand the power of Branches.
And I'm not even speaking about more complex situations, where some branches may have sub-branches and stuff.
MESHUGGAH wrote:
holding the spacebar (bound to frame advance) while holding mouse1 to draw in TASEdtor
I see, you're using one hand for editing and another hand for replaying. This is so 2011-ish! :D Try to use the mouse wheel (while holding the right mouse button) to frame advance, so you'll be editing and replaying the movie with one hand.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
FractalFusion wrote:
An interesting homebrew, although I definitely didn't expect this TAS to take 32975 rerecords. Don't know about this game, but if I ever found myself spending 33K rerecords for a 54-second movie, I would consider such action far more obsessive than I could ever have imagined.
You didn't really check TAS Editor, did you?
33K rerecords sounds like a lot of work in traditional TASing, but in the nonlinear TASing it's not as painful, and in the semiautomatic TASing it's like a breeze. The whole pace of TASing is much faster here, so you can make more tests within any given minute, without noticing how you actually made hundreds of rerecords.
Also, TAS Editor only counts "real rerecords" (and doesn't increment the rerecord counter when e.g. you rewind or load a savestate containing the same movie data).
Old rerecording emulators usually count both "real" rerecords and "technical" loads of savestates (even if the movie data didn't change in the process of loading the savestate), so in the traditional TASing you always have a bit of fake rerecords added to the total number (e.g. if your finger slips and presses a single loadstate hotkey twice in a row, you'll get 2 rerecords in traditional TASing but 1 rerecord in TAS Editor).
MESHUGGAH wrote:
All in all, most of the rerecords comes from drawing by hand and finding improvements/routechecks so many times.
Drawing Input by hand actually decreases the expenditure of rerecords, i.e. to achieve the same result you would spend more rerecords (and much more work hours) in the traditional method.
So, all the rerecords in the movie come from finding improvements/routechecks so many times. You've really tested the hell out of this game, and the run shows. I voted Yes.
MESHUGGAH wrote:
I've made 76 fm3s and fm2s file through out making this TAS.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
dart193 wrote:
About guide: nice guide, not much useful info however as i think - mostly about how to make it interesting, not fastest.
"Interesting" is more important than "Fast". If you make fast but boring TAS, you'll end up in Vault, and if you make slow but interesting TAS you may get into Moons (although after that someone else may beat your TAS by improving time, so it's better to be both entertaining and fast).
So, that "TASArt" guide is (more or less) useful for improving entertainment.
As for speed, it's not just about learning game-specific tricks, it's more about squeezing everything from them, which means combining them optimally. This is the most time consuming part of TASing. The "best practices" of TASing workflow are described in another guide: http://tasvideos.org/forum/viewtopic.php?t=13521
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
MUGG wrote:
As a heads up, it seems the credit glitch in Kirby's Adventure is another one of those "unreliable glitches". That means, if you savestate in the middle of the glitch and load, the outcome will change. Or the outcome will change if you play the movie back from the beginning, for no apparent reason.
This sounds like a nondeterminism bug in the emulator. Can you link me to a movie with the glitch, so I could reproduce the behavior?
But first, check if the bug in there in this latest build:
http://fceux.com/zip
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
grassini wrote:
i'm doing a TAS for bomberman 3 but the boss fight is almost impossible to use both characters,do you guys have any tips?
I lose no time by not using my second character but it does look boring to have the 2p as a sitting duck while the other one destroys the boss
What do you mean "almost impossible"? Don't let laziness take over. 2P TASing is possible even without aforementioned additional tools.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
errror1 wrote:
I think having one person streaming the emulator, and the other person sending inputs frame by frame is all it would take. Wouldn't be quite tool assisted without savestates, but it would be interesting I think.
Or you could use remote desktop software like Team Viewer and TAS with TAS Editor, so both persons can draw/erase Input and rewind/advance by mouse. This is probably going to look hilarious.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
Yes, FM3 files are meant for TASer's own convenience, while the OP speaks about viewer's entertainment.
I guess feos only saw the 2nd post of this topic, about showing tricks and glitches by storing alternative branches of the movie inside the movie file.
On topic: IMO, for maximum entertainment it's better to just use normal video containers for this. As in, use non-linear video editing software to stitch outtakes, add audio commentary and some special effects like arrow pointing at important details or "picture-in-picture" (e.g. the big screen displays normal playthrough, while the small screen in the corner displays suboptimal playthrough).
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
Well, yes, mostly the above, but with two major differences.
1st. Each instance must record its own movie file (even though the Input log will be the same), in order to allow "seeking".
For example, when you need to rewind to the frame 300, but you only have a savestate at the frame 200 and you don't want to repeat typing the old Input, you just switch to Read-Only mode and replay the movie from frame 200 to frame 300. All instances should be able to replay the movie without context switching.
2nd. You should never unpause while in Read+Write mode, because instances are not synchronized with each other at all.
Slow and measured Frame Advance is the only way to ensure that, say, frame 1000 in the 1st instance is emulated at the very moment of time when the 2nd instance emulates the frame 1000. And if you unpause emulation or hold Frame Advance for too long, very soon one instance will outrun another, and will emulate frame 1003 while another emulates frame 1002, recieving the same Input.
Unpausing the emulation while watching the movie in Read-Only mode is safe, unless you try to make a savestate. Just don't create savestates when emulator is unpaused. Before savestating you must ensure that both instances are at the same frame of the movie, and oftentimes it's not so. You have to be careful and always look at the Frame Counter display.
These simple rules come naturally when you start actually making such kind of TAS. In 2006 I wanted to make one, but didn't receive any support, because I wanted to make Playaround (with the emphasis on sync instead of speed).
Link to video
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
WST wrote:
Why didn’t you use GTK to make TAS editor? Out of curiousity.
And why didn't you? You're programmer too! :D
So I've added the "custom speed for Frame Advance holding", because I see how it can be useful for TASing convenience. I even think this should be noted in the "Laws of TAS".
https://sourceforge.net/p/fceultra/bugs/556/
But, ikyokyo, you should have told about it earlier! Because now all these little improvements of the traditional TASing workflow look so insignificant compared to the sophisticated and polished environment of TAS Editor, it makes me sad to see how people still cling to old habits. It's like, there is the racing car at your disposal, but you still ask me to improve the pedals of your bike. OK, improved, see r2792.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
ikyokyo wrote:
Hello, everyone? I'm still new here...
Well, I came here because some of the TAS Speedrunners I knew can't get used to the FCEUX new style of Frame Advancing, such as HappyLee and so on. The behaviour of frame advancing in FCE Ultra is different from FCEUX.
Compare to the two ways in different emulator you can see it:
FCE Ultra:
1.Holds down the "Frame Advance" key
2.Release it.
FCEUX:
1.Press "Pause" key
2.Press "Speed -" button twice to slow down the speed to 50%
3.Holds "Frame Advance" key.
4.Release it.
5.Press "Normal Speed" key to return to the normal speed.
Think about the movie, you have to use the slow motion for many times, the operation steps in FCEUX is more complicated than FCE Ultra.
Though we can still use FCE Ultra for TAS Speedrunning, but that's not a recommended emulator for TAS any more. And what if a target game that FCE Ultra not supported. I think it should have a switch to let use choose the old style of frame advancing, just some suggestions.
So you want 50% speed when holding Frame Advance, but 100% speed when watching the unpaused emulation? Sounds reasonable, I'll see what can I do.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
WST wrote:
Я ещё заметил, что некоторые новички сразу начинают тасить весьма неплохо
Это они, наверное, целый год втихую сидят-тренируются перед заявлением о себе в сообществе. Я думаю, что сходу ни один человек не может начать качественно ТАСить, потому что эта сфера не похожа ни на одну другую, тут свои особенности и требования. Например, мои первые ТАСы сейчас выглядят довольно убого, при том что я до первого сабмишена где-то полгода луркал на форуме и не регистрировался.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
Catastrophe wrote:
NES and SNES games are fixable by pressing the reset button about 20 times in 30 seconds. (Not a scientific count.) This causes a power surge which will randomize the battery's contents.
And I'm not even speaking about more complex situations, where some branches may have sub-branches and stuff.