✅ Console FPS Player Direction
I am making a math error in the following code: https://gist.github.com/ZacharyPatten/e071bfefd00f82c8ad719e53fb561d5a
NOTE: this is a fork/reimplementation of: https://github.com/OneLoneCoder/CommandLineFPS/blob/master/CommandLineFPS.cppThe code is mostly working, however, something is off and I haven't quite spotted it yet. When you hold the
'A' key, you are supposed to be turning left, however, the player icon in the minimap (< ^ > v) are rotating clockwise instead of counterclockwise (inversed). The same is true for holding the 'D' key as the icons rotate clockwise instead of counterclockwise. However the direction in the minimap appears to be accurate because the 'W' key always moves you in the direction you are facing.
I'm wondering if this was a bug in the original code or something I added when I translated it from C++ to C#. 🤔 The original code just had a "P" in the minimap (not < ^ > v) for the player; it did not include player direction in the minimap.34 Replies
@AdmSnyder 😛
first, this should be a constant:
(float)Math.PI * 2 😛
also, you shouldn't need to mod 2PI there because you already had those while loops.whoops I did the mod first and forgot to remove after adding the loops
but i don't see a math error there
code updated
and i suppose you can rule out overshooting because auf renderspeed
just updated the gist
I'm mainly concerned with whatever is going on with the clockwise/counterclockwise inversion on the minimap. I'm not exactly sure what is happening yet
we are talking about line 225ff, right?
yeah... but I don't think it is with that section of the code
something is inverted somewhere
no, that one looks good
im just not sure where the inversion is
try putting an x into the coordinates projected from the angle maybe
so we see where it's actually heading
the inversion is that y coords grow downwards?
whereas cos is going upwards
what's you system of reference, is α=0 pointing down?
yes
and growing goes counter-clockwise
well that is what has me stumped.
as "a" grows the minimap looks like you are turning left but the world view looks like you are turning right
I can't tell if I jsut inverted the world view or not
something seems like it is inverted
can i extemporaneously say that having
if (OperatingSystem.IsWindows())
inside Update() is kinda weird
it's not like the os changes while the game is playing
if i read wellI don't think it is very weird personally. I only want to call
user32.dll if we are on windows, other wise it will need to use different code to resolve it
the code will break on other OS's if it tries to call user32.dll without the if checkyeah but you don't need to check that every cycle 😐
like, once the game is started the condition should be settled
I believe it is optimized by JIT
so it won't check every cycle
For example: https://github.com/dotnet/runtime/blob/bf7fb2ecbf69deb6a73bb8bbca1e56e7beec8d8a/src/libraries/Common/src/System/IO/PathInternal.CaseSensitivity.cs#L27 there is jus tone use case in the BCL
it is used a lot if the BCL
sure, and i use it too, i just find it weird that it's not assigned to a readonly variable or something, even if it returns a constant
anyway
this
what is this doing
when rayAngle is 0 and grows sin goes to 1 and cos goes to 0
this seems important for the matter
because it seems to be clockwise oriented?
but i really have to go sleep now
no worries thanks for looking
my code is a fork of this code (but I translated it to C# rather than C++ and changed some stuff)
https://www.youtube.com/watch?v=xW8skO7MFYw
https://github.com/OneLoneCoder/CommandLineFPS/blob/master/CommandLineFPS.cpp
but the
eyeX and eyeY was from the original code. I'm still wrapping my head around the math a bityou can draw x=cos(α), y=cos(α) and see how it behaves
it takes just what 4 lines of code
yeah I have already tried several inversions but I havent' found the magic combination yet
swapping the
x=cos(α), y=cos(α)does seem like it fixes one thing but then the world view and movement angles are wrong so probably more than 4 linies of code that need adjusted
What if you just swap the conditions on the
switch at l.340 for displaying > and < ?unfortunately not that simple
it's not a bug, the math checks out, the problem is the representation of the minimap imo, you might need to invert it
also, if i understood correctly you are basing the minimap on the map, maybe keeping separate maps is better, and updating the minimap as needed based on the position and the calculated a, and the minimap representation will be based on where you are facing, so it will be different in relation to the actual map
very cool project btw
why doing random changes 😐
try to understand the code
Why not? It seemed like that fixes things 
when you press
'W' or 'S' you are currently moving in the minimap the correct direction. if I flip around the <, v, > and ^ characters rendered in the minimap, then when you press 'W' you no longer move in the direction the icon is facing
it is likely possible that those characters need to be inverted, but they are not the only thing that needs to be invertedI'd assume you only have to switch around > and <
you are welcome to try it, but as mentioned that only fixes the minimap rotation. then there are more issues where the direction you move doesn't line up with the direction you are facign in the minimap.
There is something else that is inverted
Ah yeah, I only focussed on the minimap rotation first. I haven't found anything else so far
thanks for looking 🙂
and yeah it is proving a bit challenging to figure out exactly what is happening.
I was able to fix it... I had to invert most of the X-axis indexing of the
string[] map. still wrapping my head around it but it is working
haven't updated the code at the link yet