It seems myself and MrWint measured time slightly differently, but there is no disagreement that the time saved in 8-2 is 112 frames. The 2.379 seconds does seem to be in error, more likely 1.863. I really think at least this much should be corrected in the notes so as not to mis-inform people who might read it later. Even if it's not relevent to the judgement, it's still a statement by a judge attached to a player's submission, so it should be as accurate as possible.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
I didn't realize you only had just a couple of days to prepare for this DwangoAC, I never checked the date and just assumed it was at least a couple weeks away.
Under the circumstances I think that went very well, nicely done. Sorry Battletoads gave you so much stress thuogh, I guess True has the magic touch for that game.
Aside from that have you followed the recent Atari 2600 Dragster discussion at all? There's some real interest in having console verification of some A2600 runs. I'm not sure it's interesting enough for any kind of event, but it might raise the profile of TASBot a bit in some other circles. Just a thought since it's current.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
Since I had some time today I decided to see if I could get the last graphics bit, windowing, working. As it turns out, I really should only try to do one thing at a time, because a large chunk of the time I spent on this was just trying to remember what the heck I was doing.
In the end though it worked just fine. This scene from Mega Man 5 is actually pretty challenging to get right graphically, so it's a good sign that things are working well:
A few more small timing things to clean up and it will be time to start audio.
I also did some performance analysis, since this core runs much faster the NESHawk while not really having that much less to do, to see if I could learn anything from it.
One thing I did learn is that statements like this:
state = divider_reg.Bit(9);
are really very expensive. Maybe knowing that can help me speed things up in other places.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
Nach wrote:
I picked a spot before the staircase a bit prior to where HL slows down, as an easy to notice spot. I then went through a bunch of previous movies for the game, looking for the one which did the staircase to flag fastest. Once I found the fastest, I added the time from that point to the time I calculated for HL till that point, and then subtracted that from HL's overall time.
That's the thing, if you're aiming for fastest possible playable time don't do the glitch at all, as the glitch trades playable time for real time.
Which movie did you choose? I don't think I missed anything (I mean, I just had to run up the bricks) but I'd like to be totally positive.
Good point. I went back did a test run and saved 46 frames in NTSC climbing the vine and 30 in PAL. It's surprising how little in game time this saves, but when Mario needs to jump in place it seems like it takes an eternity to do so. But, I also went back and saved the frames in 8-1 in PAL and turns out to be more then I expected at 12.
This is net savings for NTSC of 46 (0.766s) and PAL of 42 (0.84s) so the net result is that NTSC is even further behind then before.
(I'll post some movies maybe tomorrow when I have time to do things more carefully.)
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
SaxxonPike wrote:
It also occurred to me we lack a soft and hard reset. That's priority one. Followed by getting better disk and tape support. We still have quite a few games that aren't loading yet.
This reminded me Saxxon, that interrupts need a second look as well. I ran into trouble with the game MoonDust, which was doing some non-standard stuff with interrupts. The fix was simple but it took me a very long time to realize what the problem was. See this commit: https://github.com/TASVideos/BizHawk/commit/f99f9847b43d7ec51899ef65b91443e14e56b1a7
I didn't check for consistency in the other interrupt sources, so it's possible some issues are related to that.
Also porting reSID would be good so my hackish FFT stuff can be removed.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
^ This isn't a proper analysis quite yet, I want to be a bit more precise first.
To that end, I went back and did actual in game time runs of both NTSC and PAL (and by that I mean I removed the flagpole glitches and didn't slow down in 8-2.)
Here are the runs:
NTSC: http://tasvideos.org/userfiles/info/41492604435603477
PAL: http://tasvideos.org/userfiles/info/41492581593396446
I updated the spreadsheet with the new information, see the IGT tabs.
Right now, NTSC has a long way to catch up. I didn't try to improve 4-2, so maybe a little time can be saved there, but it looks like roughly the same time is lost in bot NTSC and PAL so I doubt it will improve much. I also didn't change the obvious places in 8-1 PAL where HappyLee slowed down to hit some shells.
If we count pipe transitions in 1-1 as non-playable, NTSC has an almost insurmountable 0.65 seconds to improve. Things are little closer if we don't include them, with only 0.24 seconds between them.
If anyone understands the vine glitch in 4-2 better and can improve the runs there that would probably be the biggest place to improve the accuracy of this comparison.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
I still want to know which is faster in game time, PAL or NTSC version. So I started doing my own analysis.
The first thing I checked was about how much time could be saved in 8-2 in both versions.
NTSC: http://tasvideos.org/userfiles/info/41479089906232102
PAL: http://tasvideos.org/userfiles/info/41479114334607148
I'm not HappyLee, but I managed to save 112 frames in the NTSC version and 17 in PAL. Or 1.86s in NTSC and 0.34 PAL. Surprisingly that spring doesn't add up to much (or maybe I'm just bad.) I don't know where Nach's original estimate of 2.37 for NTSC comes from, so if I'm missing something someone please fill me in. Overall so far that adds up 1.54 seconds gained in NTSC.
I'm in the process of making a table for the other level times and will edit this post when I'm done.
EDIT: Here it is: https://docs.google.com/spreadsheets/d/149PjFfAayZw1i_jR3Kew3OA930r5P-v7rz5EI6r4XHw/edit?usp=sharing
My times came in a bit under Nach's original estimates , but roughly by the same amount for both NTSC and PAL. An important note here is that these are only times where you can control Mario, the game accepts inputs (i.e. pause) for much longer then that. I also included the time you have to hit start at the beginning of the game. This is only a first order analysis, as I didn't try to find where HappyLee wasted a few frames here or there in PAL, but unless significantly more time can be saved in 8-2 in NTSC, it's unlikely to be faster.
If anyone has anything to add please let me know.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
Inzult wrote:
I did, in fact. I got the same result. I don't know what I'm missing. At this point, my plan is to just fix the Fighting event and call it a TAS.
Ah, oh well. It looks like the first enemy in swimming in the nico video doesn't take any damage on the first hit (takes 2 kicks to kill him) are you able to reproduce that at all? Weird.
(I tired briefly but couldn't do that either.)
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
Inzult wrote:
Alright. I don't understand how that other TAS gets such long combos in swimming. I'm probably missing something obvious, but I can't get the opponent to not get stunned as soon as he runs out of oxygen.
Does anyone have any insight?
Any progress on this? It may sound obvious, but did you try the (J) version to get the swimming combos?
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
I just finished making NEShawk run in single PPU ticks. This should allow for future improvements such as debugger support. That won't be happening any time soon, but it needed to be done at some point so I wanted to get it done before going more in depth into optimization.
The change only had a small negative impact on general game play performance, which I found surprising. What wasn't surprising though is the negative impact on TAStudio performance, since I had to increase the state size considerably. But I guess if you're running TAStudio you don't need to be running that fast anyway.
I'll be stress testing the changes over the next couple days to make sure everything still funcitons correctly and see if any new optimizations are possible. All test ROMs still pass and my standard Battletoads run still syncs, so in terms of accuracy at least everything seems fine.
Over time I want to make every in house core work this way, and this case was relatively painless so I might work on that sooner rather then later.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
Somehow I don't think I never noticed the original run.
I laughed at the character falling when the bridge exploded, that's a silly re-use of existing animations.
I also really liked the screen transitions this game has, I don't recall seeing that elsewhere.
Voting yes, nice run (even without the pending improvement.)
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
Warp wrote:
On what basis it is determined that two consoles are the "same" console? On what basis it is determined that two games are the "same" game?
Are the NTSC and PAL versions of the NES the "same" console? They are not identical, as there are differences in the hardware. Even the CPU's and PPU's aren't identical (as seen eg. here). They may be very similar, but not completely identical. Eg. their clockrates are different, among other things.
At least for NTSC vs PAL, there are some real differences. There are games (e.g. 'Huge Insect') that rely on glitches in the NTSC ppu that were fixed in the PAL ppu. Thus a direct port of the game only accounting for timing differences would not work in PAL. Beyond that, a large number of PAL demos would not work (or be heavily glitched) if directly ported to NTSC due to relying on behaviour that is different between the two regions. Aside from that as well, the infamous DMC glitch was fixed in the PAL NES.
The somewhat large number of errata fixed between NTSC and PAL might be unique to the NES, I don't really know, but it does put it in an interesting situation to decide whether it's the 'same' or not.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
Nach wrote:
Good thing the timing analysis was under the section labeled NTSC vs. PAL in practice -> This game in particular and not under Judgment.
Not really, incomplete / innacurate analysis doesn't belong there, either.
Having said that, I'm interested enough in the real answer here to try to work it out myself. I won't promise anything immediate, but I'll try to look at some initial stuff this weekend and post it in the game thread. Loose ends like this kind of bug me.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
Nach wrote:
I also raised questions that it's hard to estimate some of it due to a variety of factors.
You did? Where? I only see the part where you said you might be off by a frame either way.
Given Hebrano and HappyLee's statements, the timing analysis seems incomplete and certainly not conclusive (and may even be incorrect.) If it doesn't factor into the judgement, I think it's better to remove it.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
Ok I see what you are saying now. We see this issue in very different ways.
I don't think having in-game conversion comparison is much use without consistent cross obsoletion. The simple solution would be to just publish PAL seperately, which I think is a good option as well.
EDIT: And I think not publishing PAL at all would be a bad choice.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
Nach wrote:
Your point is based upon a concept that a faster version should be the one published and should obsolete the other. I don't think our current NTSC vs PAL rules demand this. If you're suggesting that is something we should codify, you just raised a good argument why we shouldn't.
...what? If you're saying that having neither record published is fine, then we simply disagree (but I don't know if that's what you're saying.)
I'm saying that whatever we base judgements on for conversions, the fastest run of the basis of that judgement should be published. It doesn't have to obsolete another run (ex. the in-game time run doesn't have to obsolete the real time) but it shouldn't be able to be rejected.
That way we always have at least one of in-game time or real time records published.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
I didn't want to disucss that judgement, I was making a general case and just using that as a current example.
Let me try again.
In the current scheme, an in game time run cannot strictly obsolete a real time run in the same region. As such, it is possible for such a run to get rejected.
However, conversion runs are strictly judged against their in-game time counterparts.
This leads to the a situation where a judgement can be made on a submission (of a conversion ex PAL) based on rejected content. If that run is slower in-game time, even if faster real time, it will be rejected even though the other run that is faster is also rejected.
My point is:
This leads to a situation where neither the fastest real time run or the fastest in-game time run is published.
This seems strange to me and my suggestion is always allow the publication of in-game time (if the current rule of judging conversions on in-game time is kept.)
EDIT: well, my actual suggestion is to drop the in-game time comparison, but excluding that this is my second suggestion.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
It is related:
I am open to suggestions, keeping in mind that the movie rules are or should be defined such that it:
should be as clear and unambiguous as possible to follow for the general audience and judges.
I'm saying that the curent situation results in some far from clear results, where it could and should be much simpler.
EDIT: If it wasn't clear, my suggestion is this part: If conversions necessarily are judged across in-game time, then I don't think you should be able to have a situation where the faster in-game time run can't be or isn't published.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
From the SMB PAL thread:
Nach wrote:
Alyosha wrote:
More importantly I find the consequences here a bit strange. Does this mean a run could be submitted of SMB NTSC U that only times playable segments and by this analysis obsolete the current run? I think this is a more important question then what to do with PAL.
You could definitely make such a submission. It would probably be accepted as a new branch if the audience liked it and the judge found it differed enough from the existing content we have.
What if it got rejected? If it were then your in-game time comparison to a hypothetical NTSC run would be to something that exists but is rejected. That certainly seems awkward. Then you'd have a run with a faster in game time (PAL SMB) then a published run (current NTSC SMB), but can't be accepted because it's slower then a rejected run that is faster. 0_0
This seems like a problem to me. If conversions necessarily are judged across in-game time, then I don't think you should be able to have a situation where the faster in-game time run can't be or isn't published.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
Nach wrote:
The first thing I want to shoot down is the idea that SMB PAL is faster than SMB NTSC.
This is a real time run, and the game was completed faster in PAL then NTSC.
Our rules on how to time runs indicate that in some circumstances, for example text in cutscenes that takes varying times in different languages, some times are discounted for the pruposes of comparison.
So, if you meant that you are extending these rules to the noted instance of 'non-playable' parts, and that you are considering time based on that, then I think this section should indicate so. (And personally I think this is a stretch and not what the intent of that rule is, but that's probably another debate.)
None of that shoots down then idea that PAL is faster then NTSC, it only shows that it's slower in our restricted rule set.
More importantly I find the consequences here a bit strange. Does this mean a run could be submitted of SMB NTSC U that only times playable segments and by this analysis obsolete the current run? I think this is a more important question then what to do with PAL.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
My proposal would be that if you are aiming for a speed record, use the fastest version of the game (for that console.) To me preferring NTSC U is the outdated part here. Is PAL NES the same console as NTSC NES? Probably close enough (although not 100% compatible.)
But, the bigger picture as I see it is that there is still a much more outdated notion that branches for games should be kept at the bare minimum. This often, and sometimes awkwardly, factors into the judging of new submissions of runs that don't fit neatly into the existing framework.
I think that this problem arises from the idea that any content we accept has to also be published. Publishing is as far as I can tell an arduous process, so this makes sense.
What if instead, we were able to accept runs without the need to publish them? They can exist in movie file / submission page form alone and still be present and searchable. We can save publication for those rus that people find entertaining enough for the effort.
Obviously there would still be need to manage branches somewhat, but you could open up the field a bit at least and take pressure off publishers.
This would of course only work if the moons-vault system were replaced by something game based, so all accepted runs would follow the game. I'm under no illusions that the moons-vault system is going anywhere anytime soon, but these are my thoughs on the matter.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
Any ideas or suggestions are certainly welcome.
It's also worth noting that at some point I need to basically turn the entire frame advance loop inside out so it can run at single ppu ticks and be debugger friendly. Maybe I should do that first before delving too deep into optimizing the current set up as it will likely change considerably.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
I added a choplifter conversion to the opening post. It does not sync (I tried but the first tank always kills me) but the conversion is at least there for anyone interested.
Also, EMU7800 is now completely removed from BizHawk. Despite being a rarely used core, I consider this a big improvement in accuracy and maintainability, so I'm glad it's finally done.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
One thing I never noticed before is that the method where that comes up is already in 'unsafe' mode. 0_0 So I guess array accesses really are that expensive.
I did try flattening out the array thogh and that did noticably speed things up so thanks for the tip!
I also have an array of structs in there and I read before that structs are slow as welll, maybe I'll try mangling that into a flat array and see how much / if it helps. not sure I want to sacrifice the readability that much but if the performance gain is high enough I might try to make it work.
A few more small timing things to clean up and it will be time to start audio.
I also did some performance analysis, since this core runs much faster the NESHawk while not really having that much less to do, to see if I could learn anything from it.
One thing I did learn is that statements like this: