dreais / wfita Goto Github PK

would be best to implement some often used variables as the (actual) room, the player, the camera, the monster array, as one core_game variable contained in a whole structure

i don't have an explanation or even an idea for what's happening. to test:

1. run the game
2. move like 5 on the right, 5 on the bottom
3. press another key until enemies surround you
4. continues for some times, step by step
5. you get tp at 0;0

the program is currently doing the red path (sorry for clarity), instead of doing the "optimized" orange path. that'd reduce considerably paths' size

calling it once seems fine, but iterating over the monster array won't work and it keeps crashing. i have no clue of what's happening yet

Describe the solution you'd like
having a log file so that we can easily printf stuff in it, be it warning or info.

Describe alternatives you've considered
using the stat window to actively print debug value.
it's still a pain to call everytime 3 functions in order to simply have 1 value, getting overriden after another call though

as of now, the bare_hand does not deal damage. while it could make sense because the player currently use a shield, it should deal some

suggested resolution:
adding a strength factor (in charac_t). it was already planned, but better sooner than never

as per the first screen, we can get negative values for y which is bad news.

no idea on how to fix or what is even the fix for now though

map is taking a LOT of time to print, it's a bother to even move.
it may be caused by the init_colors(), not sure.

attron() may also reduce the framerate since the windows console is not optimal

Two issue there:

• we can see a lack of precision when fetching all points as per screen 1 shows
  
  screen 1

as we can see, we jump from (1;8) to (2;7).
this HAS to be fixed as this may lead to another major issue later on!

• maybe due to the previous one, the y coordinate from the diagonal may be out of scope (see screen 2)
  
  map is 10;8 long, this should not happen

we can determine the current position using this line:
current_direction[2] = {(int)copysign(1, dx), (int)copysign(1, dy)};

that makes it easier to iterate, less conditions to get the enum list as well

the idea would be to create a first path on the first iteration (when initializing monster).
we could then adjust at EACH turn the (potential) missing value(s), and adding it to the path with the append function.

this would avoid the whole recalculation and realloc every turn.

will still need this to be studied to see the cost

Describe the bug
when moving DOWN, the game may crash without reason.

To Reproduce

1. set a different resolution than 1920*1080
2. launch the game
3. keep KEY_DOWN pressed until the crash

self-explanatory; it is mandatory to have logs about action.

suggested:
having a special buffer of a given size (the maximum of the window) with a window would be ideal

typedef struct {
  WINDOW *logs;
  char **buffer;
  // maybe having the buffer size as well
  unsigned int buffer_size;
} g_logs;

having the size of the window within the struct is not necessary since we can just get them with getmaxx/y

tl;dr only keeping the seed when changing the room.

if we keep the seed of the previous maps when changing the floor, we could then recreate the map when visiting it again instead of just keeping the whole in memory. it could lead to major improvement when it comes to memory usage

this function could define what is the priority like get_order_position does

currently no hitbox is implemented between the monsters themselves.

should also add player's hitbox toward monsters

not a big bug but when we try to quit and get back in the game, 2 minors issue

1. it does not stop the game, resuming it will make enemies move.
2. the room is not being printed properly until players/monsters move for some lines/cols

i don't have a resolution nor a suggestion for now, since the print is AFTER the quit condition. i don't know why it happens

not a big priority since this is a late resolution

i currently define a lot of dx/dy variables. i did not expect to use them THAT much at first, so i didn't give it a thought but i could use them within the line_t point. that would make sense too since it's a property of the line.

the only "out of sense" idea would be that line_t is no longer a straight line, but a pool of points. nonetheless, we work with it as if it was a straight anyway

Describe the bug
cannot run the binary after building it. it crashes before printing anything

To Reproduce

make
./wFita

Expected behavior
the map to be printed

Suggested resolution
valgrind is addressing the issue to print_room.c:166

Desktop information
Ubuntu 18.04, using i3, on urxvt