Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Nach wrote:
The rules should not be game dependent. It is unfair to players because they won't know until after submitting if they happened to trigger especially bad emulator behavior. We're not going to keep track of a whole list of exceptions for games and which areas in them and tricks and what not that are or are not implemented well.
At some point you kind of have to. FCEUX for example is capable of recreating SMB3 ACE just fine, but the arrangement of houses it gives at the start of Paperboy is impossible, making our current run of that game kind of pointless. Can a new run of paperboy be made on FCEUX? It would seem that it can't, even though FCEUX can make even console verifiable runs of other games.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Hi,
I found out that you can KO Apollo at least after the second knockdown. Here is a movie that does it (syncs in most recent version of BizHawk.)
I just used random button presses after the second knockdown, since I noticed there is some variation in the count if you randomly punch before the screen transitions, and by chance it led to a KO.
I imagine you can do this to the other fighters as well (maybe even after the first knockdown?) so this run can be improved significantly.
http://tasvideos.org/userfiles/info/39828386441038365
EDIT: also, GG and SMS runs really should be made using versions of BizHawk after 1.19, since significant accuracy improvements were made at that time. I know we're not real strict about bizhawk versioning, but in this case it does matter.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
After lots of searching and experimenting for the simplest test case that can provide useful data, I finally stumbled upon Donkey Kong Jr.
The FCEUX version of this run is completely wrong due to bad powerup timing, but Mesen and BizHawk differ by only a single instruction on Frame 242, right when play begins.
The difference is right at an NMI where an RNG routine is being performed. Eventually this change leads to the first red alligator going across the platform in BizHawk (where Jr. promptly runs into him) and down the vine in Mesen, (where Jr. passes but dies shortly there after on the third vine.)
This is much much easier to examine then trying to track pies in Streemerz several minutes into the run, so hopefully with some console testing we can actually learn something.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I've made a few more improvements to NESHawk. I cleaned up the code a bit and refactored some execution, so it got a little faster, and the code base is also in a better form for future testing as needed.
Also I noticed a bug in my ppu code, which was apparently impacting test 2 and 6 in test_apu_2. Having fixed that bug NESHawk now passes all 11 of those tests, so that's good.
I continue to look for things that can possibly impact console testing as well, but so far nothing promising has come up.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Also remember that the A2600 core has settings that control the output of the video window in Atari->Settings (NTSC/PAL) Top line /Bottom line. So you can open a game and make the cropping correct before dumping it. Not sure if this is what you want or not.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
feos wrote:
Just remembered. For encoding we have to crop top and bottom by 16 pixels each. Why are they even there if we need to remove them anyway?
Well, screen size for A2600 games was software controlled. Most games had 192 scanlines, but some had more (Tapper for example had 210.) The defaults are set for the maximum extent I believe.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
natt wrote:
Alyosha wrote:
My opinion though is that at some point we really should be raising the standards of accuracy for NES submissions, especially with Mesen becoming available, otherwise we'll never advance console verification.
Would that mean no more FCEUX?
Yes. If Nestaco improves in accuracy and/or Mesen gets some TAS tools I think it would be time to deprecate FCEUX (and quicknes as well.)
That's just my opinion, but I do think we're getting to that point.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
dwangoAC wrote:
Today I stumbled on Nintaco (http://nintaco.com) which is a new cross-platform open source cycle-accurate NES and FDS emulator and I was really floored with how many features it has. The main interface looks fairly standard:
...
This leads to an obvious question - if it proves itself as a reliable emulator that's in many ways more feature rich than even FCEUX, what's the possibility of allowing the emulator and its movie files to be accepted on the site for submissions?I have to say, before I saw this I wasn't thinking to myself "What the world needs is another NES emulator" but now that I see what it purports to have support for I'm rather intrigued. What are your thoughts? Discuss. :)
Not cycle accurate yet, it fails some of the more difficult tests, but it defniitely has some cool features.
My opinion though is that at some point we really should be raising the standards of accuracy for NES submissions, especially with Mesen becoming available, otherwise we'll never advance console verification.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I've been making some progress on NES audio lately. NESHawk now sounds correct in the APU_mixer tests (which previously sounded very poor) and I implemented correct behaviour to pass a few more of the test_apu_2 tests.
It doesn't really sound any different to me in actual gameplay, but the tests say its much closer to the real hardware, so maybe someone with a good ear might be able to tell the difference.
Currently only test_apu_2 tests 2 and 6 fail, but it's not clear that both of these should pass in the default ppu-cpu alignment. Tepples on NesDev had tested these previously and found that they randomly pass or fail on a real hardware, strongly indicating an alignment problem. Mesen passes both of these tests incidently, so this might be a good opportunity to test for emulation differences.
I've also fixed a number of buggy games recently, although probably no one is actually interested in playing them but hey they work at least.
There is still quite a bit left to do for test ROMs and mapper compatibility, but it's getting there.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
ruadath wrote:
adelikat wrote:
ruadath wrote:
When TASing Game Gear games, BizHawk 1.12.2 TAStudio throws a NullReferenceException and crashes (including BizHawk) every time an attempt to save the project file is made (although from what I can tell, the save does go through).
Please fix.
Works for me on 1.12.2 and latest master. Please provide more info
Just checked again. Apparently using the save method from the drop down menu works, but Ctrl+S causes a crash. Help?
Can you try again in 1.13?
I'm pretty sure I fixed that. The error was that Ctrl+S was trying to do two things, in TAStudio it was saving, but in EmuHawk it was trying to save save ram, which if non-existent caused the null reference exception.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Seems to be working to me, although it took 5 minutes to get into the game...and then I walked backwards over the edge and died and it told me to insert side 2, I'm glad I had a NES growing up.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
It's getting there. Here is the sound after the third round of commits.
If I could get the buzzing sound worked out, I'd be happy with it.
For future work it might be worth it to just integrate the reSID library, since it's at least much closer to the real thing then the high level FFT + attenuation I'm using now, but I'm not interested enough to do it.
Link to video
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Oh yeah, I guess I should spare people the pain of waiting through that horrible and long boot up sequence XD
(I forgot how tedious that is when you don't already have a savestate where you need it)
Link to video
NOTE: This is only a first draft, and should improve a bit by the final version, but don't expect it to sound like VICE (unless Saxxon comes back and codes it up)
