Posts for AnS


1 2
14 15 16
27 28
AnS
Emulator Coder, Experienced Forum User, Published Author, Experienced player (724)
Joined: 2/23/2006
Posts: 682
Baxter wrote:
The general rule is that when a 2-player run is slower, there are often two versions, as the 1-player version is the fastest game completion, and the 2-player version adds interesting 2-player gameplay. In this case, the 2-player TAS is faster though...
Well, with Chip and Dale 1 it's even worse: 1p run is slower than 2p (especially since 2p run isn't improved yet) and both runs use same sequence of levels, even though in CDRR1 player could choose levels (so since 1p is inevitably slower, I'd personally prefer it to be a "100%" run). Also, unlike CDRR2, in CDRR1 bosses tactics are absolutely the same in 1p and 2p runs. And yet both runs for CDRR1 were published and got high rates, probably because it's the game everyone played in childhood, while CDRR2 was released too late.
goofydylan8 wrote:
feos wrote:
Bosses shall be manipulated here. But I hate how the last one looks!
Believe me, I do too. Picking up the bombs is most definitely slower as it causes the boss' to act differently (I did it where I picked up every bomb, still hitting on the earliest frame and it ended up being 5 seconds slower than my current version). And that final boss is the only level in the game where lag became a problem. All other levels allowed for "dancing" without hurting the time but on that one moving around caused lag about every third frame.
But did you try to redo the run for Old PPU?
AnS
Emulator Coder, Experienced Forum User, Published Author, Experienced player (724)
Joined: 2/23/2006
Posts: 682
Nach wrote:
AnS wrote:
Also I don't want to port it (especially since it's different language and platform) until I'm sure a lot of people want to switch to new paradigm.
That might even be shrinking. With Microsoft's push for standard HTML and JS in Windows 8, and Microsoft's Going Native initiative and conferences, some wonder if .NET will even be around a decade from now.
Oh, I think I misspelled it. By new paradigm I've meant new TASing method (rapid input editing instead of consecutive input recording), not switching from native code to managed (dotnet)! :D But yeah, the platform that was chosen for Bizhawk is also rather arguable.
AnS
Emulator Coder, Experienced Forum User, Published Author, Experienced player (724)
Joined: 2/23/2006
Posts: 682
My old post was too long, and it contained two different points, so I've split it. There's no text duplication.
AnS
Emulator Coder, Experienced Forum User, Published Author, Experienced player (724)
Joined: 2/23/2006
Posts: 682
(moving my post on this new page) Here's my justification why FCEUX should be used for making TASes at least for a couple of years since now. 1. It's 7-10 times faster than Bizhawk. With Bizhawk you must have modern computer to simply play a NES game. Forget about Turbo. With FCEUX you can have fairly old computer and use fast-forwarding, which is important for TASing. 2. It has higher compatibility with NES romset. Bizhawk's NES support has yet long way to go to compete with FCEUX. Anyway, this will be obvious in a week from now. 3. FCEUX has romhacking tools (Debugger, Tracer, Code/Data logger). Bizhawk will probably implement Debugger later, but I don't think it'll ever surpass FCEUX set of romhacking rools. And debugging is an important part of TASing. Most of glitches I found were first discovered while playing with movie Recording on (so it's easy to reproduce). Then I'm opening Tracer and Debugger windows and looking at the glitch closely. Most of time it's possible to dissect any anomaly and put it to good use in a TAS. Even if a TASer not experienced in 6502 assembly, he can put his FM2 movie in a forum topic for someone to test it in FCEUX debugger. You can't do it if you're making movie in Bizhawk. So I think it's way too early to even consider switching from FCEUX to Bizhawk. SMS, GG, SG-1000, PCE-CD, SGX - sure. But not NES. Now about FCEUX 2.1.6 and TAS Editor. Old TASEdit was a prototype of this idea. http://tasvideos.org/forum/viewtopic.php?p=38496#38496 In FCEUX 2.1.5 it's only a basic Piano Roll interface without clear understanding of a final tool. And it crashes a lot, don't try using it, or you may get the wrong idea of the new TAS Editor. At first I wanted to just enhance old TASEdit with a couple of new features. But then I've suddenly envisioned the architecture of the new TASing concept. The one where TASer's mind always has the whole picture of the movie, where old "buttons Recording" method is only one of many ways to interact with the game. Where even Rockin' Kats is not tedious to TAS, because "repetition" aspect of current TASing is greatly soften by different arrangement of TASer actions. So I ended rewriting whole thing from scratch and then rewriting some parts again and again. The final architecture is pretty thought-out, both in terms of OOP classes and in terms of how to set up TASing process efficiently. Although now I see possible improvements, but hell, it's neverending cycle of perfection. So. FCEUX 2.1.6 (probably final FCEUX) will be released soon. Among usual improvements (bugfixes, new mappers, new Lua functions) it will have updated documentation and this new TAS Editor v1.0, plus its own documentation. The code was finished this January, but I had to slow down writing detailed docs, explaining all the quirks of the new TASing methodology. This is not a small deal, it's changing the whole approach to TASing, so I want to carry the message very clearly, can't hurry. Finally, about ".tas" extension. Actually, at first TAS Editor had this extension for its project files (as you can see in FCEUX 2.1.5), but a couple months ago adelikat asked me to change the extension to FM3, because he thought it's more suitable for Bizhawk's movie files. Well, FM3 is fine to me, so I changed. Because TAS Editor's file format is actually a superstructure for any other movie format, be it FM2 or GMV. But now that CoolKirby mentioned it, I also think .bkm extension is more suitable for Bizhawk, because Bizhawk's movie format is very similar to .fm2, it doesn't have anything in it that screams "TAS file".
goofydylan8 wrote:
I will probably stay using fceux at least until TAS Editor is ported over
Bizhawk is too slow for now. Maybe in a couple of years PCs will progress enough... But right now I'm not even sure that you'll get stable 60FPS using TAS Editor with Bizhawk (since TAS Editor imposes additional load on processor, plus it desperately needs Turbo emulation for a couple of cool features). Also I don't want to port it (especially since it's different language and platform) until I'm sure a lot of people want to switch to new paradigm. Not wanna risk anymore. I've spent too much time (half a year in non-stop development), now the only additional waste I can afford is writing docs and tutorials.
AnS
Emulator Coder, Experienced Forum User, Published Author, Experienced player (724)
Joined: 2/23/2006
Posts: 682
jlun2 wrote:
For the existing FCEUX runs, will the staff convert the .fm2 files into the BizHawk files?
No need for conversion. Bizhawk can play FCEUX movies (and many of them should sync). And FCEUX also could play Bizhawk movies, if that was necessary.
AnS
Emulator Coder, Experienced Forum User, Published Author, Experienced player (724)
Joined: 2/23/2006
Posts: 682
goofydylan8 wrote:
So I can't even check the numbers to see if they are the same.
You don't need FCEUX to calculate checksum of your ROM. Use any program from the list: http://en.wikipedia.org/wiki/Comparison_of_file_verification_software I use HashCalc.
Post subject: Re: Youkai Yashiki
AnS
Emulator Coder, Experienced Forum User, Published Author, Experienced player (724)
Joined: 2/23/2006
Posts: 682
Works for me. Youkai Yashiki (1987)(Irem Corp.).fds SHA-256: c06709b4 2a76c8e3 b9ec2edf 2d0e6130 416c9a22 317946f6 227d43e4 8d45c077 MD5: aa1f7c233aa9a13bba3752cfed9fcf95 CRC32: a888c6df
AnS
Emulator Coder, Experienced Forum User, Published Author, Experienced player (724)
Joined: 2/23/2006
Posts: 682
TAS Edit, который есть в FCEUX 2.1.5, очень сырой и глючный, он ненамного лучше обычного метода ТАСинга. В последние полгода я разрабатываю новую версию TAS Editor для FCEUX 2.1.6, и одновременно документирую новый подход к ТАСингу (использование TAS Editor по-умному). После того, как выложу FCEUX 2.1.6, посмотрю, насколько тепло будет принят новый метод ТАСинга. Если всё пойдёт хорошо, то через время буду думать насчёт портирования Тасэдитора на другие эмуляторы, возможно даже мультисистемные. А может быть, мне даже не придётся самому заниматься портированием - если концепция сильно заинтересует народ, то Тасэдитор автоматически станет обязательным пунктом любого уважающего себя ТАС-эмулятора (как сейчас, например, требуется наличие Lua), так что найдутся кодеры и помимо меня.
AnS
Emulator Coder, Experienced Forum User, Published Author, Experienced player (724)
Joined: 2/23/2006
Posts: 682
Ну вот, я же говорил, что ещё рано выкладывать этот пробег, когда невооружённым глазом видны улучшения. Теперь попытайся обогнать того человека, который обогнал тебя. ТАСинг - дело кропотливое, тут торопиться не надо.
AnS
Emulator Coder, Experienced Forum User, Published Author, Experienced player (724)
Joined: 2/23/2006
Posts: 682
AnS
Emulator Coder, Experienced Forum User, Published Author, Experienced player (724)
Joined: 2/23/2006
Posts: 682
WST wrote:
What is the purpose of the red dog? And why does it need waiting?
It's Rush, Megaman's sidekick, here he's digging for CDs hidden in some terrain. Since this run collects all CDs, player has to wait fixed amount of time before the CD appears.
AnS
Emulator Coder, Experienced Forum User, Published Author, Experienced player (724)
Joined: 2/23/2006
Posts: 682
I'm having deja vu... Warp, you're not learning. http://tasvideos.org/forum/viewtopic.php?p=262771#262771 A game on any console can detect whether saving process was finished or it was interrupted. It can be as simple as clearing a validation flag at the beginning of saving to Battery RAM and setting it only after the saving is completed. As for consoles where Reset doesn't clear RAM (like NES, Sega Megadrive and many other consoles without built-in BIOS), here it's even possible to retry saving after Reset. So yes, theoretically it's possible for a game to be reset-safe in terms of "bulletproof saving". For example, if you reset mid-save in Metroid Zero Mission, after the title screen the game will tell you "File A is corrupted. Erasing File A..." I guess Nintendo has really good QA for their in-house studios.
AnS
Emulator Coder, Experienced Forum User, Published Author, Experienced player (724)
Joined: 2/23/2006
Posts: 682
The run is improvable at in the fridge level, where player could use fans acceleration with better precision. Plus, some bosses luck manipulation is far from perfect (low rerecords counter speaks for itself). Since I like the game (and think it deserves 2 categories) I'm voting Meh instead of No. Fisker N, if you put more effort, you should be able to beat current time at least by several seconds.
AnS
Emulator Coder, Experienced Forum User, Published Author, Experienced player (724)
Joined: 2/23/2006
Posts: 682
I wouldn't call this "outsmarting". It's just the norm, hi-quality design (which sure becomes rare thing nowadays) - a design that doesn't require any explanations which would ruin the fun. By the way: Link to video There's a way to teach any non-obvious game mechanics. It's just that only a few game designers can do it without going down to awkward methods like text tutorials. Oh, and TASing has nothing in common with the topic. TASing is about outsmarting a program, not about playing a game just as planned.
AnS
Emulator Coder, Experienced Forum User, Published Author, Experienced player (724)
Joined: 2/23/2006
Posts: 682
fiskerN wrote:
На втором уровне летучих мышей всё-таки решил убивать (2-х мышей). Да, одну мышь из за лага. Вторую мышь если не убивать, то она полетит в сторону направления дейл'а ( т е на право), в результате чего создается не большой лаг и + дейл натыкается на неё, теряет хп, и самое главное отлетает назад...
Самое главное - это сколько кадров теряется/экономится. Если в результате экономится больше, чем теряется, то надо не убивать. И так в каждом случае надо прикидывать.
fiskerN wrote:
Можно было просто затормозить на несколько кадров перед летучей мышью, чтобы она полетела на лево, но это опять же затратится больше времени, чем просто кинуть в неё ящик.
Ясно, ну остаётся только поверить, что ты перепробовал все варианты.
fiskerN wrote:
По поводу прыжков, что кажутся не оптимальными (прыжок с ящиком в руках и т.д.), возникает опять небольшой лаг в несколько кадров, которые приходится пропускать, прыжки я старался делать по максимуму резкими и быстрыми.
При чём тут "резкими"? Такое впечатление, что ты хочешь кого-то обмануть, создав только видимость скорости. Прыжки должны быть просто самыми выгодными (с точки зрения спидрана), а не самыми резкими.
fiskerN wrote:
В холодильнике одну мышь придется пропустить по любому, потому что если не пропустим то получим дамаг об неё и потратим большее время.
По крайней мере с вентиляторами надо переделать тактику. Ты даже не постарался применить их влияние на вертикальное ускорение Дейла.
fiskerN wrote:
На боссах были развлекательные движения (не на всех).
Видел, но в основном они не очень развлекательные, скорее, просто беспорядочное мельтешение.
fiskerN wrote:
В этом то и прикол весь, что это прохождение за 1 игрока, где нет второго, чтобы помочь быстрее перелесть, пролететь на шарике и убить практически любого босса за 5 секунд. Это 1 игрок, тут всё гораздо сложнее и интереснее(на мой взгляд), что и должно заинтересовать зрителей после просмотра прохождения за 2 игроков.
Ну, может быть кого-то и заинтересует. Когда засабмитишь, увидишь голоса за и против. Но я бы на твоём месте перед сабмишеном переделал пробег, там ещё многое можно улучшить.
fiskerN wrote:
AnS, дай пожалуйста ссылочку где будет проводиться голосование. (не совсем ещё разобрался в этом сайте)
Ты же ещё не сделал сабмишен. Когда будешь готов, заполняй эту форму и появится голосование на форуме: http://tasvideos.org/SubmitMovie.html
Post subject: Re: Submission
AnS
Emulator Coder, Experienced Forum User, Published Author, Experienced player (724)
Joined: 2/23/2006
Posts: 682
Как-то мало ререкордов. Первым боссом (да и всеми остальными) можно было бы манипулировать тоже. Летучих мышей на втором уровне всё-таки решил убивать? Почему это быстрее, чем просто пробежать? Из-за лага, или ещё что-то? Во многих местах, где экран поднимается, некоторые прыжки кажутся не самыми оптимальными. Это надо тщательно тестировать, у меня-то времени нет, но ты должен был проверить все варианты (а судя по счётчику ререкордов, ты записал только первое, что показалось достаточным). В холодильнике опять ждёшь кучу времени, пока мыши уедут - тут явно можно быстрее пробежать. 16850 - вот тут просто кошмарное ожидание. Нет, это совсем не похоже спидран. Ты хоть пробовал подняться не прыжками, а с помощью вентилятора слева? 17200 - тут прыгнул на вентилятор слишком высоко, из-за чего долго не мог приземлиться (17270-17295), потерял время. В целом, пробег производит впечатление типичного ТАСа новичка. Если бы других ТАСов этой игры не было, то опубликовали бы и пробег такого уровня (чтобы потом его кто-то обогнал), но т.к. уже есть пробег за двоих, да ещё и более быстрый, то вообще не факт, что опубликуют даже ТАС от мастера. На вагонетках ты что, решил переключиться со спидрана на "no-damage"? Ты бы лучше определил приоритеты перед началом записи, чтобы не менять их посреди ТАСа.
fiskerN wrote:
В основном заметные улучшения начались с 4 уровня, а именно с призрачного босса. Манипуляция удалась, а именно пришлось зайти на 2-3 кадра позже: призрак кидал только шарики, и иногда эти шарики не сразу нужно было кидать в него.
Можно было бы ещё постараться получить по два шарика за каждый заход. Один раз у тебя там это получилось. Со страусом, кстати, хорошо вышло, только в конце он один раз всё-таки сделал ненужную атаку (уехал за экран вместо выброса шестерёнок). Это ты манипулировал, или просто повезло?
fiskerN wrote:
В моментах, где приходилось ждать, я старался делать различные красивые и смешные движения, чтобы прохождение не показалось скучным зрителю.
Я заметил только твитчинг (чередование поворотов спрайта вправо-влево). Было скучно. На первых нескольких боссах вообще никаких развлекательных движений не заметил, сразу хочется нажать турбо-перемотку (Tab). Лучше бы ты больше рисковал и издевался над боссами по-всякому. Конечно, при игре на двоих гораздо проще придумывать всякие смешные способы взаимодействия персонажей на экране, но раз ты считаешь, что пробег на одного тоже может быть интересным, то надо было это показать. В итоге самый интересный момент - кадр 11400, когда ты использовал пчелу для прыжка через большое пространство. Остальное всё так себе. Я бы проголосовал Meh.
AnS
Emulator Coder, Experienced Forum User, Published Author, Experienced player (724)
Joined: 2/23/2006
Posts: 682
HappyLee, don't be so pessimistic, it's just luck manipulation! Common thing for TASes (well, not very common for SMB because of the nature of the game, but here you finally stumbled upon it). CheepCheeps are created periodically (using FrenzyEnemyTimer), as well as some BulletBills in 5-3 and later. Their properties are set using global RNG (Linear feedback shift register of 7 bytes: 0x7A7-0x7AD). The RNG changes once per frame (even when the gameplay is paused), so it's simple Frame-based RNG. It means you can get different outcome by waiting different amound of frames. However, with periodic enemies is SMB things get hard to control, because FrenzyEnemyTimer (0x78F) is initialized near the beginning of level (where the first CheepCheep appears) and the only way to manipulate the timer (and thus change the sequence of new CheepCheeps apearance) is to wait some frames at the beginning of the level. As for manipulating properties of new CheepCheeps, there are few dependencies on player's current speed and horizontal position, as you can see in the game code.
InitFlyingCheepCheep:
         lda FrenzyEnemyTimer       ;if timer here not expired yet, branch to leave
         bne ChpChpEx
         jsr SmallBBox              ;jump to set bounding box size $09 and init other values
         lda PseudoRandomBitReg+1,x
         and #%00000011             ;set pseudorandom offset here
         tay
         lda FlyCCTimerData,y       ;load timer with pseudorandom offset
         sta FrenzyEnemyTimer
         ldy #$03                   ;load Y with default value
         lda SecondaryHardMode
         beq MaxCC                  ;if secondary hard mode flag not set, do not increment Y
         iny                        ;otherwise, increment Y to allow as many as four onscreen
