Timeline for Collision Detection on floor tiles Isometric game
Current License: CC BY-SA 3.0
11 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Jun 1, 2014 at 18:25 | answer | added | Aholio | timeline score: 2 | |
Apr 12, 2014 at 4:33 | review | Close votes | |||
Apr 20, 2014 at 3:01 | |||||
Apr 8, 2014 at 17:05 | history | tweeted | twitter.com/#!/StackGameDev/status/453579414484566016 | ||
Dec 31, 2012 at 9:36 | review | Close votes | |||
Dec 31, 2012 at 16:06 | |||||
Oct 3, 2012 at 22:10 | comment | added | David Miler | Just a brief glance: have you tried switching up the X and Y coordinates in lets say levelTiles[(int) pos2.x][(int) pos2.y] ? | |
Nov 26, 2011 at 15:32 | comment | added | Mike Cluck |
I understand that. But you're measuring moveX and moveY then if there is no collision at pos2 , move using moveX and moveY . Why not just use that measurement since that actually represents your next position? I guess I don't understand why you're making two different measurements for the same possible position.
|
|
Nov 25, 2011 at 2:37 | comment | added | Anivrom | Well the whole point is not to update the players position if the future position (exaggerated by a multiple of 6 and returned as pos2) is going to end up on a collidable tile. the problem is its not returning the proper values. I'll have to add some screenshots with value overlays | |
Nov 24, 2011 at 18:41 | comment | added | Mike Cluck | Well, it's not a full scale answer but it looks like you're only updating the characters position if in fact there is no collision. However, you've already calculated the characters new position before this. It seems like the testX and testY are moot and you would just want to check with your characters hypothetical new position, since it seems to be producing the proper coordinates being that it's moving properly. Unless of course I'm missing something vital in your code. | |
Nov 23, 2011 at 23:16 | comment | added | Anivrom | Yes every direction. For instance: if the character is moving down we shouldnt be looking ahead on the X axis (running left to right) but the Y should be looking ahead moveY * 6, but its applying moveY * 6 to X instead of Y. I tried feeding moveX to Y and moveY to X, and that returns the right tile numbers as far as looking ahead goes,which shouldnt be the case, but it also produces incorrect collision detection moving diagonally. It puzzles me that my code for actually making the character walk in the direction they are looking works perfectly. but when I try and look ahead, it fails | |
Nov 23, 2011 at 21:50 | comment | added | Mike Cluck | Does it occur only when moving left or does this consistently happen for all directions? | |
Nov 23, 2011 at 18:39 | history | asked | Anivrom | CC BY-SA 3.0 |