VC Control Stick Mapping

[Pheenoh]

I still need to play around with it some more, but as far as HESS goes -- that one was practically perfect.

[whyieyesya]

I still need to play around with it some more, but as far as HESS goes -- that one was practically perfect.

The one I have right now is much better in my opinion and the fix actually makes sense. The one I sent to you was just guessing some values and finding out what works. I'll upload the new one very soon, once I have tested it a little more, I don't want you to flash something that gives really weird issues like it did for me yesterday.

[whyieyesya]

Allright, I have tested and improved the last one, which I ended up taking offline. ESS region is pretty big on this one, and you don't have to hold the control stick as far as on the N64 version, it's almost like in OoT now. The older versions also suffered from being way more responsive when you held the analog stick diagonal. Basically this means that when you aim and you hold diagonal the response is way different from holding straight up, down, left or right. I account for this so that it doesn't react so heavily when you hold diagonal.

My thoughts on this version: ESS is really easy now probably and easier than on N64. Aiming is also pretty good, but it will never be as good as on N64, but a million times better than on VC. I fix a lot of stuff using an algorithm that checks how far the stick is away from its center and the value of the angle the stick is making, and sending different values to the Wii based on that. Because of this you might notice a little that when you aim your stick transitions from a certain state. It's not really that bad and it's still much better than on VC, as already said. I might look if I can have these transition zones a little more detail to them, so it's not noticeable at all anymore.

Here's a link to the newest .hex: https://dl.dropbox.com/u/23212729/N64_MM_FIX_LENGTH%2BANGLE_CHECK.hex

[ING-X]

ESS is really easy now probably and easier than on N64. Aiming is also pretty good, but it will never be as good as on N64, but a million times better than on VC.

I don't know if I like this. The whole point of the mod was to make the VC controls at least closer to N64 controls. If we end up making it easier than N64 controls then I would argue that it gives an unfair advantage.

[whyieyesya]

I don't know if I like this. The whole point of the mod was to make the VC controls at least closer to N64 controls. If we end up making it easier than N64 controls then I would argue that it gives an unfair advantage.

I suppose that's true. One of the reasons I made it easier, was because I am not very good at the angle change in MM, so it would be kinda hard to verify if it's working well. I am pretty sure I can make the ess region smaller again, but a lot of unpredictable stuff happened before, so I am kinda scared to make any claims. 

Edit: just tested it. If I change the settings so that Link will be in ess position when the stick has a distance from 16 till around 30 (these are approximately the values on N64) from its center I can still do the angle change fairly easy. Once again, I agree it's a bit fishy to make ess extremely easy. I'll wait untill Pheenoh has tested the most recent one I posted and if he likes it I'll let him try the one I just tried that is closer to the actual N64 version.

[Pheenoh]

Hi. Sorry, I was busy yesterday. I've been playing with this one for a few hours, and it feels a bit tighter than the one you removed, but it's still really easy to angle change. In regards to it being easier than N64, I can't really say. If it is easier, the difference is so small I can't tell.

[whyieyesya]

Allright, made the ess range more like on the N64 now and angle changing still no problem. Right now I am gonna try to make aiming better. Aiming will probably stay a little different from N64, but it's still beter than with GameCube controller.

ING, any chance you might still want to try to program yours? Your feedback would be pretty convenient. If you don't want to risk it, I fully understand though.

Thanks for the feedback so far by the way, Pheenoh.

[ING-X]

I'll try to program my adapter, but I can't make any promises on when I'll be able to do so.

[whyieyesya]

I'll try to program my adapter, but I can't make any promises on when I'll be able to do so.

