Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Aglar wrote:
AnS wrote:
Basicaly, it made the player teleport 2 screens down and thus instantly fall into a bottomless pit.
It's even more extreme than that, right? That value decreases 2 from 0, meaning that you're actually teleported 254 screens down!
No, wait, since the addresses $CA-CB store the "Camera Y", this value is subtracted from the "Real Y" of an object (to get its onscreen Y).
Normally in 4-1 it calculates like this: OnscreenY = RealY - 0.
But after the glitch it becomes like this: OnscreenY = RealY - 0xFE * 0x100 = RealY + 0x02 * 0x100.
So the onscreen Y of all objects becomes 0x200 pixels more than it should be. And the coordinates are counted top-down.
Aglar wrote:
Makes sense why the video Svenne posted looks like it does. He simply corrupted one or many addresses related to graphics by having the cannon shoot while falling from one of the lower platforms.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Sweet, a memory corrupton glitch.
The "Autobomb" enemy is very buggy, in both PRG0 and PRG1 versions. I wonder why no one noticed it before. Every time it shoots a fireball, it corrupts some byte of zero page!
$AE36: LDX Temp
$AE38: LDA HORIZONTAL_FIREBALL_ID
$AE3A: JSR ShootObject
$AE3D: LDX Temp
$AE3F: DEC Ypos[Temp]
$AE41: DEC Ypos[Temp]
The code is typical for many NES and SNES games. The "Temp" variable stores current value of "objects counter" (e.g. if there are 6 objects on screen then the loop should iterate through those values: 0, 1, 2, 3, 4, 5). The iterator (counter) is used to access memory arrays storing objects' properties (X/Y coordinates, direction, ID, timers, etc). Naturally, the value of the counter is supposed to always be within the range [0 - MAX_NUMBER_OF_ENEMIES). In SMB2U the max is 9.
But here's what went wrong. The "ShootObject" function uses "Temp" variable for its own purposes (to calculate Y coordinate of the new object, so that it appears right from the cannon nozzle). So after creating the fireball the counter value becomes corrupted, and any following RAM access (using this counter as a reference) will modify someone else's data!
In theory the value of counter can be anything from 0 to 0xFF, so those two instructions (DEC Ypos[Temp]) may alter any address in the zero page of RAM (decrease the value by 2).
But in practice some values are more likely than others, because of level design. The Autobomb's Y coordinate is usually the same (the enemy moves back and forth horizontally), for example when the enemy is on the high platform its Y = 0x70, thus the counter turns to 0x90, and the code will corrupt address $C3. If the enemy falls to the lower platform, its Y becomes 0x80, and the iterator turns to 0xA0, the code will corrupt address $D3. Same with $E3 and $F3. But all those addresses don't seem to hold any critical data, so this blatant bug was left unnoticed.
The real potential of the bug comes from the very small possibility that the Autobomb shoots in the middle of falling from a platform to platform.
This death glitch appeared because the Autobomb created a fireball while having Y = 0x77, so the code decreased $CA, which stores the higher byte of vertical scrolling position. Basicaly, it made the player teleport 2 screens down and thus instantly fall into a bottomless pit. That's why no death animation was played.
Here's Lua script that helps you monitor the glitch:
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Warp wrote:
THC98 wrote:
-First thing you have to know about 3D optimizing is that you must hold the perfect angle in your TAS Input for EVERY move, making you go in the most straight line to the next curve or obstacle
Actually that's not always the case.
I think the sentence is meant to be the most basic guideline which is as archetypal as "never release Right button even for a split second" in 2D games. I mean, the overly imperative tone of this statement inherently assumes there are game-specific exceptions and additional rules.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
I want to clarify some.
Nach wrote:
The previous run found a shortcut in level 3 which essentially leads to a buffer overflow.
No. The cause of the glitch is not buffer overflow, but wild pointer. The essence of the jet glitch is described here (in Russian though).
Nach wrote:
Instead of abusing that glitch to its fullest, it simply took the data initially written there and skipped a single level.
No. Previous run didn't simply took the data. Both runs create objects by deliberately corrupting memory. It's just that previous run didn't modify properties of several objects, and only created LevelEnd object by writing data to its ID (by setting $16 to 0x7F when the broken pointer was pointing at the address).
New run first creates object 0x79 (rat boss) to let it set some properties before actually creating 0x7F.
This process is only half-studied, and most of the work in this run is done through bruteforce (exhaustive testings of various inputs while monitoring memory through Lua displays). It's probable that there's even faster way to write necessary data to the addresses, but further investigations would be more effective if the game is disassembled, which is actually what feos and people were doing recently. A lot of other glitches arise in the process, but since they are very unlikely to finish the game faster than this jet glitch, there's little to no motivation to investigate them. Basically, this is the clear case when speed kills creativity. Here's this killer-glitch, and other glitches are not worthy to develop, since they will never be faster than this one.
While this "greedy algorithm" of TASing behavior sounds reasonable, it is narrow-minded, because you never know what could happen if you chose a circuitous route.
But to clarify feos question about the ObjectCounter glitches (e.g. stick glitch).
In this game there are other ways to corrupt memory and deliberately create objects, not just by abusing wild pointer.
For example, you can create a stick object in level 4 even in realtime by changing player Y during specific lag frames.
Since the category of the glitch is basically the same as the glitch used in this run (memory corruption), does it mean that feos should avoid using all memory corruption glitches from now on? Or only the jet glitch (plot-based limitation of glitch)?
You know, instead of creating the stick he could probably create a 0x7F object (but since it's happening in level 4 and not 3, it still would not beat the record).
And even if he knows the glitch can be abused to gain speed instead of entertainment (skip the level instead of playing it with an object that is not supposed to exist in this area) - why can't we consider it a speed-entertainment tradeoff and let it be?
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
This one-glitch demonstration should not obsolete existing warped run, since the entertainment offered here fades away after initial surprise (it's not like you'd want to watch this movie twice, unlike the previous Battletoads submission). Sure, technically it's the same glitch, but the result is different enough, that's all that should matter.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
goofydylan8 wrote:
chiptune95 wrote:
Soy but I just want to delete the author's informations messages who are in the fm2 file, if it's possible
thanks :)
If you are going to use input that someone else made then you should not be deleting them from the list of authors
I think such matters should be decided only after the TAS is complete and ready for submission, when you are able to weight contributions. If you only use old movie for comparison and to learn tricks, there's no point in stacking all previous authors in the list.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
chiptune95 wrote:
hi to all
I downloaded the fm2 file of the run of SMB3 (in 10:25 minutes) for change it (to make a "small only" run) but the problem is that I don't know how to delete information messages written by the authors of the run ...
thanks for answer :)
You can use Notepad++ to edit FM2s, but I don't recommend rerecording the whole FM2 file made by someone else if you only plan to borrow some input. Better idea would be to create your own project (with your name as author and with rerecord counter = 0) and import the old input there.
1. Download new version of FCEUX from here: http://fceux.com/zip
2. Open the ROM, then open TAS Editor in FCEUX menu: Tools->TAS Editor.
3. In TAS Editor menu: File->Import Input, then choose the FM2 you want to take input from.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Svenne wrote:
TAS:ers, I need you help! This happened to me during the ESA Charity marathon: http://sv.twitch.tv/ludendi/b/329357607
And no, no second controller was plugged in, Aglar or anyone, give me an answer plz! Would be greatful!
Too bad you couldn't record an FM2 with the bug, it would be trivial to dissect it in FCEUX.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
I think it's the influence of unassisted speedrunning. In the same vein as limiting arcade TASes to 1 coin, it's supposed to make movies more impressive for casual audience.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
That is not a TAS. It's pure bot work with suboptimal strategy as a result.
Did you know about this cheat code?
Open Minesweeper, then type the letters xyzzy and hold the shift button for three seconds. Now whenever you are about to click on a cell, look at the top left corner of your monitor screen. If the pixel is white, then its ok to click. If the pixel turns black, then it means you are pointing at a mine.
Of course a program (bot) doesn't need to look at pixels, it can just read from memory and see which cells have mines. Then it only needs to iterate through all cells and simulate mouse click (by sending WM_LBUTTONDOWN message) for those cells that don't have mines.
Now, for this to be called a TAS, the bot should calculate the least amount of clicks (not clicking on auto-opened cells, see the human-made TAS of GB Minesweeper) instead of iterating through all cells.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Да, в будущем необходимо портировать Тасэдитор на другие эмуляторы, но в ближайшее время я собираюсь взять основательный перерыв, подустал как-то от всего этого.
WST wrote:
Я всегда мечтал о нормальном редакторе для gens, а ещё очень хотелось бы в самом gens что-то типа редактора коротких паттернов, которые можно забиндить на горячие клавиши.
Это ты мыслишь в рамках традиционного подхода. Вводить паттерны в игру по мере её прохождения - это всё равно не так эффективно, как один раз нарисовать нужный паттерн и затем либо копипастить его, либо перемещать на кадр выше/ниже, чтобы он выполнялся в нужное время.
WST wrote:
По сути мне от редактора нужно немного — возможность копипаста из пробега в пробег, правки данных в кадрах, а также удаления и вставки кадров.
А вот, например, такую штуку не надо? ;)
WST wrote:
Ну и иногда бывает такая ситуация: ты тасишь игрушку и вдруг приближаясь к концу, обнаруживаешь возможность улучшить один из первых уровней…
Кстати, в мануале рассмотрено несколько таких ситуаций. Ты почитай его, даже если не собираешься практиковать ТАСинг на NES, там и теории предостаточно, и универсальных знаний (полезных и без Тасэдитора).
WST wrote:
Хотя ещё, как вариант, можно подумать о самостоятельном (без связи с эмулятором) редакторе на каком-нибудь Qt, но это, наверное, всё-таки не будет так удобно.
Да, это уже будет не то. Тут самое удобство в том, что получаешь мгновенную отдачу от изменений Ввода.
В принципе, разумно было бы портировать на мультисистемный эмулятор, тот же Бизхок, но он, опять же, на дотнете.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Привет всем.
На днях я дописал русскую версию Руководства, поэтому сразу выкладываю здесь.
Некоторые уже в курсе, что я почти год пишу глобальную софтину для облегчения ТАСинга. Теперь к ней готов подробнейший Мануал, так что, пока идёт его перевод на английский, предлагаю всем русскоговорящим ТАСерам и сочувствующим оценить эту затею ещё до официального релиза на сайте.
Тасэдитор - это редактор мувиков, встроенный в эмулятор, чтобы просматривать изменения игры одновременно с редактированием. Причём ключевое слово - одновременно, а не через минуту или секунду. Например, такая ситуация: бежит Марио вперёд, вы рисуете мышкой кнопку A и видите, как он прыгает, дорисовываете ещё ряд A подлиннее - видите, как увеличивается высота прыжка, если получилось слишком высоко, то укорачиваете этот ряд нажатий кнопки A, глядя на синхронное изменение игры, ну и так далее. Вместе с возможностью гибко управлять временем это даёт очень классные, хотя и специфические ощущения во время ТАСинга.
Там ещё много фич реализовано за прошедшее время. Визуализация рабочих данных, автоматическая подгонка мувика, всякие полезные мелочи, которых мне очень не хватало раньше, когда я записывал ТАСы дедовским методом. По личным ощущениям, ТАСить в Тасэдиторе раз в десять проще, чем жонглировать сэйвами в традиционном методе ТАСинга. Только требуется приноровиться, для чего и рекомендую почитать данное Руководство:
На русском:
http://www.fceux.com/web/help/taseditor-ru/
На английском:
http://www.fceux.com/web/help/taseditor/
Сначала советую глянуть Глоссарий, а потом уже засесть за Курс новичка. В этом Курсе описываются не только принципы работы с Тасэдитором, но и вообще суть ТАСинга, типовые приёмы и прочее. Дорого бы я отдал за такой учебник в 2006 году!
В общем, если вам интересен ТАСинг, найдите время для чтения и практикования работы с Тасэдитором. Если там что-то не понятно написано - сообщайте в этой теме, постараюсь переосмыслить. Может даже, вы тем самым поможете мне улучшить читабельность текста.
Скачать FCEUX 2.2.0 со встроенным Тасэдитором можно отсюда:
http://www.fceux.com/web/download.html
Да, пока Тасэдитор есть только в FCEUX, так что пробуем ТАСить для NES, но если многим понравится, как-нибудь портирую на другие эмуляторы. Я считаю, будущее ТАСинга именно за этим методом.
Комментарии приветствуются!
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
FatRatKnight wrote:
Until I can put the time into figuring out how my own stuff works again, you're more or less on your own. Which is too bad, since I'm really the only "expert" on this script, and I've lost any memories necessary to give a decent answer.
Hey I know that feeling... That's basically why I've spent more time on documenting TAS Editor than on coding it. Knowledge is too ephemeral when not formalized properly.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Bisqwit wrote:
How should the values of the society change then? In my eye the best solution to that would be the fulfillment of Ezekiel 11:19-20: "And I will give them one heart, and I will put a new spirit within you; and I will take the stony heart out of their flesh, and will give them an heart of flesh
It would be too easy to achieve happiness by changing the definition of happiness (by switching values of society). Sounds like direct RAM editing instead of just making keypresses and finding the best output from whatever stones we have inside.
I'll pretend that I only saw this good line: "copyright monopoly lasting 70 years after author's death is ridiculous and should be changed to e.g. 10 years after the creation".
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Brandon wrote:
for a game like Mega Man 3, I feel like both could be acceptable as the debug mode is severely limited. I can't teleport or auto-kill everything, so I figure there's still a challenge in finding the best time using these methods.
I understand, it's the same kind of challenge as How Many Five Year Olds Could You Take in a Fight, which is interesting in theory, but not quite noble in practice. Thus I figured a playaround would be much more popular than a speedrun.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
If the resulting TAS will be entertaining, it may be published as a concept demo, why not. Sure it can't compete with regular tool-assisted speedruns of the same game, so a playaround is probably the only way to go. But it'll require really versatile imagination, to make good use of debugging possibilities. Because the TAS will inevitably be compared to a machinima video, it has to provide some kind of narrative (consistency of events), so you can't just showcase all the tricks, you have to be creative. It's not as straightforward as pure speedrunning.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
feos wrote:
If you emulated a segment, then changing the input you cut the greenzone, it counts as one rerecord.
The point is: its behaviour is inherently the same as in old emulators.
Outside TASEditor: the rerecord counter increments every time you edit something you have watched. It doesn't increment when you blindly append the movie by recording Input without knowing the future. But it does when you return back and edit the movie by rerecording Input for frames you've seen.
In TASEditor: the rerecord counter increments every time you edit something you have emulated/Greenzoned. It doesn't increment when you blindly change the movie by editing Input on whitish rows of Piano Roll. But it does when you move mouse cursor up to previously verified part of the movie and edit it.
feos wrote:
Loading a branch is also one.
Only when the branching changes the Input in Greenzoned part of the movie.
If you repeatedly tap the same "load state" key, for the first time it will increment the rerecord counter, but for other times the Input won't be changed, thus the rerecord counter won't increase.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
I think the death abuse should at least be tested, so that we may know the theoretical limit of the game in terms of speed. Hope it'll be less than 25 minutes.
goofydylan8 wrote:
This game is just so frustrating. Adding 1 frame at any point means redoing the entire rest of the game as how many and where the lag frames occur, and the jumping height and speed for each jump changes due to the randomness.
But, if you were practising traditional method of TASing, you'd quickly get used to redoing small and large chunks of input again and again.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Voting Yes. Great game and quite good TAS.
Heisanevilgenius wrote:
Why would someone make this? Obviously they have a lot of talent. The graphics, music, and engine are all excellent. Couldn't they have made their own original game rather than painstakingly recreate EVERYTHING iconic about Megaman?
It's called doujin game for a reason. Of course they could make completely original game, but they deliberately put cameos and tropes to excite nostalgia and sense of community and fellowship.
They also achieve special kind of novelty by combining familiar elements in a new way (for example, this game nods to both Megaman and Castlevania series - doesn't that sound awesome? Well, the implementation could be better, but it's still fun to play). I doubt Capcom and KONAMI would ever come to an agreement and make any kind of a crossover between those series, so hurray for fan games!
Heisanevilgenius wrote:
I'm just going to abstain from voting here. :p The TAS is nice, but I just can't sit through the whole thing because of how ridiculously derivative the game is.
But can you sit through Megaman2-10 after you saw Megaman1? Or it's different for copyright holders?
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
As much as I eager for innovations in TASing, I have to admit not all ideas produce decent results, at least when applied to SMB. Maybe there are games where an MP run would look impressive, but for SMB/SMB3 it looks more like pre-frame advance era TAS.
This particular idea comes from abusing current format of TASes (being sequences of button states). Note that "abusing" is positive term here.
But unlike other original ideas (pacifist runs, walkathons, multigame TASes) that put restrictions on gameplay, this idea doesn't alter gameplay and doesn't make sense outside TASVideos. And I mean today's TASVideos, because someday we might as well change format of movies (like storing replays as events, or storing input as snapshots of player's behaviour), so this kind of restriction would become even more unnatural.
Anyway, if it was an interesting TAS, I wouldn't overanalyze all the matter and would agree with artificial self-imposed rules, but since the movie was pretty boring, I have to rationalize my No vote.
The "Autobomb" enemy is very buggy, in both PRG0 and PRG1 versions. I wonder why no one noticed it before. Every time it shoots a fireball, it corrupts some byte of zero page!
