Posts for bzb95

Experienced Forum User
Joined: 10/25/2009
Posts: 59
Synx wrote:
This could have been a total disaster for one simple reason. The PU stuff so often causes crash on console. That the team avoided abusing emulator to ignore such crashes was a brilliant decision. Well done on getting the TAS verified on console! Some day I hope the OoT community will follow the great example you guys have set with this TAS. As I have observed the trend in OoT speedrunning, I must admit I was skeptical when you, the authors were so secretive about this TAS in the Super Mario 64 Thread on the forum here. I feared it would be because the run would not play on console. I am happy to be proven wrong. Congratulations on this great run! MOAT DOOR HYPE!
Can you link a specific OoT TAS you'd expect to crash? I want to see if it crashes for the same reason as the SM64 crashes, now that they can be detected without a console.
Experienced Forum User
Joined: 10/25/2009
Posts: 59
ALAKTORN wrote:
Route ≠ optimization. Did Tyler make the final optimized one? I was talking about that. Edit: Also I still think snark found the final route. Tyler found the initial improvement, then snark improved upon it a little further IIRC.
Tyler found it, and optimized it to its current state. Maybe you wouldn't hate the 'west' so much if you actually gave them credit for anything.
ALAKTORN wrote:
What improvement do you mean?
The BitFS PU route.
ALAKTORN wrote:
The m64 to what?
You're the one who brought up that they are using the Japanese input with what you consider a unfair deal suggesting they didn't agree to it. As sonicpacker said above "due to us requesting their B2 fight input".
Experienced Forum User
Joined: 10/25/2009
Posts: 59
ALAKTORN wrote:
I think snark got to the finalized version first, but I’m not sure. I get the feeling you’re considering snark as part of the “0 star team”, but the teams here are Japan vs. the west, not “0 star” vs. whoever imaginary else.
No Tyler Kehne found the current route. It is comical that you think I'm the one who is confused about the teams, but I digress.
ALAKTORN wrote:
This is just wrong. The Japanese are still working on 120 Stars and never wanted to submit a run in the first place because it wasn’t optimized. The western community forced a run out of their ass in 2012 to get something published. Japan strives for perfection.
Huge difference here. The Japanese didn't want to release a run with a known improvement. The 0 star doesn't necessarily have known improvements rather things that still need to be tested. Remember these are the same people who took the BitFS improvement that they didn't find, wasn't optimal, and release in their own 0 star video 13 days later.
ALAKTORN wrote:
What arrangement? There isn’t any. Why do you think the SM64 Japanese TASing community hates us?
Really? How do you think they got the m64? It wasn't submitted to tasvideos, it isn't linked to on the video.
Experienced Forum User
Joined: 10/25/2009
Posts: 59
ALAKTORN wrote:
…What the hell are you saying? Literally every single statement in this post is wrong. How do you have so much misinformation all at once? Amazing. Never forget that packer is gonna upload the TAS to his channel and not share a penny with the Japanese TASers, again, btw.
Please humor me then, and explain where I am wrong. The BitFS improvement was originally upload on July 13, 2015 by MKDasher, and later that day tied by Snark. It took until March 3, 2016 to get the the current state. So only 7.5 months, but both the discovery and ultimately optimization were done by the current 0 star team. If the Japanese are so amazing wouldn't they have optimized it during this time?
Experienced Forum User
Joined: 10/25/2009
Posts: 59
ALAKTORN wrote:
Tfw the Japanese TASers would’ve submitted the TAS months ago if packer and friends collaborated with them.
What makes you think that? The BitFS improvement was publically released, and it took 8 months to get to the current version. On top of that the current best run was produced by the 0 star team. None of which suggests to me that the Japanese would have released an optimized 0 star TAS faster. The only reason to believe the Japanese would have released already. Is because the Japanese tend to release far more incremental improvements rather than trying to get everything perfect the first time.
Experienced Forum User
Joined: 10/25/2009
Posts: 59
Thats the issue I have with your branch, but its fixed in the newest master builds. Guess someone inadvertently fixed it, or forgot to close it.
Experienced Forum User
Joined: 10/25/2009
Posts: 59
Clicking wiimote on OSX crashes dolphin in your revision, but doesn't in the newest rev from dolphin-emu.org. Don't know if this is something that you/i caused, or if master was broke when you forked it. http://pastebin.com/ZsCtQw5F
Experienced Forum User
Joined: 10/25/2009
Posts: 59
RachelB wrote:
Hello. I am about ready to give up on IR though, it is far more complicated :/
Now you figured out why I didn't even put anything in the UI to control IR. While inconvenient to have to put your mouse back if you move it, it is already accurate. At least I think it is, never actually tested come to think of it. EDIT: And why on earth don't the crosshairs show up on windows?
Experienced Forum User
Joined: 10/25/2009
Posts: 59
I'm not too familiar with c in general much less the ins and outs of visual studios. Nor do I have a windows computer available to play around with it on. So the only suggestion I have is the obvious albeit line consuming idea of initializing them in the construction as WiiButtons[0] = ... etc. But with the halfway added wii support the code is still 500 lines shorter than the current implementation. So I cannot imagine anyone complaining about the extra lines. However I am sure there is probably a better way to initiate it. I just don't know it.
Experienced Forum User
Joined: 10/25/2009
Posts: 59
RachelB wrote:
The .h and .cpp were based on different revisions lol. This will be fun.
Not quite sure how I managed to do that, but below is an explanation of how to get it compiling if you haven't already, and what I think is left to do for the wii. To get the GC Input working/compiling again all that needs to be changed is 1. the includes statements at the top. 2. change SPADStatus to GCPadStatus, 3. and on line 674 of FrameTools.cpp add g_TASInputDlg->CreateGCLayout(); As far as the the wii input (IIRC) wm_core and wm_accel just need to be passed in and set to the values from the wii tas input. Oh, and of course you have to make the wii input actually pop up.
Experienced Forum User
Joined: 10/25/2009
Posts: 59
Here is a link with the two main files TASInputDlg.cpp/.h http://www.mediafire.com/download/852ac6dw1ar7u6t/Archive_2.zip For what ever reason it is no longer considered a git repository so I cannot create a patch. There are very few changes outside of these files though, but it doesn't currently compile due to all the changes in dolphin in the past year. Its not only begins implementing wii support, but also completely redid a lot of the code for the GC input. So the wii and GC could share the code. So when the code does get finished and committed GC input will need to be tested as well.
Experienced Forum User
Joined: 10/25/2009
Posts: 59
Who says its not done? Just messing with you. This pictures is from over a year ago, back when I didn't have a job or college to worry about. It was still too buggy to release when I stopped working on it. Plus at the time wii TASing wasn't stable enough to bother finishing it anyways.
Experienced Forum User
Joined: 10/25/2009
Posts: 59
rog wrote:
Yeah: http://tasvideos.org/DTM.html
Don't forget to also update http://code.google.com/p/dolphin-emu/wiki/TAS_Tasks also good work on dolphin so far. Keep it up.
Experienced Forum User
Joined: 10/25/2009
Posts: 59
I have now implemented this on my clone http://code.google.com/r/bradenb95-tas/source/list?name=TAS-Input , i will update this post with builds later tonight and will move the changes to the offical dolphin TAS-Input branch sometime. Edit:Sorry i will not actually be able to provide builds for a while, I had kind of forgotten that i an now on a Mac, which cannot make windows builds.
Experienced Forum User
Joined: 10/25/2009
Posts: 59
64 bit - http://www.mediafire.com/?q30id4iv6kpmfj9 32 bit - http://www.mediafire.com/download.php?pl3ycrvljnnnvf4 fixes crashes from
Unhandled Exception 
  Code: 0xC0000005 
