Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
Currently only joysticks count for input polling.
If it's needed console switches could easily be added just by putting the call in "ReadConsoleSwitches" in Atari2600.core.cs. Is this something you want?
joystick one, joystick two, and console switches are each their own event in this sense, so you have to be a bit careful when looking at / counting polls.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
Nice research on this.
Based on everything you have presented, my guess is random bit flip in $03FB. Since the effect is un-noticable until you reach the boss, and only requires a single bit to change to occur, and can happen at any time before reaching the boss, hardware error seems like the most likely possibility.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
Oh Yeah, I was working on Grand Prix as that time seems by far impossible, but TG people seem to think it can even be beaten, but won't say how.
Anyway, the current release build of BizHawk runs constant length frames for A2600. In other words, all frames are 262 scanlines long. This causes some adverse side effects for some A2600 games because start up times can vary and put frame boundaries in the middle of video frames. Also some frames in games are 263 scanlines long, so this causes a cycling effect.
By pure coincidence, I was working on another bug and realized that it could be solved by only changing frames on video frames, so this is the current implementation in the dev build. So, in that build, frames change at the falling edge of VSYNC.
Side Note: A2600 core originally changed frames on video frames and at some point was changed to constant length frames. And now I changed it back, we aren't very consistent!
EDIT: http://tasvideos.org/userfiles/info/41923259965218113
Here is a movie that gives a 32.74 in the Dev Build. I'm not sure a 32.74 is possible in the release build.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
I did? 0_0
I forget about 90% of everything I do, but I don't recall doing that.
I can however at least reproduce a 32.74 on the latest Dev Build of BizHawk that always changes inputs on video frames, so maybe that's a start.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
Wow that's amazing!
I'm continually impressed at the cool stuff people are able to come up with, even for current technology. I hope this expands to become a more general use application, could really open up the world of testing and analysis.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
I was going to respond to this ealier but then forgot, sorry!
I suppose the discussion could take place there, but I do think it's good to have a dedicated thread where formal decisions are made clear, concise, and documented. It would be great to have a clearly defined way to avoid such huge wastes of time in the future like SMB PAL was (in the event that it ultimately isn't published, which I hope isn't the case.)
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
I'm a little worried about Dragster becoming something of a black eye for TASbot if not handled tactfully. I trust the TASbot team to do so, but just wanted to voice some concern, as a lot could happen between now and January.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
That's cool! Nice find Koh1fds.
As for which emulator to use, at least for the game end glitch run, testing by DwangoAC has showed that it doesn't really matter. The RNG at the life stealers will randomly sync or not, as will the glitch itself, and the inputs up to that point in the current movie are the same for both BizHawk and FCEUX.
For other runs, BizHawk is needed to make sure the RNG syncs later in the run, it's impossible with FCEUX, as every cycle counts.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
Aside from anything else that might happen with PAL, I think there should be an official channel with a garaunteed response that allows this to be practical. The impression I have right now of the site is that throwing something on the workbench is the only way to get a real answer (and not just about this rule in particular.) If there is a way to get a real answer ahead of time, I think this should be mentioned in the rules as well as the process to go about it.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
I think it's ok if you can't formalize those two things. It can be published alongside SMB NTSC just fine on it's own merits (people just saying they liked it.)
I also think exceptions are fine. After all, if judging were nothing more then linearly applying the rules, you wouldn't need to call yourselves judges anymore, I don't think that's an atainable goal at any rate.
But it seems we have different goals here in how to sort this out.
I personally don't see the clutter argument as a real concern. People can find both NTSC and PAL entertaining, and nothing bad will happen by having them published side by side (again, this assumes that the PAL port in quesiton is sufficiently well done like SMB.)
Well, I don't think I can add much more to this though. I don't see the need, or the practically, of having a strict formalism here if the goal is to allow some PAL runs while still preferring NTSC. Saying it's ok and being done with it seems good enough to me. If others like feos are trying to really formalize things here then I wish them luck, as the whole situation is quite messy (as the real world usually is), and I think the end result would end up very little different then just using an exception, probably with just many more words.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
yup, no effect. I would have thought this would help, since it saves so many 'x & 3' operations, but maybe some kind of compiler optimization happens with the '& 3' in the switch since there are exactly four choices there.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
What aspect of the sound is low quality? Can you provide an example game that sounds better in a different emulator?
I don't think I can just increase the sample rate, but if you can provide a concrete example maybe there is something I can fix.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
(state & state_c) == 0
^ This part will always return true (state_c only has bit 2 set but state never has bit 2 set), but that's not what we want. I don't think the original expression can be simplified unless you shift one to match the same bit being set as the other. I'm not sure that's any faster though.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
Well yeah honestly that's kind of what I was going for. It doesn't really need to prove anything except that people like it. And if we just want to be able to publish the couple of good PAL runs that come along every once in a while, just assert that we can do so.
It's kind of like Mothrayas' "special one time exception." If it's good enough to have, just say it's ok. (And I mean that sincerely, not sarcastically, exceptions are needed every now and then.) In this case it's just slightly more formalized since many PAL ports really aren't worth having. But, some are (like PAL SMB in my opinion), so let's leave an opening for them.
As for your bolded question, I really do think something needs to change here. We shouldn't be turning away good runs like SMB PAL was when the site is littered with horribly boring content that's accepted just because someone was able to get a game on a cart and sell it.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
Ok, so far I tried on BizHawk 2.2.0 and no combination of BIOSes synced. But then I tried on 2.1.0 and it synced just fine with only the standard BIOS in the folder (no debug there at all.)
I think part of the problem is that the submission says mGBA 0.6.0 was used, but that wasn't added (according to the release notes) until 2.1.1. The submssion says 2.1.0 was used and this version worked for me, so maybe problem solved? (I sure hope so because I have no clue how this could happen otherwise.)
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
^ That's bad. It shouldn't even be possible.
Also it looks like there is a state error in mGBA. Start TAStudio, advance some frames, hit '<<', game won't load.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
Case by case basis seems fine to me. Maybe just change this:
to this:
To keep things simple and consistent, just publish PAL seperately.
I'd don't think any rule should be tied to the tier system.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
I have completed a new, more accurate in game time analysis here: http://tasvideos.org/forum/viewtopic.php?p=458702#458702
The new runs include time savings in 8-1 and 8-2, and use the vine in 4-2 to save in game time. They also remove all pole clips to save in game time.
overall PAL is faster by 0.9 seconds or 0.4 seconds depending on how you count the pipe transitions in 1-1.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
^ About the same as the current one. (But I believe your new condition statement is incorrect, as state and state_c never have the same bits set.)
So to summarize so far:
- putting failing condition first is the biggest improvement
- bool to int is also a noticable but smaller improvement
- look up table has a negative effect
- everything else has more or less no effect
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
I had actually tested the look up table earlier but it is slower by a LOT. I guess I could try with unsafe too but it's not worth it just for that.
I also tried stringing together '?' operators but that had only marginall effect.
I also tried just replacing the switch with ordinary logic elements but that wasn't much faster either.
Overall it's currently ~30% faster then when I started, and I guess that's about as fast as it's going to get. It doesn't matter much for this case but I thought I could learn something more from it since it's so simple and obviously slow. Oh well though, too much other stuff to do to get hung up on it.
EDIT: I tried your (Sour) other suggestions but they didn't result in improvements. Thanks for coming up with things to try though.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
Ok, I added a volume slider under NES->Sound Channels.
Minimum setting (1) should match current NESHawk uadio.
Maximum setting (10) should be 3x louder. Please try the dev build and let me know if it's enough.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
Hi, the sound seems normal to me. Check the following settings and make sure they aren't turned down:
Config -> sound make sure volume is turned all the way up.
Does QuickNES Sound soft as well or only NESHawk? How about other cores (i.e. SNES) ?
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
Tried aggreisve inlining, no effect, probably the compiler already does it.
Tried removing the Bit call altogether and just using explicit statements like (value & 0x200) > 0, no effect.
Tried changing to integers and rewriting the logic. Small but positive effect, not sure it's worth the reduced clarity.
But the most effective change was putting the condition most likely to be false first in the 'if' statement later on in that function. >___> I guess I need optimization 101.
EDIT:
Here's the complete thing if anyone sees anything obvious. According to performance profiler, this tiny block takes about 1/4 as long to run as the entire CPU function 0_0. So something about it must be super slow:
public void tick_2()
{
divider_reg+=1;
// pick a bit to test based on the current value of timer control
switch (timer_control & 3)
{
case 0:
state = divider_reg & 0x200;
break;
case 1:
state = divider_reg & 0x8;
break;
case 2:
state = divider_reg & 0x20;
break;
case 3:
state = divider_reg & 0x80;
break;
default:
break;
}
// And it with the state of the timer on/off bit
state_c = timer_control & 0x4;
// this procedure allows several glitchy timer ticks, since it only measures falling edge of the state
// so things like turning the timer off and resetting the divider will tick the timer
if ((state == 0 || state_c == 0) && (old_state > 0 && old_state_c > 0))
{
timer_old = timer;
timer+=1;
// if overflow, set the interrupt flag and reload the timer (4 clocks later)
if (timer < timer_old)
{
pending_reload = 4;
reload_block = false;
}
}
old_state = state;
old_state_c = state_c;
}