TASVideos

Posted: 9/3/2017 3:16 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
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.

Posted: 9/3/2017 2:53 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
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.

Posted: 9/3/2017 12:22 AM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
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.

Posted: 9/2/2017 5:15 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
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.)

Posted: 9/2/2017 3:31 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
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?

Posted: 9/2/2017 2:20 AM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
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.

Posted: 9/1/2017 6:52 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
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.)

Posted: 9/1/2017 1:09 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
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.

Posted: 8/31/2017 6:08 PM
(Edited: 4/13/2022 11:03 PM)

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
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.

Posted: 8/31/2017 2:45 PM
(Edited: 4/13/2022 11:03 PM)

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
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.

Posted: 8/31/2017 12:48 AM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
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.

Posted: 8/31/2017 12:12 AM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
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.

Posted: 8/30/2017 11:50 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
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.

Posted: 8/30/2017 11:22 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
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.

Posted: 8/30/2017 11:06 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
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.

Posted: 8/30/2017 10:29 PM
(Edited: 4/13/2022 11:03 PM)

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
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.

Posted: 8/30/2017 10:01 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
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.

Posted: 8/30/2017 1:59 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
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.

Posted: 8/30/2017 1:57 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
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.

Posted: 8/29/2017 10:19 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
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.

Posted: 8/29/2017 3:28 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
Location: US

creaothceann wrote:

Alyosha wrote:
I'm not a programmer in real life
Perhaps you meant "not a professional programmer" ;)

That's for sure, that sounds awful. D: @Sour: I don't know what happened, but I downloaded fresh from github and rebuilt (since my current local build wasn't running anymore for some reason after i compiled it) and now I'm getting the proper fps. It's a bit frustrating that I'm never able to get any evidence of any of these anomolies, but whatever. My only theory is that maybe something with the auto updater is impacting things, but that's just a guess.

Posted: 8/29/2017 2:08 AM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
Location: US

I'd be happy if I could get to 180 fps (without making the code unreadable.) I tried not resetting the other 2 array values but it didn't seem to speed anything up. I'm not familiar with what 'unsafe' code means. I'm not a programmer in real life so to me that sounds ... unsafe. Good idea about the decay function though I'll definitely look into that. Sure I'll report back tomorrow with frameDelay and emulationSpeed values. I'll edit the results into this post. thanks for the help!

Posted: 8/28/2017 2:32 AM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
Location: US

Nope, I tried all speed settings 100%-Max, and each setting gives an fps consistently under the expected except for 100%. 350% for example gives me 190 fps. Yeah I've checked performance profiler several times, but the only thing it really tells me is that everything is really slow. Different parts of the core run as fast as I expect compared to other parts (like relative time running ppu operations compared to CPU,) it's just that each of those things is very slow. I'm not sure why compiled cores like QuickNES run so much faster. Maybe it is something in BizHawk's architecture or in the compiler that makes running compiled DLLs way more efficient, I can't imagine the code itself is that much worse. As an example, even if I never run the CPU (and as a consequence the ppu never gets turned on) , I STILL only get 180 fps max.

Posted: 8/28/2017 12:26 AM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
Location: US

Oh you're right , by hitting the increase speed hotkey I can go up to ~ 350 fps on Mesen. I didn't bother ever doing that because when I put it on 300% speed it was only giving me 160 fps instead of the expected 180 so I thought it was maxed out. Weird. 0_0 Any idea why the fps indeicator is off? Well that honestly makes more sense, Mesen should be way faster given it's C++ core. But NESHawk should still be much better then it is, I wonder if I'm missing some really big slowdown somewhere.

Posted: 8/27/2017 10:34 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3560)

Joined: 11/30/2014
Posts: 2744
Location: US

Recently I've been trying to improve NESHawk's performance. Working on other cores has really helped me see inefficiencies in code and target places to improve. Unfortunately, most of my ideas don't pan out. But, one obvious place to improve that did result in big gains was fetching sprite pixels. Previously, the routine in BizHawk checked every sprite on a scanline for every pixel. This is very inefficient, especially when the information about the sprites doesn't change during a scanline (since it was compiled the previous scanline. ) Instead, I made a buffer to contain sprite data for sprites at the time the sprites are processed. This sped up this part of the code considerably, resulting in an overall speed boost of ~5%. There is still a long way to go though. To give some context, right now NESHawk can run Battletoads at about 130 fps on my laptop. Mesen meanwhile can do around 160 fps. Since so far I'm out of ideas on how to speed things up anymore, that 30 fps difference won't be getting closed anytimg soon. Still, at least fps is slowly going up now instead of down!

Posts for Alyosha