F:\Games\(e) NES\Blaster Master (U) [!].nes
What's the status on new PPU? Should I use it in my run? I noticed that Acmlm used it on Dragon Warrior.
adelikat has recommended consistently that the old PPU be used.
The new PPU offers increased accuracy but changes timing. Old PPU should be used for watching older movies but New PPU is recommended for new TAS movies.
Switch to the new PPU and it will be fixed.
local PrettyColors={
0x0000FFFF, 0x0020FFFF, 0x0040FFFF, 0x0060FFFF,
0x0080FFFF, 0x00A0FFFF, 0x00C0FFFF, 0x00E0FFFF,
0x00FFFFFF, 0x00FFE0FF, 0x00FFC0FF, 0x00FFA0FF,
0x00FF80FF, 0x00FF60FF, 0x00FF40FF, 0x00FF20FF,
0x00FF00FF, 0x20FF00FF, 0x40FF00FF, 0x60FF00FF,
"#80FF00FF","#A0FF00FF","#C0FF00FF","#E0FF00FF", -- Odd glitch with red
"#FFFF00FF","#FFE000FF","#FFC000FF","#FFA000FF", -- when at least 128...
"#FF8000FF","#FF6000FF","#FF4000FF","#FF2000FF",
"#FF0000FF","#FF0020FF","#FF0040FF","#FF0060FF",
"#FF0080FF","#FF00A0FF","#FF00C0FF","#FF00E0FF",
"#FF00FFFF","#E000FFFF","#C000FFFF","#A000FFFF",
"#8000FFFF",0x6000FFFF, 0x4000FFFF, 0x2000FFFF}
while true do
gui.pixel(0,0,0x00000000) -- Clears gui
local Clr= PrettyColors[ ( movie.framecount()%36 )+1 ]
local T = zapper.read()
T.y= T.y-8
if T.fire == 1 then
gui.line( T.x , 0 , T.x , 220 ,Clr)
gui.line( 0 , T.y , 255 , T.y ,Clr)
end
emu.frameadvance()
endSince I don't know whether people read the SF tracker or not, I'm cross posting here. Bug fixes for the file PPU.CPP: In the function CheckSpriteHit of ppu.cpp: Change this line: (line #1078) if((sphitdata&(0x80>>(x-sphitx))) && !(Plinef[x]&64)) To this: if((sphitdata&(0x80>>(x-sphitx))) && !(Plinef[x]&64) && x < 255) This bug was a pretty nasty one, causing it to treat transparent pixels of palettes other than 0 as not transparent.
I'll see if I can incorporate some more features like avi dumping...
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?
Normally i would say Yes, but thennI thought "its not the same hack" so ill stick with meh.
