Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I just recently went back to try to match the RTA world record for game 2. I was able to beat it just slightly with a 49.95.
I don't know the programming details of what I changed, I just compared against my old run until I found some improvement.
http://tasvideos.org/userfiles/info/42764456087635749
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Debugging is definitely one of BizHawk's big weak points at the moment. Lack of subframe inputs is as well.
For in-house cores, the situation is at least tractable. NESHawk for example already has the entire core state available on every single clock tick. I've made progress on making other cores work this way as well. Eventually all in house cores will work this way. As feos mentions though this would require a new ecosystem to have any real use, but it's basically doable.
For ported cores the problem seems to be much more complicated. I'm not sure it's really even practical, and the maintanance burden would likely be quite large. But, these are also the cores that people are most interested in, so that's awkward.
Maybe we are just seeing the limits of this kind of multi-system, multi-source architecture?
I think this is already a feature request, not sure if its exactly the same:
https://github.com/TASVideos/BizHawk/issues/267
Sounds difficult and unlikely to happen.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Can I waterbox Mednafen's PCE core? lol no. 8D
I don't know anything about waterbox or mednafen or any of the relevent infrastructure stuff. natt would have to do that one.
I could potentially fix PCEHawk, I've looked into the code base in the past and it's not that much worse then other cores (except for the CD stuff.) It would need a ton of work though starting with a new CPU core.
But, there's really no point in having both in BizHawk. If Mednafen's core was ported, it would 100% obsolete PCEHawk. Properly fixing PCEHawk would by necessity make it on par with Mednafen, so porting it wouldn't be needed at that point.
I think I'll end up doing Coleco Adam next, so at least on my end the PCE can will be kicked down the road a bit longer.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
You win this round QuickNES....
I just added Mapper 114 support for Aladdin SuperGame.
I also cleaned up NESHawk a bit, but it didn't speed anything up.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
There is an MMC3 version that is marked as [!] from GoodNES:
Aladdin (SuperGame) (Mapper 4) [!].nes
md5:505DE5B7465F89013D6797523A079D61
This version hes no lava wall in the last level, it also doesnt run in FCEUX (due to obscure IRQ stuff that I forgot the details of.) Nevermind it seems to run just fine, i must have been thinking of something else.
There is also a 'Mapper 114' version which doesnt work in NESHawk.
So yeah, seems like one of these 2 would be the prefered version?
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Thanks for the testing, that is consistent with what I would expect.
Sorry Sonia but it looks like you just got unlucky :(
I'll try to find some general optimizations that will at least get you back up to 1x speed in games like Kirby. A NES emulator not being able to hit 1x, even under abnormal conditions, just seems silly, there must be something I can do to get some better performance.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
So it seems certain that the PPU changes are the culprit here, but I looked over the code again and there just really isn't anything that would slow it down so much. (It's just a mess of 'if' 'switch' and 'for' loops really.)
From a compiler / different OS perspective (I do all my testing on Windows 10) the biggest change I made was taking FrameAdvance out of 'unsafe' mode since it was no longer relevent. I suppose there is a chance this could have a real impact on performance for your machine, but I wouldn't know anything about why. In looking over things again I also had a spurious 'unsafe' array I just removed, but I doubt that has any impact.
So far the only thing I can see that sticks out is that you are using windows 7. If anyone else with Windows 7 is reading this, can you please try NESHawk and see if you are having any similar slowdowns?
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Thanks for the feedback so far.
I'll look into at least getting Trace Logger going in mGBA, that seems pretty important. I'll probably look at Code Data Logger in NESHawk, although that's less important. The debugger more or less needs a rewrite, so that won't be happening soon.
Our GPGX build is very dated, That one will need natt.
Can you give an example for this one?
Still so much to do! 8D
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Hi all,
I'm looking for input on what things people want to see that I might be able to work on in BizHawk. Up until now I've just done whatever without any real direction. But now I'd like to try to do things that people are actually interested in.
So, just to be clear, I'm looking for things that people would actually, really use to make a TAS, not just 'it would be cool to have this system in BizHawk.' I really want to focus on something that would actually be used to do some TASing.
I've had a request for arcade PacMan, so I'm thinking of doing that, but I'd still like to hear other ideas.
Anyway, I'm open to suggestions. I do still plan on working on GBHawk but it's on the back burner until I can muster up the motivation to do the audio. I like to be working on a few different thing at once anyway.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Hmm, strange stuff.
Maybe it's something like anti-virus or drivers, but I can't think of a reason why only NESHawk would be affected.
Thanks for trying though.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Ah ok, yeah I just happened to be hitting the one screen that wasn't crashing. I do see now that in previous builds the other ones were crashing while in the current build they work fine. Nice.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Fixed.
Although Kattekita Mario Bros wasn't crashing for me previously, where was it crashing for you? Maybe I have a different version?
Also thanks for the valuable R&D on this Sour!
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Do Zelda TASes have a chance at working on console currently? If not I would consider an any% TAS kind of pointless at the moment anyway, might as well wait for CEN64 (assuming it will eventually be finished.)
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Done.
I tested your build, and did not notice any slow down. Try disabling rewind and see if that helps. Also check CPU and memory usage and make sure they aren't off the charts, although I did that on my end and nothing seems amiss.
Also what OS are you using?
I'm not sure what other variables might be at play here. Can you try a Dev Build from right before I made all the changes and see if it works fine there?
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I can't reproduce this so I'm not really sure. If you can zip up the folder you are using exactly as it is and get me a link to it, then maybe I will be able to see what the problem is if it also occurs on my end.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
buttons = { };
analog_sets = { };
while true do
buttons = joypad.get();
analog_sets["P2 Zapper X"] = "30.5";
joypad.setanalog(analog_sets);
console.writeline(buttons);
emu.frameadvance();
end
Here's the simplest example I can come up with. In this example the zapper is plugged into player 2 on the NES.
In this case the joypad.setanalog simply locks the X coordinate at 30.5, as you can easily verify on the game window by turning on input display.
You can just use the console.writeline(buttons) by itself to see what analog controls are available.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
There is no mechanism to assign analog (float) controls to keyboard keys, so that's certainly not happening.
There is a lua function joypad.setanalog, does this not work?
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I think this is a great idea. That would be very cool to see.
As for TASVideos, I don't really see an issue with this. Our technical standards are already quite low, this would be closer to console then like 95% of our current TASes.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I've made some more improvements to the core and fixed a few bugs.
Sync of older runs will not be possible if they use the R register at all. The new core corrects several bugs in the old core and this primarily impacts the R register (which counts up every instruction call) and is sometimes used as a souce for RNG.
At this point we could really really benefit from having console testing of SMS and coleco to precisely test behaviour, but I don't see that as likely to happen any time soon.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
@Sonia: I tested build 0.0.0.1830 and the performance matches my local build , which is about 5% slower then 2.2. For comparison SMB runs at ~135 FPS on 2.2 and ~130 on dev build. So, I'm not entirely sure why your performance has suffered that much. Does it affect any other cores or only NESHawk? Did you compile it on your own or did you use the appveyor download?
@Sour: Ah, thanks for reminding me about that, I was following along when you all were first writing the tests, but then I got distracted by Z80 stuff and totally forgot. I'll try to work through that eventually.