MaxCC:   sty $00                    ;store whatever pseudorandom bits are in Y
         cpx $00                    ;compare enemy object buffer offset with Y
         bcs ChpChpEx               ;if X => Y, branch to leave
         lda PseudoRandomBitReg,x
         and #%00000011             ;get last two bits of LSFR, first part
         sta $00                    ;and store in two places
         sta $01
         lda #$fb                   ;set vertical speed for cheep-cheep
         sta Enemy_Y_Speed,x
         lda #$00                   ;load default value
         ldy Player_X_Speed         ;check player's horizontal speed
         beq GSeed                  ;if player not moving left or right, skip this part
         lda #$04
         cpy #$19                   ;if moving to the right but not very quickly,
         bcc GSeed                  ;do not change A
         asl                        ;otherwise, multiply A by 2
GSeed:   pha                        ;save to stack
         clc
         adc $00                    ;add to last two bits of LSFR we saved earlier
         sta $00                    ;save it there
         lda PseudoRandomBitReg+1,x
         and #%00000011             ;if neither of the last two bits of second LSFR set,
         beq RSeed                  ;skip this part and save contents of $00
         lda PseudoRandomBitReg+2,x
         and #%00001111             ;otherwise overwrite with lower nybble of
         sta $00                    ;third LSFR part
RSeed:   pla                        ;get value from stack we saved earlier
         clc
         adc $01                    ;add to last two bits of LSFR we saved in other place
         tay                        ;use as pseudorandom offset here
         lda FlyCCXSpeedData,y      ;get horizontal speed using pseudorandom offset
         sta Enemy_X_Speed,x
         lda #$01                   ;set to move towards the right
         sta Enemy_MovingDir,x
         lda Player_X_Speed         ;if player moving left or right, branch ahead of this part
         bne D2XPos1
         ldy $00                    ;get first LSFR or third LSFR lower nybble
         tya                        ;and check for d1 set
         and #%00000010
         beq D2XPos1                ;if d1 not set, branch
         lda Enemy_X_Speed,x
         eor #$ff                   ;if d1 set, change horizontal speed
         clc                        ;into two's compliment, thus moving in the opposite
         adc #$01                   ;direction
         sta Enemy_X_Speed,x
         inc Enemy_MovingDir,x      ;increment to move towards the left
D2XPos1: tya                        ;get first LSFR or third LSFR lower nybble again
         and #%00000010
         beq D2XPos2                ;check for d1 set again, branch again if not set
         lda Player_X_Position      ;get player's horizontal position
         clc
         adc FlyCCXPositionData,y   ;if d1 set, add value obtained from pseudorandom offset
         sta Enemy_X_Position,x     ;and save as enemy's horizontal position
         lda Player_PageLoc         ;get player's page location
         adc #$00                   ;add carry and jump past this part
         jmp FinCCSt
D2XPos2: lda Player_X_Position      ;get player's horizontal position
         sec
         sbc FlyCCXPositionData,y   ;if d1 not set, subtract value obtained from pseudorandom
         sta Enemy_X_Position,x     ;offset and save as enemy's horizontal position
         lda Player_PageLoc         ;get player's page location
         sbc #$00                   ;subtract borrow
FinCCSt: sta Enemy_PageLoc,x        ;save as enemy's page location
         lda #$01
         sta Enemy_Flag,x           ;set enemy's buffer flag
         sta Enemy_Y_HighPos,x      ;set enemy's high vertical byte
         lda #$f8
         sta Enemy_Y_Position,x     ;put enemy below the screen, and we are done
         rts
Unfortunately, the speed and horizontal position affect CheepCheep properties much less than predetermined RNG affects them, so manipulating CheepCheeps is more about waiting at the beginning of level, and (to lesser extent) about slowing down during the level run. Oh, and shooting CheepCheeps or keeping them alive can change the sequence sometimes, because there can be only 3 CheepCheeps on screen (or 4 in Hard mode), so when FrenzyEnemyTimer is about to create new CheepCheep, you can prevent it from doing so by having 3 CheepCheeps still on screen. This way you postpone CheepCheep creation to next time when FrenzyEnemyTimer gets ready, and at that time RNG will have different values, so properties of new CheepCheep will be different from what it would be with current RNG.
Post subject: Re: Jurassic Park
AnS
Emulator Coder, Experienced Forum User, Published Author, Experienced player (724)
Joined: 2/23/2006
Posts: 682
Hi kylelyk! Please call it "TAS Editor" since now, thank you.
kylelyk wrote:
I have link a folder containing compressed movie file fm3 file: https://docs.google.com/open?id=0BzYN4VRJkm_CMzU3YjJmNGUtOWQ2Zi00ODk0LTk1ZjItYWM4NTAyY2IzNGUw
When you want to share TAS Editor projects, use File->Save Compact and uncheck Greenzone, then file size will be much smaller. Do note that right now not many people can watch your project file, since FCEUX 2.1.6 isn't officially released yet. You're jumping the gun. Better just Export your project to FM2 file and upload it to the Microstorage.
kylelyk wrote:
How do I find glitches? I found some particularities in movement, but nothing that allows me to go faster.
Experiment with the game a lot. Spend weeks and months trying to find anomalities and loopholes in the game rules. Explore different combinations of ingame events. Be creative and don't be lazy. That's all.
kylelyk wrote:
Is there documentation on TASedit in the newest version of 2.1.6? I haven't been able to figure exactly how branches work and I think I'm missing out on a tool that will speed up my optimization process.
The documentation is being written right now. It's going slowly, but I really hope it can be published this month. There will be very detailed "Beginner's Guide". It's gonna be long read. As for Branches, they work like savestates - you can save current condition of your movie to any slot, then you can restore it anytime. Bookmarks-Branches aren't really that important in TAS Editor, first you should learn to optimize input efficiently. This may take some time.
AnS
Emulator Coder, Experienced Forum User, Published Author, Experienced player (724)
Joined: 2/23/2006
Posts: 682
TheAxeMan wrote:
Looks like a bug got introduced in 2.1.5 affecting rectangle drawing. The graphics inside a rectangle are offset, shifted up about 10 pixels or so. This didn't happen in 2.1.4. I've shared this lua with others and they see the same issue. I think it happens with any rectangle, but definitely with my crystalis hitbox lua. lua code a few posts from the end of the thread here: http://tasvideos.org/forum/viewtopic.php?t=390
http://tasvideos.org/forum/viewtopic.php?p=297025#297025
AnS
Emulator Coder, Experienced Forum User, Published Author, Experienced player (724)
Joined: 2/23/2006
Posts: 682
OK, done. But you won't see any symbols on frames where you invoke disk commands, so you'd better set Markers to remember the place. And to delete these commands you'll have to delete the frame. This feature isn't used often enough to grant adding new columns to Piano Roll.
AnS
Emulator Coder, Experienced Forum User, Published Author, Experienced player (724)
Joined: 2/23/2006
Posts: 682
XTREMAL93 wrote:
How?
Short answer: TASEditor v1.0.
XTREMAL93 wrote:
Not so good encode
Make better encode, if you like the game. Or even better, go and beat this record! ;)
Post subject: Re: Bad Game Choice (Long Rant)
AnS
Emulator Coder, Experienced Forum User, Published Author, Experienced player (724)
Joined: 2/23/2006
Posts: 682
goofydylan8 wrote:
With NES being a gateway for most people into the world of TAS'ing this is a problem.
This is indeed a problem that should be solved by trying to expand the gateway to other platforms, and not by endorsing NES even more (by accepting bad games from this platform). Your suggestion won't help to solve the problem in long term.
AnS
Emulator Coder, Experienced Forum User, Published Author, Experienced player (724)
Joined: 2/23/2006
Posts: 682
XTREMAL93, раз тебе уже помогли найти игру на Эму-Раше, удаляй свой вопрос отсюда или пиши, что уже нашёл (+сообщи название) http://tasvideos.org/forum/viewtopic.php?p=301767#301767
AnS
Emulator Coder, Experienced Forum User, Published Author, Experienced player (724)
Joined: 2/23/2006
Posts: 682
Вот тут спрашивай, регистрироваться не обязательно. http://forum.emu-russia.net/viewforum.php?f=14
XTREMAL93 wrote:
какие кнопки лучше настроить для сейвов и лоадов? желательно не комбинации клавиш
Так как нужен мгновенный доступ к любому из 10 слотов, то требуется выделить 20 клавиш - половина для сохранения, половина для загрузки. Лично мне удобнее пользоваться рядом F1-F10 для загрузки, и этим же рядом клавиш + с зажатым Shift для сохранения. В большинстве эмуляторов это настроено по умолчанию, выходит, многим удобнее всего работать именно так.
AnS
Emulator Coder, Experienced Forum User, Published Author, Experienced player (724)
Joined: 2/23/2006
Posts: 682
Bump. Since feos asked me to translate my post to English, I'll expand it a bit. While this thread is about personal preferences in distributing 10 slots, I think that specific scheme is irrelevant to effective TASing. It's more important to learn mindless juggling with savestates. Not just use them often, but do it more often than common sense suggests. No excuse is needed to save or load a savestate. The ultimate goal is to move savestating to motor memory and release brain for more diverse stuff like analysing game. When you successfully moved savestating into motor memory, you'll subsonsciently assign your own priorities to each of 10 slots (e.g. the easiest key to reach will become your most important slot, but you don't need to think about it, it should appear naturally). I like to compare "savestates juggling" to how experienced pianist plays music - he doesn't need any time to decide which key to press, and he often performs a coordinated sequence of presses (saving/loading many slots in a split second), without really planning it ahead. When you use only one savestate slot and save/load occasionally, this would be the same as playing piano with one finger. I noticed some newbies use rerecords as rarely as in casual retrogaming, which doesn't produce good TAS. From my old TASing experience I can remember entering flow state of mind and being able to do many save/loads within a second. Like this... ..Loaded the segment10, saved to1, advanced 4 frames, noticed possibility, savestate2, now Read-only, teleport to5, grasped set of buttons, jumped back to2, recorded some frames, saved to3, replayed from1, noted inconsistency, teleport to5, turbo to6, loaded5, loaded2, loaded5, loaded2, loaded5, recorded different set from 5 to 6, noted, restored6 by jumping to2, copy insight instead of buttons now, saved to2, noted success, saved to1, saved to9, loaded1, moving ahead!..
1 2
14 15 16
27 28