Posts for Alyosha

Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3560)
Joined: 11/30/2014
Posts: 2744
Location: US
CasualPokePlayer wrote:
Oops, seems like the 12 cycle improvement was actually a 24 cycle improvement. I forgot to account that Gambatte's cycles are in double speed mode while GBHawk uses single speed mode cycles. Updated movie file: http://tasvideos.org/userfiles/info/64667814141526578
GBHawk counts single speed cycles, gambatte counts half speed cycles.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3560)
Joined: 11/30/2014
Posts: 2744
Location: US
phoenix1291 wrote:
I will (re)test PAL games and G7400 in next days. I have test several US games and it work great, even the voices in "Spike". Thanks for all your work Alyosha!
Don't bother testing G7400 yet, it's just WIP and the graphics pipeline isn't coded yet. I just roughed in the framework so I can work on it as I have the time. Also I don't believe there is an O2 version of chat et Souris (Mousing Cat in english.) What 'Spike'? I can only find a Vectrex version of that.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Chat et Souris is fixed, I misread the cpu spec and was dividing by the wrong number for the timer. Somehow no other game that used the timer cared about being off by a factor of 5, so I never noticed it.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3560)
Joined: 11/30/2014
Posts: 2744
Location: US
http://tasvideos.org/userfiles/info/64789886628663291 Probably last WIP before submission. I cleaned up some errors in the earlier worlds and finished world 4. Half way through world 5, still a lot to do there. EDIT: Actually on more with more optimal play in the final levels. http://tasvideos.org/userfiles/info/64903498664032186
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Nice work once again! Yes vote.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3560)
Joined: 11/30/2014
Posts: 2744
Location: US
http://tasvideos.org/userfiles/info/64683214002008391 Here is V3, about 200 frames faster then V2, with various time saves throughout. World 3 is done, as is most of world 4 except for Parrot Chute Panic where I still am about 2 seconds behind in the second half of the level. Not counting the 2 bios loading screens, I'm finally ahead of the Nico Video TAS by a couple seconds, getting close to a final product.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Congrats on a new job, and thanks for this report, it's certainly eye opening to see how things add up. ~$16000 total in 'tech stuff' in one year sounds like a lot considering TASBot has been around for a quite a while already. Do you project this level of equipment spending to continue?
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3560)
Joined: 11/30/2014
Posts: 2744
Location: US
So all this time that opening was hidden in plain sight! Yes vote.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3560)
Joined: 11/30/2014
Posts: 2744
Location: US
90 degree per frame is pretty fast, a back of the envelope calculation puts that at about 20 - 40x gravity. But limiting user input would be quite a big departure from standard practice. I think a human could do 1/3 of that (30 degree per frame.) I'm not sure what a robot or something could rotate at, but 90 degree per frame (or 700 RPM or so) doesn't sound impossible. Overall I'm not inclined to limit user input automatically. EDIT: Oh, but Blazephlozard is banned now I see. I'll still be doing physical testing on my own end, maybe starting next week, it would be nice to finalize this for stability.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3560)
Joined: 11/30/2014
Posts: 2744
Location: US
I was testing out the homebrew game Pong, and noticed it was failing the PAL console detection. Looking over the code it looked like just a timed loop in Vblank. In order to pass the time had to be significantly longer then nominal PAL vblank time. I think maybe PAL games just have the same resolution as NTSC games, meaning Vblank time goes from 240 to 312. That's a lot of time, so maybe that's why PAL games weren't working so well, since before I was only going from 288 to 312. I made this change in dev build, so please test some PAL games and let me know if there is any improvement. EDIT: also I'm going to be working on support for the G7400 as well.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Ok, range changed to 216. Fixed savestates, I was missing a variable, should be good to go now. The flicking part of the code is wrong, I'll fix it once the static cases are nailed down.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3560)
Joined: 11/30/2014
Posts: 2744
Location: US
PikachuMan wrote:
DS emulation controls are configured improperly. Windows does NOT have a Return key. It's Enter. We shouldn't have to plug a Mac keyboard into a PC.
Fixed in master.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Alright neutral value is changed to 0x8370 and range is increased to 220. I'm working on getting my own cart to test as well.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3560)
Joined: 11/30/2014
Posts: 2744
Location: US
The game reads raw accelerometer values from the cart like this:
			else if ((addr & 0xA0F0) == 0xA020)
			{
				return acc_x_low;
			}
			else if ((addr & 0xA0F0) == 0xA030)
			{
				return acc_x_high;
			}
			else if ((addr & 0xA0F0) == 0xA040)
			{
				return acc_y_low;
			}
			else if ((addr & 0xA0F0) == 0xA050)
			{
				return acc_y_high;
			}
