Results 1 to 10 of 15
I have some ideas about writing a small game in terminal ( just for fun ) using ncurses library. I want to use some kind of menus (in Midnight Commander's ...
- 04-06-2010 #1Linux Newbie
- Join Date
- Apr 2010
- Location
- Novosibirsk, Russia
- Posts
- 136
ncurses: filling window with background
I have some ideas about writing a small game in terminal ( just for fun
) using ncurses library. I want to use some kind of menus (in Midnight Commander's style), but there are some problems with rendering windows, that I don't understand. I create a window with newwin(), assign a color pair to it calling wattron() (for example, I want to fill a window with blue background), and then I call my own function wnd_fill() :
But the result is not the same as I expect. The window is filled entirely, except the last (bottom) line - only its lesser part is filled. No matter how huge I make the string in 'buf' - it always left the window's lower right part unfilled. If I highlight the window's borders with the box() function, it looks like on the image in attachment.Code:void wnd_fill (WINDOW* wnd) { int i; int maxy = wnd->_maxy; // retrieve the window's Y and X sizes int maxx = wnd->_maxx; int area = maxy * maxx; // calc the window's area char *buf = (char *) malloc (area); for(i=0; i < area; i++) { buf[i] = ' '; // generate an "empty" string } buf[area] = '\0'; waddstr (wnd, buf); // fill the window wrefresh (wnd); }
Can anyone tell me what's the matter of such broken window fill and how I can fix it?
- 04-06-2010 #2Linux Guru
- Join Date
- Apr 2009
- Location
- I can be found either 40 miles west of Chicago, or in a galaxy far, far away.
- Posts
- 8,974
First, allocate one byte more than the 'area' for your buffer. You are overriting the end of the buffer since the position of buf[area] is actually beyond the end of the buffer you allocated. As a result, it has munged your stack. You are lucky it didn't segfault on you. This may be related to your problem. Try it at least to be sure that this isn't causing the effect you are seeing.
Sometimes, real fast is almost as good as real time.
Just remember, Semper Gumbi - always be flexible!
- 04-07-2010 #3Linux Newbie
- Join Date
- Apr 2010
- Location
- Novosibirsk, Russia
- Posts
- 136
Oh my God... That's thing I've just forgot :) of course, you are right, cause of this function is called also from other code parts, a segfault appears randomly with some trash on the screen. Thanks, it seems that all other problems are also could be fixed in that way :)
- 04-07-2010 #4Linux Guru
- Join Date
- Apr 2009
- Location
- I can be found either 40 miles west of Chicago, or in a galaxy far, far away.
- Posts
- 8,974
Happy to help. This is one of the most common software bugs out there - mis-sized buffers and buffer overruns. If you are developing software for commercial or corporate use, it is helpful to utilize some memory checking tools that will detect these sort of problems. If $$ is no issue, then you can't go wrong with IBM/Rational Purify. If it is, then are are some open source tools that will help detect these sort of problems. In fact, I think that the GNU debugger (GDB) can do bounds-checking if you compile your software properly and run it in the debugger for testing. I haven't done this, personally, so I only THINK it can be done, from some things I have read in the past...
Sometimes, real fast is almost as good as real time.
Just remember, Semper Gumbi - always be flexible!
- 04-07-2010 #5Linux Newbie
- Join Date
- Apr 2010
- Location
- Novosibirsk, Russia
- Posts
- 136
Thanks, I think I should try some of them ) at now it's only my own interest, not $$ yet

And the window-filling problem at last appeared to be a quite more interesting...) the window's X size (width) in fact doesn't match with summary width of filling chars ) I had to add 11 spaces to reach the correct result
- 04-07-2010 #6Linux Guru
- Join Date
- Apr 2009
- Location
- I can be found either 40 miles west of Chicago, or in a galaxy far, far away.
- Posts
- 8,974
Probably due to line-wrapping? It's been a LONG time since I last did much ncurses programming (almost 20 years). Never had this particular problem, but the environment is different. In fact, at one time, I implemented my own curses library for realtime systems.
One resource I have been very productive with was Unix Curses Explained from Prentice-Hall by Berny Goodheart. I don't know if it is still in print (Copyright 1991), but it was very useful to me.
Sometimes, real fast is almost as good as real time.
Just remember, Semper Gumbi - always be flexible!
- 04-07-2010 #7Linux Guru
- Join Date
- Apr 2009
- Location
- I can be found either 40 miles west of Chicago, or in a galaxy far, far away.
- Posts
- 8,974
Also I had a lot of use from O'Reilly & Associates' book Programming with Curses, published in 1986 originally. I'm sure there are newer books on the subject, but these two, the O'Reilly and Prentice-Hall books, enabled me to implement a completely compatible and efficient curses library suitable for realtime applications.
Sometimes, real fast is almost as good as real time.
Just remember, Semper Gumbi - always be flexible!
- 04-07-2010 #8Linux Newbie
- Join Date
- Apr 2010
- Location
- Novosibirsk, Russia
- Posts
- 136
- 04-07-2010 #9Linux Newbie
- Join Date
- Apr 2010
- Location
- Novosibirsk, Russia
- Posts
- 136
I heard that some people compile ncurses from the source code, so can I find it anywhere?.. Does ncurses library has its own website, or source repository?..
- 04-07-2010 #10


Reply With Quote