Call stack info: 
     tasinputdlg.cpp(646) : TASInputDlg::UpdateFromText 
and
Unhandled Exception 
  Code: 0xC0000005 
Call stack info: 
     tasinputdlg.cpp(591) : TASInputDlg::UpdateFromText 
[\code]
Experienced Forum User
Joined: 10/25/2009
Posts: 59
MUGG wrote:
bzb95 wrote:
Will you try this build and let me know if it works? http://www.mediafire.com/?qy9p7tecbyywfr6
exceptioninfo.txt:

Unhandled Exception
  Code: 0xC0000005
Call stack info: 
     tasinputdlg.cpp(646) : TASInputDlg::UpdateFromText
     appbase.cpp(323) : wxAppConsole::HandleEvent
     event.cpp(1233) : wxEvtHandler::ProcessEventIfMatches
     event.cpp(907) : wxEventHashTable::HandleEvent
     event.cpp(1293) : wxEvtHandler::ProcessEvent
     wincmn.cpp(2661) : wxWindowBase::TryParent
     event.cpp(1306) : wxEvtHandler::ProcessEvent
     textctrl.cpp(2098) : wxTextCtrl::SendUpdateEvent
     textctrl.cpp(2137) : wxTextCtrl::MSWCommand
     window.cpp(4992) : wxWindow::HandleCommand
     window.cpp(2926) : wxWindow::MSWWindowProc
     dialog.cpp(494) : wxDialog::MSWWindowProc
     window.cpp(2618) : wxWndProc
