You can only get it the "first time" you play the level. Let's say you get the 1up in the first level, if you die it won't appear the next time. You'll have to be game over first in order to get it again.
More generally, the bonus 1up will always appear the first time you play 1-1; for the other -1 levels it will only appear if you warped there or if you had collected all of the coins in the previous -3 level: http://www.themushroomkingdom.net/smb_breakdown.shtml
That claim looks very suspicious. I think we'll need to do some Source Diving to figure out this one.
Edit: I just read the disassembly, and yes, it's true!
Here's the number of coins you must collect (must be at least this number)
1-3: 21
2-3: 35
3-3: 22
4-3: 27
5-3: 23
6-3: 24
7-3: 35
8-3: 99
The 1-up flag will then be set, so the invisible 1up object will appear. The flag is then unset the first time a 1up object appears.
Also, the coin counter resets every time you change your area. So this is why the X-3 levels never have any pipes to take you elsewhere.
I'm just saying that if you want to TAS any Megaman game, it will probably work fine. But if you want to TAS any Konami game which uses the DMC channel, don't be surprised by a desync.
As far as I know, the NES at least has no non volatile memory. Which would mean that if it is turned on as soon as it is plugged in, then the same demo would be played.
Would unplugging the NES have the same effect?
Dwedit wrote:
The thing about the DMC channel is that its counters are always running no matter what. It's always ticking down so it knows when to fetch the next byte, even when it's turned off.
You say this runs even when the game is off. Are you assuming that or is it known? It could just be left in the state it was in when the game is turned off for when it is next turned on.
Essentially, if we unplugged the NES every time, would the same demo play upon turning on the game's first play?
No, when the game turns the DMC Channel off, not when the game is off.
It's just that the channel starts out with an unknown period before the DMC fetch would happen, and the channel runs continuously whether the game is using it or not. If the game does not use it, then it never steals any cycles, and everything is nice and predictable. If the game does use it though, then you never know exactly how many times the RNG will iterate every frame.
There is never any actual corrupted input, because Blades of Steel read the joysticks twice each frame, and if the joystick input does not agree, it reads it one more time. Most other games which use the DMC channel also do the same.
The thing about the DMC channel is that its counters are always running no matter what. It's always ticking down so it knows when to fetch the next byte, even when it's turned off. When you turn it on, you never have any idea how many cycles will elapse before the DMC reads a byte. Also, its counters are not in a known initial state. So anything that uses the DMC channel will not behave predictably down to the cycle.
Konami Games use a remaining CPU cycle counting algorithm for their random number generator. Those would not be TASable on hardware. Konami isn't the only developer that did that either.
Other games use different RNG methods, so as long as there is not unexpected lag, they should work fine.
Every time you turn on the game, you get a different demo, despite exactly the same input. Therefore, TASs are impossible on NES hardware.
Granted, this game especially exploits some things about the NES:
* It uses the DMC channel during the title screen. The DMC channel's counters start out in an unknown state.
* The DMC channel works by stealing CPU cycles away from the NES, and can also corrupt controller input if the DMC channel steals the bus right when it's reading joystick input.
* It uses a RNG which is basically a CPU cycle counter.
Great job!
I loved this run, especially all the levels that were solved quickly.
Nice to see you exploit the AI at every chance you can get! For instance, the cannon's always targeting the most expensive units so as to create the most money damage, rather than targeting what would matter. Same with the missile silos, target the big mass of units at the start position and ignore the battleship that's actually taking out the important stuff.
Or have the AI just chase after your APC or Lander.
And of course, the neotank which just serves to distract the AI away from the air units which actually do work.
The level where you don't build anything and just wait to get conquered was awesome, because the AI is too incompetent to actually capture your HQ.
I'd say don't do any TASs on the new PPU until the glaring sprite zero hit bug is fixed. Otherwise a TAS of any Konami game which uses sprite zero hit will desync under proper behavior.
Since 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)
In the function FCEUX_PPU_Loop of ppu.cpp:
Change this line: (line #2288)
if(oam[6] == 0 && pixel != 0)
To this:
if(oam[6] == 0 && (pixel & 3) != 0)
This bug was a pretty nasty one, causing it to treat transparent pixels of palettes other than 0 as not transparent.
While you're at it, also add this check right before the PPU_status |= 0x40 line:
if (rasterpos < 255)
{
PPU_status |= 0x40;
}
Still broken, even with New PPU.
Looks like the problem has entirely to do with triggering sprite 0 collisions on pixel #255, when it shouldn't.
For some strange reason, the PPU ignores sprite collisions on pixel #255, and Battletoads relies on this.
So let's say you're the artist. You've just drawn new text for a bunch of panels, and there's this Cannon one right next to the others. Why wouldn't it make sense do quickly sketch some translated text for that panel?
On a real NES, the framerate is 60.099 FPS, assuming the screen is turned on during the pre-render scanline. Otherwise, it's 0.00112% faster if the screen is off.
What really matters is the frame count. It's just that FCEUX calls a frame 1/60.099th of a second, and FCEU calls a frame 1/60th of a second. FCEU just uses bad numbers for establishing length of a movie.
"Lossless" X264 isn't lossless. If it was lossless, there would be under 25 colors in the optimized palette for that frame. If there are any chroma subsampling features, make sure they are disabled.
Also, zoom in on that goomba and see how crappy it looks.
