Object coordinates now have more precision#1014
Conversation
|
Maybe we should get rid of the direct access to the pos->x and pos->y everywhere we can. Also a macro like FPx(32) that would multiply by 256 to get the fpv value might be nice? |
| int dir[2] = {OBJECT_FACE_RIGHT, OBJECT_FACE_LEFT}; | ||
| pos[0] = vec2i_create(HAR1_START_POS, ARENA_FLOOR); | ||
| pos[1] = vec2i_create(HAR2_START_POS, ARENA_FLOOR); | ||
| pos[0] = vec2i_create(HAR1_START_POS / 256, ARENA_FLOOR / 256); |
There was a problem hiding this comment.
I feel like the 2i should hold the full pseudo float, and we have functions that divide by 256 to get the pixel coordinate when we need it
There was a problem hiding this comment.
Agree, the current issue is I've left the spawn functions untouched in the way they handle pos in order not to break UI, so coordinates are expected in pixel space for now
There was a problem hiding this comment.
I think we should do it all the right way and fix what breaks. I can assist if you want.
|
How do we get this moving again? |
| int object_fpx(const object *obj); | ||
| int object_px(const object *obj); | ||
| int object_fpy(const object *obj); | ||
| int object_py(const object *obj); | ||
| float object_vx(const object *obj); | ||
| float object_vy(const object *obj); | ||
|
|
||
| void object_set_fpx(object *obj, int val); | ||
| void object_set_px(object *obj, int val); | ||
| void object_set_fpy(object *obj, int val); | ||
| void object_set_py(object *obj, int val); | ||
| void object_set_vx(object *obj, float val); | ||
| void object_set_vy(object *obj, float val); |
There was a problem hiding this comment.
please add a comment or comments to explain what distinguishes the many similarly named functions here.
|
Is it unreasonable to hope that all |
|
I'm just busy with other things is all, haven't had the chance to make necessary changes to the spawn calls
Yes it absolutely should be a vec2i |
I would definitely like to minimize our use of floating point math wherever possible. Luckily the way velocity is done should be relatively safe from the perspective of accumulating floating point error (although I do think we should consider switching that to a pseudo float as well). |
Switching to integer math would certainly be better from portability side also. |
| #define ARENA_FLOOR 190 | ||
| #define ARENA_LEFT_WALL 5120 | ||
| #define ARENA_RIGHT_WALL 76800 | ||
| #define ARENA_FLOOR 48640 |
There was a problem hiding this comment.
Instead of rolling magic values, could these instead be the operation ? e.g.
#define ARENA_LEFT_WALL (20 * 256)
Compiler will probably optimize that anyway, and it would be much clearer on what these values are.
There was a problem hiding this comment.
That's why I suggested a macro so we could do something like #define ARENA_FLOOR PSEUDOFLOAT(190)
|
Closed in favor of #1044 |
5 participants
fpos gives more precise coordinates while existing pos methods retain their original behavior
Methods and new equivalents
object_get_pos -> object_get_fpos
object_set_pos -> object_set_fpos
object_px -> object_fpx
object_py -> object_fpy
object_set_px -> object_set_fpx
object_set_py -> object_set_fpy
Planes in the desert are broken but everything else seems ok so far?
Most of the code actually references obj->pos directly without using one of these functions which was a bit annoying
Low agility pilots should appear to move faster now