Goemons Great Adventure - Inconsistent collision

[Krusher97]

Webm : https://drive.google.com/open?id=0B1sugCZh1a3ZYVJBUDM2UE5WRms It seems to be really hard to grab these bars consistently. I managed to do it once but haven't been able to do it since. If you slow down the webm you can see the character straight up passing through the bar without grabbing them. Doing these jumps consistently is way easier in PJ64.

[loganmc10]

Is this new? Like do older builds of mupen64plus have this issue? Also, can you provide a save state or save game where I can quickly get to these bars to perform some regression testing?

[Krusher97]

The bars are in the first level. I didn't test the game in older builds and I don't know where to get them. Here is a save state : Goemon's Great Adventure (U) [!].zip

[loganmc10]

I just did the bars twice (using my keyboard), I had no issues catching all the bars and reaching the higher plateau. Do you have any settings non-default like CountPerOp? Did you do this using GLideN64 or Angrylion?

[Krusher97]

Did it using GlideN64, all default settings and an Xinput controller. Could you post a video of you doing it? I want to compare it with mine.

[loganmc10]

Here you go:

https://drive.google.com/file/d/0B8iAuv3fmhb_b1V2Wmw5YW9sanc/view?usp=sharing

[loganmc10]

That was using my keyboard, english version

[Krusher97]

Yeah its super easy to do with a keyboard. On the control there seems to be only a specific point where it'll register the grab and the same input/trajectory which works on PJ64 doesn't work in M64p

[loganmc10]

huh I grabbed my controller and I experience the same thing. It's like it deregisters the A button press.

I'm assuming you keep A held from pole to pole, can you try this: When you're mid air, let go of A and re-press it before you get to the next pole, does that help? It seems to work for me

[loganmc10]

It only seems to be a problem when I use the analog stick to control Goemon, if I use the d-pad, no problem, is it the same for you?

[Krusher97]

Yeah the problem is only with the analog stick. Also you don't need to hold anything for the player to grab the bars. He should do it automatically.

[loganmc10]

I need to find an N64 controller expert, or find some documentation.

Here is the problem: The N64 controller's axis limit is from -80 to 80 in both the X and Y direction.

So if you're extended all the way right, you're at +80 on the X axis for instance. When we emulate the analog stick using the keyboard, if you push Right+Up, you're at 80 in both directions. However, when using a real analog stick, if you push Right+Up, its more like 60,60, since neither axis is actually fully extended.

In this game when you use the D-Pad it seems to act more like the 80,80 situation. I need to find out what values a real N64 controller would have if it was extended all the way to a corner

[richard42]

I did exactly that, and fit a quadratic curve to the maximum values, and wrote that into that axis limiting function in the input plugin. I only tested with one controller though, and I'm sure there is variation between controllers. Even this turned out to cause problems because the maximum values right on the X and Y axis were not all the way to +/-80, and it caused issues in some games. But allowing the axes to go full +/-80 even in the corners (the old, inaccurate behavior) caused problems in other games.

[loganmc10]

I'm curious what the behavior is like on a real N64 with this game, basically it seems like Goemon can swing farther when using the dpad (or when the analog stick is being emulated inaccurately by the keyboard), rather than the analog stick. I wonder if the same thing happens on real hardware

[loganmc10]

So it does seem like something is wrong, I asked someone with a real N64 to test and this is what they said:

I just tested this on my authentic cartridge... And no, they are the same. I saw or felt no difference between the d pad and joystick. Both need to be angled up and right to go to the next bar and traveled the same distance.

https://www.reddit.com/r/n64/comments/76yq9s/need_someone_to_test_goemons_great_adventure/doidkps/

[loganmc10]

I tested this on Mupen64plus AE. It's not quite as bad there, it was easier to grab the poles using the analog stick (tested using a Shield Controller). However, you still get way more height using the dpad. I'm hoping more people can test a real N64, but from the feedback I received so far it sounds like there should be no difference

[loganmc10]

@richard42 basically this issue is caused by the ApplyAxisLimits function. If I disable that function, then the axis values can reach 80/80 in the corners, which allows the character to behave the same using the dpad or the analog stick. The ApplyAxisLimits function limits the range in the corners to roughly 60 (on my controller the corner comes in at 57/57), which limits the distance the character can jump

[richard42]

That's kind of a conundrum then, because removing this function will cause problems with other games, as it will allow the emulator to produce joystick positions which are not possible on an N64 with the Nintendo controller.

[loganmc10]

Is it possible it's just a bit too restrictive? On my controller it limits the corner to 57/57, maybe that is too low? I bet if it just went to 65-70 the jump would probably be much closer to the dpad

[richard42]

You can extend this maximum value by increasing the number 1.000f in the "float fMaxRadius = ..." calculation in that function. I tried looking through issues and google group messages to find out which games were fixed by this function, but I couldn't find the info. It would also be nice if someone else with a real N64 controller (different one from mine, obviously) could use the joymodel.c program in the "tools" folder of the core to model another controller.

[loganmc10]

Just one more piece of feedback I received:

I find it equally easy on both stick and d pad. Just get him spinning and hold up-right and then hold jump. When he catches the next one, don't release up-right. When he starts spinning hold jump again.

https://www.reddit.com/r/n64/comments/76yq9s/need_someone_to_test_goemons_great_adventure/dokylk4/

[bsmiles32]

Did a quick test with 2 controllers a "black" one which is somewhat recent, and a "gray" one which is more older with a loose joystick. I modified the core to print the joystick values and I got this: (Up, UpRight, Right, DownRight, Down, DownLeft, Left, UpLeft) black with raphnet : (0,82), (64,71), (78,0), (64,-69), (0,-81), (-66,-70), (-78,0), (-65,72) black with sdl : (0,80), (52,59), (79,0), (52,-59), (0,-79), (-49,-60), (-80,0), (-54,58) gray with raphnet : (0,73), (60,62), (75,0), (64,-67), (0,-82), (-63,-66), (-73,0), (-59,64) gray with sdl : (0,80), (55,57), (79,0), (51,-59), (0,-79), (-46,-62), (-80,0), (-55,57)

And here are some joymodel results (2 tries with black controller):

And 2 tries with gray controller :

[loganmc10]

Awesome thanks for testing! @richard42 it does seem like based on @bsmiles32 test that the controllers get better range in the corners than SDL is currently providing

[richard42]

the diagrams for the grey controller look similar to what I saw with mine. Is that black controller a Nintendo device, or a 3rd-party controller?

[richard42]

I just pushed a commit which removed the axis limiting function. If the over-excursion in the corners causes problems with some games then we'll probably hear about it, and have to go back and find a happy medium. I did find a minor error in the implementation which resulted in the coordinates being limited too much, but I wasn't all that happy with the shape of the curves either. I might do it slightly differently if it becomes necessary.

[bsmiles32]

@richard42 The black controller is a genuine Nintendo device.

[bsmiles32]

@richard42 If I remember correctly (can't find the report now), the axis limiting function was added after a user complained that he couldn't, given the high sensitivity of the joystick, move precisely in OoT (maybe it was to get the hammer in the fire temple ?). And he was able to get it after you implemented that axis-limiting function. So I think it is usefull, just not well configured yet.