Click here to Skip to main content
15,039,214 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
I am making a snake game on my own and it seemed that no matter what I did there were errors. So I googled some stuff and got a decent looking setter board function thing. But the problem is it doesn't print anything to the screen.Is there something wrong with my terminal that can be fixed or added? Here is the Setboard function.
C++
void Setboard()
{
    int x,y;

    gameover = false;
    score = 0;
    getmaxyx(stdscr, y, x);
    x -= 18;
    for(int i = y; i > 0; i--){
        mvprintw(y, x,"%c",'|');
        refresh();
        wrefresh(stdscr);
    }
    mvwprintw(stdscr, y / 2, x + 1, "Quit Game ctrl + c");
    refresh();
    wrefresh(stdscr);
    fruitx = rand() % x + 1;
    fruity = rand() % y + 1;

    headx = x / 2;
    heady = y / 2;
    
    while(headx == fruitx && heady == fruity){
        fruitx = rand() % x + 1;
        fruity = rand() % y + 1;
    }

    mvwaddch(stdscr, fruity, fruitx, '*');
    mvwaddch(stdscr, heady, heady, 'O');
    refresh();
    wrefresh(stdscr);
    taily = heady;
    tailx = headx;
    prevy = heady;
    prevx = headx;    
    refresh();
    wrefresh(stdscr);


}


of course I have a seprate file calling this function. I also have a statement printing hello world to the screen to make sure the file is working(int main.)(This is all in ncurses).

What I have tried:

I have tried googling solutions and looking at ncurses tutorials but nothing really showed anything usful to fix this problem. The main thing is i am trying not to look at any building snake game tutorials(If more code or description needed tell me).
Posted
Updated 2-Jun-21 17:43pm
v3

Additional to what Patrice has said, debugging ncurses has its own set of challenges. If your IDE can't handle running and debugging a program that uses ncurses, or if you are using a text editor (e.g vi, nano, etc), its nearly impossible to run gdb in a terminal to debug a program that's going to do curses things to the terminal window.

The solution is to use 2 terminal windows. The first we will be using to display the program output. Here you do
$ tty
/dev/pts/0
$ sleep 10000
This tells us that this terimanl screen is using /dev/pts/0 as its tty port, and we then sleep for 10,000 seconds - about 2:45 hours - which should be plenty of time to run several debugging sessions. In the other we do
$gdb myprog
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2
(gdb)tty /dev/pts/0
(gdb)b Setboard
(gdb)run
Here we've started gdb and told it to use /dev/pts/0 as the input/output for the program we're running. This means that all the curses I/O will happen in terminal 1. Since terminal one is executing sleep 10000, any key presses will be read by the program running under gdb on the other terminal.
Alternatively, if you're comfortable with emacs you only need one terminal and do
$ echo $TERM
xterm-256color
$ tty
/dev/pts/0
$emacs -f gdb
This will start an emacs session, and will prompt you for the name of the program to debug. When you get the emacs gdb buffer, you can tell gdb to use /dev/pts/0 for program in the same way as before. You might also need to do set env TERM xterm-256color to get the proper terminal sequences (adjust as per the result of the $TERM variable).
   
Quote:
I have tried googling solutions and looking at ncurses tutorials but nothing really showed anything usful to fix this problem.

Trying random things in hope encounter with a solution is about the worst thing to do. You need to understand exactly what you code is really doing. The debugger is the tool if choice to see what going on under the hood.

Your code do not behave the way you expect, or you don't understand why !

There is an almost universal solution: Run your code on debugger step by step, inspect variables.
The debugger is here to show you what your code is doing and your task is to compare with what it should do.
There is no magic in the debugger, it don't know what your code is supposed to do, it don't find bugs, it just help you to by showing you what is going on. When the code don't do what is expected, you are close to a bug.
To see what your code is doing: Just set a breakpoint and see your code performing, the debugger allow you to execute lines 1 by 1 and to inspect variables as it execute.

Debugger - Wikipedia, the free encyclopedia[^]

Mastering Debugging in Visual Studio 2010 - A Beginner's Guide[^]
Basic Debugging with Visual Studio 2010 - YouTube[^]

1.11 — Debugging your program (stepping and breakpoints) | Learn C++[^]

The debugger is here to only show you what your code is doing and your task is to compare with what it should do.
   

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
Top Experts
Last 24hrsThis month



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900