The accelerometer values are short (16 bit values) The neutral values and ranges are hard coded into BizHawk in GBHawk's controller definitions. Neutral value is 0x81D0 and range is 125 (so at 90 tilt the accelerometer would read 0x81D0 - 125) Neutral value is probably variable between carts, I can change it without much issue. Range can also be changed, seems like right now it's not high enough, maybe it should be around 135?
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Roughly speaking, there should be a point where if you rotate fast enough to the left, kirby will still go to the right. (Or maybe it's the opposite.) I need to get an idea of how fast that is. It's important know how fast it is compared to realistic player movements.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Seems pretty definitive to me. I'll increase the range to 90. I also realized my acceleration calculation contain an error, so unfortunately I'll have to break sync after all. EDIT: for now I just increased the range to 90 for further evaluation. I think I'll have to do some physical testing to nail down the other error.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3560)
Joined: 11/30/2014
Posts: 2744
Location: US
I just checked the movie file and the frame before the power button is hit is still at 50000. The correct value seems to be 14199. here is an updated movie file: http://tasvideos.org/userfiles/info/64459518673915123 New cycle count: 317452060
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Alright TotalexecutedCycles now represents run time. I'm not the biggest fan of this since it's supposed to show CPU cycles (which can change with doublespeed mode), but it's only for SubGBHawk so I guess this will have to do.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3560)
Joined: 11/30/2014
Posts: 2744
Location: US
About how many degrees do you have to tilt your cart to get that acceleration? I can increase the range to 90, but I assumed that the game devs didn't want people to have to tilt the gameboy 90 degrees down and away from them to get the fastest speed. I can also increase the sensitivity.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3560)
Joined: 11/30/2014
Posts: 2744
Location: US
I fixed the TAStudio issue, please test to make sure there are no de-syncs or other problems.
dekutony wrote:
My concern about this is that if that's ok to do when I plan to submit this movie after I finish it. Didn't the rules say something about not using dev builds to make the TAS for submissions? Would it sync on a release build?
Given the complexity of this TAS I think it's safe to assume that there will be an official release before it's done. And yes it will sync on the release build since I'm done with emulation changes until next release (currently in testing mode.)
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Total execute cycles returns the number of cpu cycles since power on. The TAS contains a power cycle so it starts over from there. The cycle count in the bk2 is correct. I could make the lua function return this as well I suppose, but then it wouldn't match trace logger.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3560)
Joined: 11/30/2014
Posts: 2744
Location: US
In SubGBHawk you have to account for mis-alignments caused by turning the screen off. Try this one: http://tasvideos.org/userfiles/info/64410159364464147
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Blazephlozard wrote:
Alyosha wrote:
Please report problems with desyncs, and use the current dev build. Make sure you are all using the same version so it's definitely narrowed down to a TAStudio (i.e. savestate) problem and not just an emulation change.
Yeah, I was going to check out his WIP in the dev build and report anything if it was still there, cause I do want this game to work well. If I load his movie into tastudio in dev build, with no pre-existing savestates, and sync to the end of level 1, that would eliminate version diff / emulation change as the issue, right?
Yeah, and I don't think dev will change again in terms of emulation before the next release, so that should give you some stability.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Please report problems with desyncs, and use the current dev build. Make sure you are all using the same version so it's definitely narrowed down to a TAStudio (i.e. savestate) problem and not just an emulation change.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3560)
Joined: 11/30/2014
Posts: 2744
Location: US
What problems are you having with SubGBHawk? It doesn't make sense to optimize for cycles without optimizing the reset, that's where most of the savings are. For example here is a movie that hits reset at cycle 191340171 as opposed to this submission that hits at 191349960. http://tasvideos.org/userfiles/info/64408496504648552 Basically just keep reducing the number on the cycle input on the frame before power is pressed until you get the 'save destroyed' message.