Editor, Experienced Forum User, Published Author, Expert player
(3628)
Joined: 11/30/2014
Posts: 2765
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
(3628)
Joined: 11/30/2014
Posts: 2765
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
(3628)
Joined: 11/30/2014
Posts: 2765
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
(3628)
Joined: 11/30/2014
Posts: 2765
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
(3628)
Joined: 11/30/2014
Posts: 2765
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
(3628)
Joined: 11/30/2014
Posts: 2765
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
(3628)
Joined: 11/30/2014
Posts: 2765
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
(3628)
Joined: 11/30/2014
Posts: 2765
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
(3628)
Joined: 11/30/2014
Posts: 2765
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
(3628)
Joined: 11/30/2014
Posts: 2765
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
(3628)
Joined: 11/30/2014
Posts: 2765
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
(3628)
Joined: 11/30/2014
Posts: 2765
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
(3628)
Joined: 11/30/2014
Posts: 2765
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
(3628)
Joined: 11/30/2014
Posts: 2765
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
(3628)
Joined: 11/30/2014
Posts: 2765
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
(3628)
Joined: 11/30/2014
Posts: 2765
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.
Editor, Experienced Forum User, Published Author, Expert player
(3628)
Joined: 11/30/2014
Posts: 2765
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.
Editor, Experienced Forum User, Published Author, Expert player
(3628)
Joined: 11/30/2014
Posts: 2765
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!
Editor, Experienced Forum User, Published Author, Expert player
(3628)
Joined: 11/30/2014
Posts: 2765
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.
Editor, Experienced Forum User, Published Author, Expert player
(3628)
Joined: 11/30/2014
Posts: 2765
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.
Editor, Experienced Forum User, Published Author, Expert player
(3628)
Joined: 11/30/2014
Posts: 2765
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!
Editor, Experienced Forum User, Published Author, Expert player
(3628)
Joined: 11/30/2014
Posts: 2765
Location: US
Ninja Golf is done and linked in the opening post. It synced easily with just some minor lag adjustment.
Scrapyard Doog is converted but failed to sync (desyncs early in level 1.) This game is sensitive to timing so I'm not surprised. It's also linked in the opening post anyway though.
Barnyard Blaster I'll try later but I doubt anything useful will come from it.
I'll also try Choplifter later as well.
Editor, Experienced Forum User, Published Author, Expert player
(3628)
Joined: 11/30/2014
Posts: 2765
Location: US
It turns out that movie recording for A7800Hawk was broken in the current BizHawk release. Frustrated, I decided to buckle down and implement the Pokey sound chip, which was the last thing holding up the removal of EMU7800. Removing it allowed a cleanup of the core swapping code and naturally fixed movie recording. (As a side note, I went back and looked and a one line copy-paste error was what broke movie recording, and had I been less frustrated I would have probably just fixed that instead, but at least the end result is good! :) )
Now Ball Blazer and Commando, the 2 games requiring Pokey emulation for sound to work, will have proper sound in A7800Hawk.
Along with this I have removed EMU7800 as an option from BizHawk's core list. Going forward new releases of BizHawk will only contain A7800Hawk, as it is vastly more accurate then EMU7800. I recommend new movies only be made with A7800Hawk, although obviously EMU7800 is not officially deprecated and submitting runs made on it in older versions of BizHawk is still permitted.
If anyone has any runs they started in EMU7800 that they would like converted toA7800Hawk and can't figure out how, send me the movie file and I can do it. (It's a pretty painless process that takes < 5 minutes once you figure out the details.) I cant promise it will sync after though.
EDIT: On the front page I linked to re-synced movie files of published EMU7800 runs for anyone interested.
Editor, Experienced Forum User, Published Author, Expert player
(3628)
Joined: 11/30/2014
Posts: 2765
Location: US
Warp wrote:
Isn't that what the live commentary is for? The commentary is what makes the run interesting to the viewers.
TASeditor wrote:
As Warp already said, these runs wont be uncommentated. Infact the right commentary should make the key difference between holding peoples attention or not.
My point was meant to be that even with live commentary it won't be very interesting without something interactive, sorry this wasn't clear. Right now we're talking about 3-4 people sitting on the couch for ~30 minutes playing pre-recorded inputs off someone's laptop. There won't be a 'runner', no one will even have a controller, and TASBot doesn't even need to be there. Sure this will be more representative of typical TASing, but to me it doesn't sound very fun.
Editor, Experienced Forum User, Published Author, Expert player
(3628)
Joined: 11/30/2014
Posts: 2765
Location: US
dwangoAC wrote:
Having said that, I really do like the idea of a badge / icon that indicates a given run has been shown at a GDQ for the ones that *are* published. Thoughts?
I think it's a good idea. GDQs are our only real exposure to a general audience, and runs featured there are also some of our best content.
dwangoAC wrote:
I, for one, would welcome a fun exploit with a short but interesting payload if it fit in with the rest of the block well. Bonus points if said ACE allows us to do a credits roll to on-screen highlight the efforts of everyone who contributed to the TAS block, that was a good choice during AGDQ 2017. Yet again I end my diatribe with the question - thoughts?
I don't think a TAS block would be much fun or entertaining without something like this. As Mothrayas pointed out earlier, a lot of the fun of watching GDQs comes from the humanness of live runs and runners. Even with good commentary, we miss out on this entirely (especially if it's just replayed on a computer which is another step removed from actually playing the game.) Something interactive in real time with a real person (like SMB3 or Mario Kart choco mountain were) is much more entertaining in my opinion.
I'm not purposely trying to be a downer here, but I'm pretty skeptical that just playing several normal TASes back to back will hold many people's attention.
EDIT: I guess since I'm advocating for something interactive I should give an example of something that could be done within the relatively short time available and without great technical difficulty. One avenue of ACE that is untapped so far is sending information back to TASBot via controller pings. As long as it's only a few bytes per frame, there should be enough time to send information to some offboard script for processing, and send the results back to TASBot to write back to the game. Ex SMB in SMW, you could have TASBot directly control the enemies for example and have them do trolly things they couldn't ordinarily do to react to the player. As long as the resources for the original SMB in SMW run are still available, this might be something that could be done pretty easily as well as be pretty funny to watch. There are probably lots of ways to do interactive things with TASBot (imagine a trolly anti-coop AI player 2 in Battletoads for example) but this is just something I thought might be plausible.
