Experienced Forum User, Published Author, Experienced player
(871)
Joined: 9/18/2008
Posts: 148
Location: Japan
Nice improvement. Just in case, I converted the movie to fm2 and confirmed that it syncs on FCEUX 2.1.5. So I voted yes.
But I have some anxiety to accept FM2/TAS movies simultaneously. I glanced at the code of BizHawk and found that its CPU emulation is not identical to FCEUX. For example, BizHawk does not emulate the RMWW (read-modify-write-write) behavior of RMW (read-modify-write) operations. In some tases, the difference of emulation may cause desyncs. (And indeed, my Double Moon Densetsu tas desyncs on BizHawk 1.0, although I don't know the cause)
Experienced Forum User, Published Author, Experienced player
(871)
Joined: 9/18/2008
Posts: 148
Location: Japan
Well, I played this movie on BizHawk 1.0 as a test, and it desyncs at about 20200 frame. (To load the ROM of this game on BizHawk, you have to add an entry to NesCartDB XML. I put the edited DB (the entry is not complete, but it is sufficient to load the ROM))
I don't know the cause of the desync, but anyway this movie syncs only on FCEUX.
Experienced Forum User, Published Author, Experienced player
(871)
Joined: 9/18/2008
Posts: 148
Location: Japan
c-square wrote:
3) The route isn't even optimal. In the last dungeon, the player doesn't even take the shortest distance to the stairs, but wastes time going the long way around.
I should have mentioned about this in my submission (even if probably you have already guessed the reason:). There are some chutes on the first floor in the final dungeon, and that's why I do not go straight to the stairs. I added a note to my submission. Thanks!
Experienced Forum User, Published Author, Experienced player
(871)
Joined: 9/18/2008
Posts: 148
Location: Japan
Dacicus wrote:
I did notice that sometimes you bought the item that costs 5 money pieces from the shop and sometimes the one that costs 200. Were those specific items necessary for the memory manipulation you did?
Yes. Antidote (5 gold, id:0x3F) is cheap and useful to fill up item-repository, but I need some expensive items to manipulate memory. Here is the list:
* Source of Magic (1000 gold, id:0x5D) - I need this to write 0x5D as the character id of 4th.
* Spellbook of Outcold (400 gold, id:0x70) - I need this to write 0x70 as the character id of 4th.
* Spellbook of Outflame (400 gold, id:0x71) - I need this to write 0x71 as ship position x.
* Healing Herb (200 gold, id:0x3C) - I need this to write 0x3B as item-count.
Besides, I buy 32 Antidote to fill up item-repository. So I need 2160 gold (1000+400+400+200+5*32). When I return to Saicon, I have only 866 gold, so I sell these items to make money:
* Scimitar (500 gold)
* Earring (500 gold)
* Spellbook of Multiheal (300 gold)
Experienced Forum User, Published Author, Experienced player
(871)
Joined: 9/18/2008
Posts: 148
Location: Japan
I might find a cause of the emulation problem of "Mahjong (J)" (please refer to my previous post).
I examined FCEUX source code again, and I found that FCEUX takes only 512 CPU clocks to execute a sprite DMA. But NesDevWiki says:
This takes 513 cycles to copy 256 bytes from this memory into $2004
Experienced Forum User, Published Author, Experienced player
(871)
Joined: 9/18/2008
Posts: 148
Location: Japan
Last year I reported an emulation problem of "Mahjong (J)", but still it haven't been fixed and I don't know how to do about it (About this problem, please refer to the post I have linked to).
So, I patched VirtuaNES 0.97 to generate trace logs (it logs only program counter), and I compared the log with FCEUX trace log (VirtuaNES seems to emulate "Mahjong (J)" correctly). After all, I couldn't find the cause of this problem, but I uploaded the logs. I hope someone could find a solution.
There may be different versions of this game. I used "Rev B" (md5: 38abeee1b7148a5ff13f8f2ef6ab22e9). And I used emulators below:
* FCEUX r2194, old/new PPU
* FCEUX r2194mod, old PPU (I mention about r2194mod later)
* VirtuaNES 0.97trace (applyed the patch aforementioned)
And, in the all logs, I held <START+A> from power-on.
Dealing routine is $D2BF (I call it deal()), so I truncated the logs until the execution of deal(). I also attached a full trace log of FCEUX, and it is logged until 194F (deal() is executed at the frame).
I think the problem is the execution count of the routine which updates random number. The routine is at $FCC2 (I call it rand_update()). On FCEUX, rand_update() is called 8186 times until deal() is executed. On VirtuaNES, 8185 times. FCEUX updates random number in surplus by 1.
This game continues to call rand_update() while it is waiting NMI ($CE4C). So I guess there may be something wrong with the implementation of PPU.
I noticed that FCEUX waits the first VBLANK for a long time. It takes 59683 CPU clocks. On the other hand, VirtuaNES waits only for 27409 CPU clocks. I think the cause is "ppudead" logic (in ppu.cpp) of FCEUX.
According to NesDevWiki:
The VBL flag ($2002 bit 7) is usually clear at power, and unchanged by reset. It is next set around 27384, then around 57165.
So, VirtuaNES seems right at this point. Thus I tried patching the old PPU code of FCEUX (this is r2194mod) to wait the first VBLANK as long as VirtuaNES, but it didn't affected the hand dealt. I don't know exactly which is right, but anyway this likely has nothing to do with the first problem.
But, I also noticed that even the FCEUX r2194mod executes about 140 more operations until deal() is executed, than VirtuaNES does. On average, FCEUX appears to execute slightly more operations at one frame than VirtuaNES does.
Experienced Forum User, Published Author, Experienced player
(871)
Joined: 9/18/2008
Posts: 148
Location: Japan
klmz wrote:
There were moments in this movie when the awesomeness of TAS powers were displayed, but the game seemed to suffer from overly low difficulty and simplistic level design.
I agree with you. I think this game has good idea, but it looks like a rush job. I tried bringing out the goodness of the idea.
What in this movie do you think were the most attractive to you?
I mostly like the levitation of 1-4, and I like the vine boost of 2-1, 2-BOSS fighting, and breaking blocks of 2-4.
Experienced Forum User, Published Author, Experienced player
(871)
Joined: 9/18/2008
Posts: 148
Location: Japan
There is a fairy at the beginning of area 12 (I knew this by ZANAC MANIAX).
With the fairy, you can destroy the first form the fortress instantly (I made a movie). So I think it will help to improve this run.
Experienced Forum User, Published Author, Experienced player
(871)
Joined: 9/18/2008
Posts: 148
Location: Japan
I put some lua scripts.
Checking savedata:
Language: lua
emu = emu or FCEU
local SAV_BASE = 0x6300
local SAV_SIZE = 0x0300
function sav_chk(n)
local base = SAV_BASE + SAV_SIZE*n
local sum = 0
for addr = base, base+SAV_SIZE-1 do
sum = sum + memory.readbyte(addr)
end
sum = bit.band(sum, 0xFF)
local chk = memory.readbyte(base+SAV_SIZE-2)
return sum, chk
end
function draw()
for i = 0, 3 do
local sum, chk = sav_chk(i)
local chk_str = "OK"
if chk ~= 0x5A then chk_str = "NG" end
gui.text(64*i, 0, string.format(
"%d:%02X(%s)",
i, sum, chk_str
))
end
end
gui.register(draw)
Watching stack pointer:
Language: lua
emu = emu or FCEU
local VIEW_SIZE = 8
local GUI_ALPHA = 0.8
local DRAW_SP_X = 0
local DRAW_SP_Y = 0
function draw()
gui.opacity(GUI_ALPHA)
local sp = 0x0100 + memory.getregister("s")
local view = {}
for i = 1, VIEW_SIZE do
view[i] = memory.readbyte(sp+i)
end
gui.text(DRAW_SP_X, DRAW_SP_Y, string.format(
"stack $%04X: %02X %02X %02X %02X %02X %02X %02X %02X",
sp,
view[1], view[2], view[3], view[4], view[5], view[6], view[7], view[8]
))
end
gui.register(draw)
Experienced Forum User, Published Author, Experienced player
(871)
Joined: 9/18/2008
Posts: 148
Location: Japan
If we can modify $6012 or $6312, we will be able to achieve a great improvement.
If you modify $6012 to 0xD5 (or 0x01, ...) by cheat, Jade Portal appears. And, savedata is almost a copy of $6000-$62FF. So, If we can modify $6012 or $6312, we can skip most event.
But we can't modify $6312 by spellbook glitch, so I don't know whether it is possible. If you can manage to let the 4th character equip the item 0xFE (かめん), you can modify $6312 using spellbook glitch. But this is originally a keyword, not an item. So we can't get this as an item usually. And, we can't equip it (even as an item) via the menu.
Or, it's possible that you can modify $6312 with 45-floor bug. But I don't know even the probability of it.
Experienced Forum User, Published Author, Experienced player
(871)
Joined: 9/18/2008
Posts: 148
Location: Japan
I will mention about another glitch called "45-floor bug" (FF3j also has this bug). If you go up/down stairs in a kind of dungeon, the stack of CPU continues to grow, and finally, you can't go up/down stairs. If you do a "heavy" process in this condition, the stack overflows and the game will be freezed. I think it would be difficult to predict the effect of this glitch (the NMI address of this game is $0100).
45-floor bug is inspected by Fazz (Japanese), and he says we can cause 45-floor bug in dungeons such as:
* we can enter by events (eg. Arena of Palamecia, Base of Altair, Phin Castle)
* has multiple entrance (eg. Cave of Bofsk)
I tested for Base of Altair and Cave of Bofsk, and confirmed the bug occurs.
I think we need to encounter an enemy to make the stack overflow. I couldn't cause stack overflow in Altair.
Here is the movie performing this glitch (in Cave of Bofsk):
http://dehacked.2y.net/microstorage.php/info/350006923/Floor45.fm2
This movie causes a reset on old PPU, a freeze on new PPU. I don't know the detail of PPU, sorry.
Experienced Forum User, Published Author, Experienced player
(871)
Joined: 9/18/2008
Posts: 148
Location: Japan
Dada wrote:
Actually, this looks great. Just the fact that attacking with certain tomes does absurd damage at low levels will be a great help.
Nice find!
Here's a video for those who are curious: http://www.youtube.com/watch?v=edH3qCkEUKw
Thank you for encoding!
Well, spellbook of Fire is very strong, but it often misses after mid-game. If you use it, you may need to train Strength. And, it refers an insane address as skill-level, so you may need to consider about it.
Experienced Forum User, Published Author, Experienced player
(871)
Joined: 9/18/2008
Posts: 148
Location: Japan
I found a glitch to corrupt (first) savedata, but this probably wouldn't lead to drastic improvement. Anyway, I will write what I know for reference.
First, spellbooks can also be used as two-handed weapons. To do so, equip a spellbook as an item, encounter an enemy, and exchange your weapon for the spellbook. The effects of spellbooks vary, and some of them make the game freeze after chacacters attack with them. But spellbook of Fire is very strong (it works like Blood Sword).
And, if a character fights using a kind of spellbooks, the skill of another character (after him) is trained. So, if the 2nd-4th character does it, the memory out of range will be changed. By the way, savedata ($6300-) exists right after skill data ($6200-). So we can corrupt savedata using spellbooks.
Here is the table of spellbooks to corrupt savedata:
# Spell Skill TargetAddress
Fire magic[0] of next character $6310
Stun magic[0] of next character $6310
Minimum magic resistance of next character $6332 # freeze
Blink ? of next character $633A
Esna axe of next next character $630C,$634C
Forg spear of next next next character $6308,$6348,$6388 # freeze
Wall spear of next next next character $6308,$6348,$6388 # freeze
Clouda spear of next next next character $6308,$6348,$6388 # freeze
Toad spear of next next next character $6308,$6348,$6388 # freeze
Haste spear of next next next character $6308,$6348,$6388 # freeze
With these books above, we can modify the addresses below:
$6308 Chokobo state (1:exist, 2:riding, 3:permanent)
$6309 Chokobo x
$630C passenger ship state (2 or above:can be taken, even:route1 odd:route2)
$630D passenger ship x
$6310 player x in the overworld
$6311 player y in the overworld
$6332 chest flags
$6333 chest flags
$633A chest flags
$633B chest flags
$6348 event flags
$6349 event flags
$634C event flags
$634D event flags
$6388 keyword
$6389 keyword
But, this game checks the sum of savedata on reset. So, we need to adjust the sum, modifying multiple values. savedata is considered valid when:
* sav[0x02FE] == 0x5A (this condition is fulfilled when you do save once)
* sum(sav) == 0xFF
To adjust the sum, attack/cancel trick will be useful.
Well, we can indeed modify savedata, but the values are treated as skill levels, so the format of value is limited. For x/y in the overworld, I think we can modify only y in practice.
Permanent Chokobo may be useful, but it doesn't disable encounters.
We can use passenger ship as usual ship. To do so, modify the ship state, and simultaneously push <start> when you take the ship. This is well-known as "menu glitch".
We can modify some event flags, but I think they are not so useful.
We can get some keywords, but I think it is not so useful. By the way, if you write an item-id to keyword area and "ask" about it, it looks like the "keyword" works as "item". But in fact, the "keyword" doesn't change any event flag, so it's useless.
Overall, I think this glitch is not so useful for now. We can go to Dist by passenger ship, but it seems that we need to finish all events after all.
Here is the movie performing this glitch (modifying y in the overworld):
http://dehacked.2y.net/microstorage.php/info/1142883529/SaveGlitch.fm2
Experienced Forum User, Published Author, Experienced player
(871)
Joined: 9/18/2008
Posts: 148
Location: Japan
Randil wrote:
Regarding the matlab program. Your Y speed when you make a jump depends on your X speed when you press A. It also depends on if you hold down right or left when pressing A. And in turn, your initial Y speed will have an impact on how many frames your sprite is inside the block when you hit it with your head. The matlab program I wrote wasn't very complicated. I simply told it how the jumping physics worked in this game, and it told me what X speeds that resulted in a jump that gave me maximum time inside the block.
That's mostly what I use matlab in TASing for. If the game's physics are easily predicatable, you can just write a matlab program that simulates these physics and can brute force test all (or at least extremely many) possible ways of solving something.
Thanks! I have thought about simulating game physics, but I never thought about using matlab to do it. This idea may also be useful for my projects, so I will study matlab :)
And, I found narimasa had uploaded his improved run (J version). He says it is in 49474 frames:
http://dic.nicovideo.jp/v/sm8222456 (apparently, fcm/fm2 is not available)
Do you know this narimasa, TaoTao? Perhaps you can ask him to upload his movie file somewhere?
I have watched some of his videos, but I don't know him personally. I commented on his video asking him to release his movie file. But he have never released any movie file, so I don't know he does so.
Randil wrote:
I'm also wondering, is there an easy (and legal, of course) way to download videos from nicovideo? If the .fm2 or .fcm isn't available, it would be easier for me if I had the nicovideo movie on my hard drive.
It seems that Craving Explorer is widely used to download nicovideo, but I haven't used it and don't know much about it. If you have installed python, nicovideo-dl or smget(made by me) are available. But anyway, you will have to get nicovideo account to use these tools.
Or, you can simply watch the video via "dic.nicovideo.jp" url, and salvage cache files of your browser. With this method, you don't have to get nico account. Anyway, I believe there are no legal problem with downloading videos from nicovideo.
Randil wrote:
I have also managed to perform the wall zip in level 3-1! Here's the .fm2 of this submissions with this edited in. The zipping is optimized, I wrote a matlab program that optimized it for me. This movie is 264 frames faster than this submission so it saved quite a lot of time.
Nice! Your next run will be more cool. And, I'm surprised that you are using matlab to make TASes. It is very interesting. I hope if you write some article to utilize matlab for TASing someday.
Experienced Forum User, Published Author, Experienced player
(871)
Joined: 9/18/2008
Posts: 148
Location: Japan
Randil wrote:
It would be awesome if it could be incorporated in the run.
I agree. I hope this glitch is useful :D
And, I found narimasa had uploaded his improved run (J version). He says it is in 49474 frames:
http://dic.nicovideo.jp/v/sm8222456 (apparently, fcm/fm2 is not available)
Experienced Forum User, Published Author, Experienced player
(871)
Joined: 9/18/2008
Posts: 148
Location: Japan
It seems that FCEUX does not emulate "Mahjong (J)" correctly.
This game has a well-known cheat. On a real console, if you perform a soft/hard reset holding <START+A>, you get an excellent hand. But, if you try the cheat on FCEUX, you get a different hand.
Note: you must keep holding <START+A> until the hand is dealt.
Here is the screenshots of the cheat:
Left is the result on a real console. Right is the result on FCEUX.
For a real console, I tested the cheat on my "New Famicom" (HVC-101) for 100+ times, and I always got the left result. I did not test it on a "Famicom the first" (HVC-001) because I do not have it now, but I think you will get the same result on a HVC-001. If you have this game and FC/NES variants, please try the cheat.
For FCEUX, I tested on 2.1.3, 2.1.2, and latest interim build, and I always got the right result, regardless of new/old PPU. And FCEU 0.98.28 produces the same result.
I tested on some other emulators. I got the left result on the emulators below:
* VirtuaNES 0.97J
* NNNesterJ 0.23
* Nestopia 1.40
* Nintendulator 0.970-unicode
And, G-NES 0.618 produced another result.
This issue is not the problem of the initial state of RAM. This game clears the entire RAM, at $CA54, on every RESET interrupt. So this game does not depend on the initial state of RAM. I think this is the problem of timing.
The random number of this game is a 256-bit shift register, and it exists at $23-$42. And the random number is clock-dependant, and you can change the value by your inputs. Because, this game continues to update the random number in NMI-waiting loops, and the input-related routine consumes a little more cycles if you do a input.
When you execute the cheat on a real console, the hand is generated from the 8186-th random number. But on FCEUX, it is generated from the 8187-th. The fact indicates that FCEUX is not strictly accurate at timing, doesn't it?
Experienced Forum User, Published Author, Experienced player
(871)
Joined: 9/18/2008
Posts: 148
Location: Japan
I remember FCEU does not have savestate.persist(). Is this function really necessary?
I read the svn log (r870) of FCEUX, and I understood this function was introduced to optimize the performance, processing savestates on-memory. But, I think this function and its documentation spoil the compatibility with FCEU and they are confusing.
FCEUX Help wrote:
savestate.persist(object savestate)
Set the given savestate to be persistent. It will not be deleted when you load this state but at the exit of this script instead, unless it's one of the predefined states. If it is one of the predefined savestates it will be saved as a file on disk.
I understood the sentence above like below:
* By default, anonymous savestates will be deleted when they are loaded. But if you call persist() against them, they will be remain until the exit of the script.
* By default, predefined savestates will not be deleted when they are loaded. But if you want to write them out to disk, you must call persist() against them.
For predefined savestates, it is true on FCEUX 2.1.2. But for anonymous savestates, it is not true (they will not be deleted when they are loaded, in any case).
First, is the feature which deletes anonymous savestates when they are loaded really needed? If not, persist() against anonymous savestates is meaningless, isn't it?
And, I think the feature which does not write predefined savestates out to disk by default is not compatible with FCEU, and confusing. If a person uses a predefined savestate, his purpose will be reusing the savestate after the exit of the script, in most cases. Indeed, writing savestates out to disk whenever they are saved may be slow, but saving is not so frequent operation as loading, isn't it?
How about removing this function and reverting the feature to that of FCEU?
Experienced Forum User, Published Author, Experienced player
(871)
Joined: 9/18/2008
Posts: 148
Location: Japan
Well, this time I didn't contributed at all, so the player list above may be some mistake ^_^;
Anyway, great improvement beyond my expectation. This time Rockman becomes the real "Warpman" in the woodman stage. The encode on nicovideo is nice too :D
Experienced Forum User, Published Author, Experienced player
(871)
Joined: 9/18/2008
Posts: 148
Location: Japan
FYI: I have watched another run of this game (J version, "Kakefu-kun no jump tengoku speed jigoku") played by narimasa:
http://dic.nicovideo.jp/v/sm6972518 (fcm/fm2 seems not available)
Your run seems to beat that run successfully in most stage, but in a stage, that run seems to be a little faster than yours (watch from 10:00 of the movie above). But I have never played this game, so I don't know whether your run is improvable (I don't know the differences between J and U).
With the fairy, you can destroy the first form the fortress instantly (I made a movie). So I think it will help to improve this run.
Left is the result on a real console. Right is the result on FCEUX.
For a real console, I tested the cheat on my "New Famicom" (HVC-101) for 100+ times, and I always got the left result. I did not test it on a "Famicom the first" (HVC-001) because I do not have it now, but I think you will get the same result on a HVC-001. If you have this game and FC/NES variants, please try the cheat.
For FCEUX, I tested on 2.1.3, 2.1.2, and latest interim build, and I always got the right result, regardless of new/old PPU. And FCEU 0.98.28 produces the same result.
I tested on some other emulators. I got the left result on the emulators below:
* VirtuaNES 0.97J
* NNNesterJ 0.23
* Nestopia 1.40
* Nintendulator 0.970-unicode
And, G-NES 0.618 produced another result.
This issue is not the problem of the initial state of RAM. This game clears the entire RAM, at $CA54, on every RESET interrupt. So this game does not depend on the initial state of RAM. I think this is the problem of timing.
The random number of this game is a 256-bit shift register, and it exists at $23-$42. And the random number is clock-dependant, and you can change the value by your inputs. Because, this game continues to update the random number in NMI-waiting loops, and the input-related routine consumes a little more cycles if you do a input.
When you execute the cheat on a real console, the hand is generated from the 8186-th random number. But on FCEUX, it is generated from the 8187-th. The fact indicates that FCEUX is not strictly accurate at timing, doesn't it?