Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
The game requires player 2 to select their car. If you don't want to use player 2, you still have to hit enter on player 2 controller to bypass their car selection.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
@ThunderAxe31: I'm not following. Is the glitch supposed to be there or not?
Making good progress so far. Right now all of the CPU, DMA, and timer tests from Gekkio's mooneye gb page pass, so I'm pretty confident the core is internally consistent and accurate up to this point. Background and sprites are working just need to do windowing and graphics will be initially done (though not in a cycle accurate way yet, that will be the next step.)
I have a couple bugs in some register bits and interrupt timing to work out, but those should be easy enough to work out so games should be fully playable (except for sound) pretty soon.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
This is a tough one. Highly entertaining runs are rare. We don't really have any fresh runs of the caliber of Brain Age or SMB 3 ACE. As a viewer I'd probably just tune out of any of the listed runs so far, (maybe except for Battletoads, but even that is more technically interesting then really entertaining.)
I don't know, I'm tempted to say just sit this one out rather then submit something mediocre. Maybe the time would be better spent searching out new ideas.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
So far so good. It's a good thing the Gambatte core already exists in BizHawk, it probably would have taken me 10x as long to debug some of these tests without it. instruction timing tests pass as well, so the basics of the CPU are functioning correctly. Next steps will be Memory access timing, Timer tests, and interrupt timing. Once those are done the core should be on a pretty firm footing to start on the more difficult stuff.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I'm making decent progress here. So far I'm doing everything in single clock steps, so breaking out into a debugger should be simple.
Trace logging works for the new CPU core, and I'm able to compare logs to gambatte. So far it makes it through the bios corectly (even though there is no rendering yet so there is nothing to see.) There is a couple of cycles of variation in timing the scanline counter, so it doesn't exactly match Gambatte, but all that stuff is still very preliminary (and the deviation doesn't show up until about 13000000 cycles in, so I guess it's pretty small.)
Savestates are already functioning as well, so all the basic foundations of the core are coming together. Next steps are to get rendering going. I have sprite evaluation and the timer done, just need to do all the actual rendering steps and start firing interrupts and such. Once that's in place I can start varifying the CPU and working through all the various test ROMs. I think rendering shouldn't be too bad, certainly the biggest hurdle will be the dreaded APU, but that's still a ways off.
Also I looked at Terrifying 911. At first I thought that was going to be some kind of murder mystery that starts off with a phone call to 911, but after googling it ... it's something else entirely 0_0
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
That's an amazing demonstration !
I had no idea you can do all that stuff with just LUA, that could become quite a powerful framework for longer 3D games. The tracking algortihm could always be improved, I think that's a small part of the puzzle compared to getting the rest of the infrastructure working.
I'll be watching progress on this with great interest, good luck!
So far so good. It's a good thing the Gambatte core already exists in BizHawk, it probably would have taken me 10x as long to debug some of these tests without it. instruction timing tests pass as well, so the basics of the CPU are functioning correctly. Next steps will be Memory access timing, Timer tests, and interrupt timing. Once those are done the core should be on a pretty firm footing to start on the more difficult stuff.