well this should fix that problem but if it still crashes please post the code again mugg. http://www.mediafire.com/?9u5kyfui66nzd9k
Experienced Forum User
Joined: 10/25/2009
Posts: 59
MUGG wrote:
rog wrote:
Nope, they have not been merged to the main branch yet. 32 bit - http://www.mediafire.com/?xjm5zmuwqqush1z 64 bit - http://www.mediafire.com/?b25pr1fcaxoqtms
When I try to open the 32 bit version, nothing happens at all. exceptioninfo.txt:
Unhandled Exception
  Code: 0xC0000005
Call stack info: 
     tasinputdlg.cpp(591) : TASInputDlg::UpdateFromText
     appbase.cpp(323) : wxAppConsole::HandleEvent
     event.cpp(1233) : wxEvtHandler::ProcessEventIfMatches
     event.cpp(907) : wxEventHashTable::HandleEvent
     event.cpp(1293) : wxEvtHandler::ProcessEvent
     wincmn.cpp(2661) : wxWindowBase::TryParent
     event.cpp(1306) : wxEvtHandler::ProcessEvent
     textctrl.cpp(2098) : wxTextCtrl::SendUpdateEvent
     textctrl.cpp(2137) : wxTextCtrl::MSWCommand
     window.cpp(4992) : wxWindow::HandleCommand
     window.cpp(2926) : wxWindow::MSWWindowProc
     dialog.cpp(494) : wxDialog::MSWWindowProc
     window.cpp(2618) : wxWndProc

Unhandled Exception
  Code: 0xC0000005
Call stack info: 
     0x006F0079 : ?
     wincmn.cpp(411) : wxWindowBase::SendDestroyEvent
     window.cpp(3854) : wxWindow::HandleDestroy
     window.cpp(2661) : wxWindow::MSWWindowProc
     window.cpp(2618) : wxWndProc
Additionally, WerFault.exe shows up in taskmanager with a description that would translate to "windows problem report".
Will you try this build and let me know if it works? http://www.mediafire.com/?qy9p7tecbyywfr6
Experienced Forum User
Joined: 10/25/2009
Posts: 59
Here are links more updates if anyone wants it. Such as hotkeys working in render to main with the tas input and you can now right click to center sticks. 32 bit - http://www.mediafire.com/?xjm5zmuwqqush1z 64 bit - http://www.mediafire.com/?b25pr1fcaxoqtms code - http://code.google.com/p/dolphin-emu/source/detail?r=0a4cee2e429b3214e6de130335c9cd8056e4c1b5&name=TAS-Input
Toad King wrote:
AngerFist wrote:
sonicpacker wrote:
Input display is already built in, and bzb implemented rapidfire with the TAS input yesterday. He just hasn't released it to the public.
I am curious why he isn't part of team Dolphin. Instead of working by himself, he should officially join them.
Yes, he should get on Dolphin's IRC channel and show his patches so far and ask for commit access. At least when I joined, there were fairly lenient on giving people commit privileges.
Can you please explain to me how to make a patch on git? Because for me "create serial patch" does nothing.
antd wrote:
32bit crashes upon launch
Unhandled Exception
  Code: 0xC0000005
Call stack info: 
     tasinputdlg.cpp(425) : TASInputDlg::UpdateFromText
can you please try these new revs and post the code again if it still crashes?
Ilari wrote:
I have no idea what Dolphin calls "Frame".
A frame is every time the controller is polled. Which for dolphin is 60 times a second for any NTSC game. Even if it is a 30 fps game.
Experienced Forum User
Joined: 10/25/2009
Posts: 59
rog wrote:
bzb95 wrote:
rog wrote:
It seems that way. Still, something was fixed, so maybe it'll be easier to get it working fully now. Or even just working around it by running the different .dtm after loading the previous savestate would work as a temporary solution.
Its extremely easy to fix if i am correct. He just needs to not load the number of frames from the savestate and keep the ones that have already been loaded from the .dtm, but now that dolphin has switched to the new versioning system i am to lazy to try coding anything on it.
Hex editing the frame count in the first .dtm, save stating then recording more doesn't work. It still stops where the original did (where it ran out of input, it ignored the inflated frame count).
It should... Its getting the frame count from the savestate not the dtm(I think). It needs to be getting it from the dtm.
Experienced Forum User
Joined: 10/25/2009
Posts: 59
rog wrote:
It seems that way. Still, something was fixed, so maybe it'll be easier to get it working fully now. Or even just working around it by running the different .dtm after loading the previous savestate would work as a temporary solution.
Its extremely easy to fix if i am correct. He just needs to not load the number of frames from the savestate and keep the ones that have already been loaded from the .dtm, but now that dolphin has switched to the new versioning system i am to lazy to try coding anything on it.
Experienced Forum User
Joined: 10/25/2009
Posts: 59
I'm not looking at the source code right now but i'm pretty sure the issue is he is writing the number of frames to the .sav file . So then when you use that savestate it is getting the number of frames there were in the .dtm at the time of making the save and ending the playback based on that.
Experienced Forum User
Joined: 10/25/2009
Posts: 59
Toad King wrote:
I can work on this. Didn't know about this issue because somebody else implemented the read only option. What should the exact behavior be when a savestate is made/loaded in read-only mode?
Basicly in the LoadInput function of movie.cpp it needs a if/else statement to set the mode to movie_Playing if g_bReadOnly is checked but then you also need to make it continue reading input from the input frame on the dtm...which is where i am stumped so i hope you have better luck then me. Which you probably will.
Experienced Forum User
Joined: 10/25/2009
Posts: 59
True wrote:
bzb95 wrote:
I have a question what if this run was submitted before the other 0 star? It would have been accepted correct? I highly doubt if this run had came first that anybody would be arguing to replace a quicker run with a slower one because the camera angles are(supposedly) better.Then nobody who has actually tased sm64 is against this improvement, its retarded for a run to get rejected by idiots who have never played the game or are just to dumb to understand whats going on.
Ignorance is not idiocy or being dumb. Some people just don't care about SM64 to spend massive amounts of time learning how it works to watch a 5 minute superplay. I know I don't. Does that make me an idiot or dumb? If so, then you are too, because you don't know Somari inside and out. Some people played it as a kid and are just amazed to see it broken so quickly.
Yes if i go and vote no on are Somari movie that i know nothing about i'm an idiot, but i'm not going to do that because i accept that i know nothing about Somari and should stay out of its voting process. You cannot vote in the United States till your 18 for a reason. They don't want you voting on stuff you don't understand, same should apply here. Don't vote against a movie because you don't understand whats going on. It pure ignorance to vote against something for no reason other than being too dumb, or lazy to understanding whats going on.
Experienced Forum User
Joined: 10/25/2009
Posts: 59
I have a question what if this run was submitted before the other 0 star? It would have been accepted correct? I highly doubt if this run had came first that anybody would be arguing to replace a quicker run with a slower one because the camera angles are(supposedly) better.Then nobody who has actually tased sm64 is against this improvement, its retarded for a run to get rejected by idiots who have never played the game or are just to dumb to understand whats going on.
Experienced Forum User
Joined: 10/25/2009
Posts: 59
The gamecube and wii controllers get polled more than once a frame. So even though we still advance a video frame at a time with frame advance your button press(in some cases) will actually get written to the dtm 3 times. Due to the controller actually getting polled more than once a frame.