If you need any help, just let me know. If I would have to build you an adapter first it would take much longer, because getting the PCBs fabricated would take a few weeks already (the one I show in the video that I built myself is very fragile, so I wouldn't want to send that to someone).

[Runnerguy2489]

I don't know if I like this. The whole point of the mod was to make the VC controls at least closer to N64 controls. If we end up making it easier than N64 controls then I would argue that it gives an unfair advantage.

Right, because having less lag is totally not an unfair advantage. 

[ING-X]

Right, because having less lag is totally not an unfair advantage. 

Well yeah, but with approximately 99.9999999999% of everyone using VC there really isn't much you can do.

[whyieyesya]

Allright, just confirmed with a memory editor that the mapping for MM isn't as simple as just translating the X- and Y-axis individually. When I have the value on the Y-axis on the Dolphin TAS plugin with Majora's Mask fixed and I start moving the X-axis the value for the Y-axis will increase. This is basically already what I thought the problem was. I might have a new approach of fixing this than I had before. It would be to gather a lot of GameCube X and Y-values and the corresponding X and Y-values for N64. If I would then calculate a function that (if this is possible) approaches the gathered data, it could become a really nice mapping. I think that when I have a lot of data from the ess positions, this should work very well hopefully. This will take some time, but I think it's the best solution if it works.

I want to step away from a mapping table, because with a mapping table I will have to hardcode some stuff to keep the ess-region. This is a pretty arbitrary process and I find it very hard to make aiming feel good when you hold your controller in ess position, or when you go from ess position to walk position.

Edit: just a quick update. Just did some thinking on this. If I would want to do it with a mapping table I would need to make one that is 70x70 bytes. This doesn't fit in the RAM from the chip, but it could possibly fit into the flash memory. Right now I am busy writing a program that retrieves all the memory data I need. With this a 100% correct mapping should be possible, if we ignore the N64 values that are lost in the conversion project, since the GC stick only uses about 40% of the possible values. I hope this works, cause in theory it would be perfect.

I also cancelled the pcb designing for the adapter for now, because it could change, if it were to turn out that it doesn't fit on the chip. In that case I would have to get a new chip. Sorry if this project is starting to take a little long, but I want to do this as good as possible.

[whyieyesya]

OK, I think I've got it. Here's a long story so people can see if it makes sense that I think I have fixed it:

Basically the N64 X and Y-value were dependent on both the GC X- and Y-value. This basically means that when, for example, you hold the Y-axis in position 30 on GC (which is 16 on N64) and you start moving over the X-axis, the N64 Y-value will change with it, even if your GC Y-value is still the same. What I did to fix this was make a lookup table of 70 times 70. In this table all GC-values are listed that correspond with the N64 value. I can use this really big lookup table for both the N64 X-axis and Y-axis, because the transformation to GC is symmetrical. The lookup table is 70 times 70, because this way it fits. Link will be running at full speed when you hold your N64-stick at value 70 anyways, and higher values just take the GC value at N64 place 70.

I got the mapping table by writing a program that would change the value of the GC analog stick in the Dolphin TAS plugin and then read out the N64 X and Y-values. When I got all this data a problem occured. A lot of N64 combinations don't exist. For example, combination N64 X=10 and Y=11 could very well not exist in the VC MM version. All the N64 combinations that did not exist were zero in the lookup table, so I somehow had to put in the best possible data in there. I wrote a little algorithm that checks which values are zero and then looks which N64 combinations do exist and chooses the one that lies close and has about the same angle.

After all this worked I tested it and aiming is super good now and the margin you have for superslides feels about the same as on my N64 PAL MM cart. Angle changing is also easily possible. I will check later if the region of ess is the same as on N64, by sending fixed GC analog stick values to my Wii and check when Link starts to turn.

The hex is here. Pheenoh, before you try this one, try the older one one last time and see if aiming when you hold your analog stick in ess position makes any sense and then try it with the new one.

[Pheenoh]

Yeah, the aiming feels alot less awkward now (it had good control on a small scale, but was pretty sensitive once you pushed the control stick all the way in one direction). HESS/angle changing and leniency on the diagonals feels close to the same (it's tighter than the one similar to OoT but still easily manageable). Are you gonna do a large mapping table for the OoT one too? I finally sat down and put in some time with one of the older mappings and realized the aiming was a bit strange, despite my first impression.

[whyieyesya]

Yeah, the aiming feels alot less awkward now (it had good control on a small scale, but was pretty sensitive once you pushed the control stick all the way in one direction). HESS/angle changing and leniency on the diagonals feels close to the same (it's tighter than the one similar to OoT but still easily manageable). Are you gonna do a large mapping table for the OoT one too? I finally sat down and put in some time with one of the older mappings and realized the aiming was a bit strange, despite my first impression.

I'll have a look if OoT acts the same as MM, meaning the X and Y-values are dependent. If this is the case then I'll do the same as for MM. I actually doubt that the X and Y-values are dependent in OoT, but we'll see. Only problem is that two big mapping tables won't fit on an Atmega8. This would mean the raphnet adapters wouldn't be able to use the best conversion possible, but of course the .hex file in my last post can be used. As for my own adapter that I'll hopefully will be producing any day soon, I'll just choose a chip with larger memory, since the extra costs aren't that high anyways.

Just confirmed it: X and Y-values are also dependent in OoT; if you have a fixed GC X-value and you start changing the GC Y-value, the N64 X-value will also change. It's a lot less worse than in MM though, but definitely something worth fixing. What the hell, I never expected this was the case for OoT too. Next update will probably be a new mapping table for OoT. It will not include MM since it won't fit.