Experienced Forum User, Published Author, Player
(157)
Joined: 9/1/2014
Posts: 235
Location: Italy
TASeditor wrote:
Can someone provide me memory addresses of the player and camera struct (positions, speed, acceleration, etc.)?
The ones I found have only basic stuff.
I tested my input script and the angles seem very unprecise. In the script are many more things wrong, don't use it.
See here: https://youtu.be/mMqwVekr0Ak The lines are twitching to much and I don't know if there're special conditions for the control stick for this game that would make an optimal solution of my script unoptimal.
Experienced Forum User, Published Author, Player
(157)
Joined: 9/1/2014
Posts: 235
Location: Italy
Tyler Kehne wrote:
I think it's kind of weird that console timing isn't in the conversation for being the standard. Like, it doesn't get any more accurate than that. I understand there are issues with determining the start point, but that seems minor compared to the inaccuracies of RDP emulation.
Like mkdasher said, the 1 Key TAS was optimized for console, not any particular emulator. A notable example was BitFS, which didn't lag at all (IIRC) on Mupen but had a lot of lag on console, particularly when Mario was around the elevator. We had to scrap a really cool POV where we got the camera stuck in the elevator so you could see Mario's entire BLJ, because it introduced additional lag. The movement was redone several times, and the movement + camera you see in the run yielded the least lag on console. I think DDD fixed cam also reduced lag.
Console timing would be what I'd go for but I already assumed TASVideos Staff wouldn't accept it LOL
Experienced Forum User, Published Author, Player
(157)
Joined: 9/1/2014
Posts: 235
Location: Italy
Mothrayas wrote:
adelikat proposed an alternative compromise: the movie is still submitted as a BK2 file, but the displayed time will be changed to reflect that of the equivalent M64 file.
Would this work for you? This would solve the SM64 community's gripe with the BK2 reporting an off time, while publishers can still encode and publish in BizHawk.
That's fine by me. Please don't get me involved with having to do stuff like writing for publication etc
Experienced Forum User, Published Author, Player
(157)
Joined: 9/1/2014
Posts: 235
Location: Italy
OmnipotentEntity wrote:
Plush wrote:
Nah thanks, you just answered =)
I'm just popping in to point out that completely ignoring the part where it took a long time is actually a bit disrespectful to the person who did the encodes. Their time is also donated to the site, and they tend to get fewer accolades than the runners, but tend to spend as long, if not longer, contributing to the site overall.
I've been a reasonably minor figure on both sides of the player/publisher divide, and I can assure you that encoding with Mupen has been a pain that I've had the displeasure of experiencing. Please don't minimize the actual problems that it represents.
And, I understand that you think you've rhetorically outwitted Mothrayas here. But as far as I have seen in this thread, he's been as or more polite to you than anyone else. Please return that courtesy. We all have similar goals here.
natt is in the thread, why not open a dialog and try to help him, if he's willing? If emulator accuracy is the problem for you accepting BizHawk, wouldn't that be the most reasonable thing to do? I'm sure you have more than a few test cases that might be useful. It might not be as easy as trying to bully staff into accepting an improvement, but I think we both can agree it's more useful and sustainable.
Legit sorry if that sounded disrespectful. I said that simply because I had nothing else to say: I realize how tough it must be to encode with Mupen so I'd just say it's better not to publish at all (which is the thing I've been saying the whole time)
Experienced Forum User, Published Author, Player
(157)
Joined: 9/1/2014
Posts: 235
Location: Italy
Mothrayas wrote:
Plush wrote:
What was not fine in the encoding of the 120 star TAS, for example?
You mean the one by our publishers, or something else? Did anyone else make downloadable encodes for that TAS?
If the former, nothing wrong with it - just that it took a month or two of a publisher's time. If the latter, what are you referring to exactly?
Experienced Forum User, Published Author, Player
(157)
Joined: 9/1/2014
Posts: 235
Location: Italy
natt wrote:
Non5en5e wrote:
natt wrote:
Swordless Link wrote:
The solution is obvious. The "BizHawk or bust" rule is a failure, and people who actually TAS N64 games clearly dislike it. Allow Mupen (even if BizHawk is still preferred), or risk not getting new N64 runs on your site. Easy.
Does that mean you'll go away forever? Because that sounds awesome!
What a very logic and polite way to challenge somebody else's position...
There's no challenge. The goals of the TASVideos community and the SM64 community are not compatible. I agree with the position; SM64 speedrunners should stop submitting movies to TASVideos and TASVideos should stop publishing them.
Aside from the not-so-mature comment, I totally agree with your last thoughts about this situation. Sorry for the troublesome conversation =)
Experienced Forum User, Published Author, Player
(157)
Joined: 9/1/2014
Posts: 235
Location: Italy
OmnipotentEntity wrote:
Plush wrote:
Mupen64 objectively HAS better accuracy than Biz, since it's much closer to final time.
Just because the time is closer, doesn't necessarily mean that the emulation is more accurate. There are a lot of moving parts in an emulator.
For instance, if an emulator has two emulation errors, one that causes it to gain a frame, one that causes the loss of a frame, the overall time is exactly the same. However, if a second emulator merely has the second error, then it will be a frame faster. But you'd presumably agree with me that the second emulator is objectively the more accurate emulator, despite having a different time.
Actually very good point, but that's not the case here. Mupen's inaccuracy is mostly given from its framerate (30FPS). If you divide the VI counter by the n64 framerate, you get an actual close time. On the other hand, in Bizhawk, the framerate is a bit more accurate (closer to true framerate instead of 30), while the lag is completely messed up. Not sure how you can say that is "better emulation".
Tl;dr Mupen nearly got it except for framerate. Just divide by true framerate and you get the correct time. Bizhawk lags where it shouldn't.
Experienced Forum User, Published Author, Player
(157)
Joined: 9/1/2014
Posts: 235
Location: Italy
OmnipotentEntity wrote:
Plush, you do good work. But there's a number of very good reasons for the migration from Mupen. I understand it's the standard for Mario 64 TASers. But it's not really being maintained anymore, and the timing, while slightly better in an absolute scale, is far too generous, and results in a better time than possible on console. BizHawk is undeniably a more accurate emulator overall. And it's much easier for other people, like judges, encoders, and publishers, to work with.
No one is saying you can't continue to personally use Mupen, or that you can't continue to use it as a benchmark for your old files. Just that if you'd like to submit the file as a movie it needs to be in the BizHawk format.
I know there's a lot of drama in the SM64 TAS community. Like... all of the time. But this, at least, isn't personal. It's simply applying uniform standards, to try to make the site a better place.
Thanks for an actual nice, quiet post, those are pretty rare here =)
What you might be missing is that BizHawk's accuracy is lacking in SM64. Mupen64 objectively HAS better accuracy than Biz, since it's much closer to final time. BizHawk is a very good emulator, don't get me wrong. It has support to many many consoles with amazing accuracy. Here that's just not the case.
Experienced Forum User, Published Author, Player
(157)
Joined: 9/1/2014
Posts: 235
Location: Italy
Can you be more clear? Why should it be converted to BK2 except "hurr durr you said so months ago" (I didn't)?
And also I care if you use a literally bad timing when a better one is available.
If you can't follow this simple task, then just don't publish it.
Experienced Forum User, Published Author, Player
(157)
Joined: 9/1/2014
Posts: 235
Location: Italy
Sorry, but I explicitely refuse to that. There's literally no reason why it should be converted to BK2 since it results in an even more inaccurate time (Read sp's post again)
Experienced Forum User, Published Author, Player
(157)
Joined: 9/1/2014
Posts: 235
Location: Italy
I think your assembly for 4 bytes big endian is bad, can it show signed values if you right click -> “Show as signed”? If it can then I guess it’s fine. If it can’t I got mine from here and it can: http://tasvideos.org/forum/viewtopic.php?p=292784&b=28#292784
Your 2 bytes big endian has that problem, and the one in the post I linked is even more broken (when doing scans it won’t show correct values if they’re too high). Does anybody know how to fix the problem with showing signed values for 2 bytes big endian?
Also, I asked on the CE forums and they told me a different workaround for Win 10: http://forum.cheatengine.org/viewtopic.php?t=603753
“after enabling kernelmode read/write, also execute this lua command:
dbk_writesIgnoreWriteProtection(true)”
It works nicely for me, I haven’t tried your workaround though.
^
This post is by ALAKTORN btw
