Pi3D cbreak() problem


12 posts
by davef21370 » Sat Nov 03, 2012 12:45 pm
Just trying to get to grips with Pi3D by playing with the ForestWalk example but getting this error when I run the script.....

File "include/pi3dCommon.py", line 640, in __init__
curses.cbreak()
error: cbreak() returned ERR

...if I comment out the "curses.cbreak()" function the script runs but, of course, I've no keyboard input and can't exit the script.

I really fancy doing something with Pi3D and could do without early knockbacks so any help greatly appreciated.

Cheers.
Dave.
Please feel free to tap into my abundant lack of knowledge.
User avatar
Posts: 511
Joined: Fri Sep 21, 2012 4:13 pm
Location: Up North
by paddyg » Sun Nov 04, 2012 6:11 pm
dave, I have found some odd behaviour running some of the pi3d examples, not all of them with a discernible pattern. However I know that I will get non function keys if I start the 3d type (i.e. forestwalk etc rather than rasperryrain etc) from the command line (i.e. 'python ForestWalk.py') rather than opening the graphical interface with startx then running geany and using the run (cogs button). Tom Swirly also found that the pi3d.display() has to be started in the main thread which might be realted (though don't know how). Obviously these things need to be fixed if possible

How are you running ForestWalk.py and what version operating system and set-up do you have?

PS when debugging and fiddling with stuff I usually set the screen size a bit smaller so I can 'get at' the terminal window underneath and right-click close it when the script stops responding. This saves unplugging and rebooting each time!

Paddy
also https://groups.google.com/forum/?hl=en-GB&fromgroups=#!forum/pi3d
User avatar
Posts: 870
Joined: Sat Jan 28, 2012 11:57 am
Location: Bingley, Yorkshire
by davef21370 » Sun Nov 04, 2012 8:20 pm
So far I've run everything from within IDLE, Python 2.7, not tried anything using command line. The RPi is a model B rev.2 with bang up to date debian squeeze, only had the thing a few weeks and updated & upgraded yesterday.

I've been running things with a smaller screen like you say and it does avoid the frustration of having to reboot when things go butt-over-brains!

Anyway, minor bugs aside, I've been playing with "loadmodel.py" today which quickly became "create-model-add-some-physics.py", just bouncing balls and camera wobbles but great fun, hoping to stick a demo on youtube next weekend (no time during the week) and carry on creating.

This definitely has massive potential, love it !!

Thanks for your help again.
Dave.
Please feel free to tap into my abundant lack of knowledge.
User avatar
Posts: 511
Joined: Fri Sep 21, 2012 4:13 pm
Location: Up North
by paddyg » Sun Nov 04, 2012 8:44 pm
Waiting to see what you've done with interest. I did a bit of physics with a rough 3D pong (more like pinball now I think about it) on the programming/python/pi3d thread, right at the end. I have just started looking at incorporating some of the physics into the pi3d library (collision detection and normal-for-bounce calculation)

Paddy
also https://groups.google.com/forum/?hl=en-GB&fromgroups=#!forum/pi3d
User avatar
Posts: 870
Joined: Sat Jan 28, 2012 11:57 am
Location: Bingley, Yorkshire
by KenT » Sun Nov 04, 2012 9:00 pm
It might be worth trying to run from a terminal opened from the desktop. I have had some problems with running Python from Idle which Google suggests is because Idle is a Tkinter gui toolkit application.

Watching this thread with interest. I want to fade, slide, and otherwise animate changes between full screen images. I know Pi3d would be overkill but I'm not sure it would be the right tool for the job.
Pi Presents - A toolkit to produce multi-media interactive displays for museums, visitor centres, and more
Download from http://pipresents.wordpress.com
Posts: 591
Joined: Tue Jan 24, 2012 9:30 am
Location: Hertfordshire, UK
by paddyg » Sun Nov 04, 2012 9:19 pm
Quick test on Pi. Same py file in same location etc
1. run on console before startx - works fine and responds to key but the screen is then unusable in so far as characters appear on screen but that's all. Have to power off and on.
2. run in a terminal started from GUI - works ok and stops, terminal closes with X button
3. run using the cogs in geany - essentially the same as terminal from GUI
4. run from IDLE I get an error about the mismatched tabs and spaces. This is a real bother to tidy up in Tim's code but ought really to be done, geany copes ok. When fixed IDLE still complains about the cbreak() so Ken is probably right but still worth getting to bottom of.

Ken, there seem to be quite a few people keen to use just the fast graphics aspects without all the 3D and sprites. Look towards the end of the pi3d thread. I think there will probably be a rationalisation of the code so that it lends itself to this.

Paddy
also https://groups.google.com/forum/?hl=en-GB&fromgroups=#!forum/pi3d
User avatar
Posts: 870
Joined: Sat Jan 28, 2012 11:57 am
Location: Bingley, Yorkshire
by jojopi » Mon Nov 05, 2012 5:32 am
paddyg wrote:1. run on console before startx - works fine and responds to key but the screen is then unusable in so far as characters appear on screen but that's all. Have to power off and on.
Some of the demos appear to hang during cleanup for me too. They do not respond to Ctrl+C (interrupt) but they do exit on Ctrl+\ (quit signal). (Also you can switch consoles with Ctrl+Alt+F2 and log in again to identify and kill stuck processes. And Ctrl+Alt+Del on console will reboot, so it should never be necessary to power off.)

In X it is best to kill the process (with Ctrl+\ if necessary) before closing the terminal window. Closing the window will send a hangup signal, but it is possible for this to be ignored leaving the process still taking up memory.
4. run from IDLE I get an error about the mismatched tabs and spaces. This is a real bother to tidy up in Tim's code but ought really to be done, geany copes ok. When fixed IDLE still complains about the cbreak() so Ken is probably right but still worth getting to bottom of.
The error message actually tells you how to automatically untabify the source.

cbreak() attempts to configure the terminal attached to standard input to read individual characters instead of waiting for a complete line. This does not work in IDLE because standard input is not attached to a terminal. (Unless you start idle from a command line, in which case the input terminal is the window you started it from, not the window it appears to be running in!)
User avatar
Posts: 2058
Joined: Tue Oct 11, 2011 8:38 pm
by paddyg » Mon Nov 05, 2012 8:51 am
jojopi, Thanks for that. I don't think I tried ctrl+\ (though I'm sure I did try ctrlAltDel at some stage but I think there may have been other problems previously that Tim fixed) and ctrlAltF2 is a good option too.

The trouble with the mixed tabs and spaces is that python is cleverer than the untabify (as I remarked to a previous defender of python) if you make a back-up of pi3d.py or pi3dCommon.py then try to untabify them you will see that, although python can differentiate between the different combinations of spaces and tabs used, your document will end up with blocks no longer indented and odd lines indented where they shouldn't be. I have gone through and fixed this a couple of times already and it's really quite hard to do (and has convinced me of the beauty of curly brackets) but the mods haven't made it back to original version.

Do you have any suggestions for a better way of getting key presses, I know Tim Skillman was unhappy with this and looking for some alternative.

Paddy
also https://groups.google.com/forum/?hl=en-GB&fromgroups=#!forum/pi3d
User avatar
Posts: 870
Joined: Sat Jan 28, 2012 11:57 am
Location: Bingley, Yorkshire
by jojopi » Mon Nov 05, 2012 10:37 am
paddyg wrote:The trouble with the mixed tabs and spaces is that python is cleverer than the untabify
Untabify worked for me, with a tab width of 8, which was not the default. It is clear that 8 is the right value because the first indent in the file is four spaces, and the next indent is one tab.

Moreover, from what I have just read python assumes a tab width of 8 when tabs and spaces are mixed. So I believe that untabify 8 is exactly as clever as python is and should work for any parseable program. (It will be a bit excessive, however, if the author has used tabs exclusively.)
Do you have any suggestions for a better way of getting key presses, I know Tim Skillman was unhappy with this and looking for some alternative.
If it is to work both in X and on console, then terminal cbreak or /dev/input/event are the only options. Terminal is arguably better behaved and has the advantage of working over ssh.
User avatar
Posts: 2058
Joined: Tue Oct 11, 2011 8:38 pm
by paddyg » Mon Nov 05, 2012 9:34 pm
jojopi, I'm not sure I'm glad to know how much time I would have saved myself by knowing about untabify 8! Actually I learnt a lot about the code by reading it through line by line and working out where blocks should end. (The second time was much faster but also a complete waste of time).
Paddy
also https://groups.google.com/forum/?hl=en-GB&fromgroups=#!forum/pi3d
User avatar
Posts: 870
Joined: Sat Jan 28, 2012 11:57 am
Location: Bingley, Yorkshire
by davef21370 » Fri Nov 09, 2012 8:08 pm
Things are looking up but not perfect. Been running stuff from within a terminal instead of direct from IDLE with no cbreak() error so happy days there.

A problem remains though, in ForestWalk (not had time to try much else) the keyboard input seems to be buffered and moving forward, for example, continues movement a while after releasing the key.

I'm going to have to play the "new-to-linux-python-and-pi3d" card again and plead ignorance.

How do I use keyboard control that stops completely on key up?

Thanks for all your feedback so far, I'm learning a good deal and still got a lot to learn, loving it :)
Please feel free to tap into my abundant lack of knowledge.
User avatar
Posts: 511
Joined: Fri Sep 21, 2012 4:13 pm
Location: Up North
by jojopi » Sat Nov 10, 2012 2:55 pm
Terminal cbreak mode returns an ascii character on each press plus auto-repeat if the key is held, rather than keydown and keyup events. The speed of the auto-repeat is a system-wide setting (on the system with the keyboard, if you are controlling remotely).

There is, as you realised, an input buffer. That is so that characters are not lost if you type faster than the program reads. But it also means that if a character auto-repeats faster than the program reads, the effects can carry on after the key is released.

A solution would be to read as much input as possible (without blocking) at each attempt, and immediately discard any duplicates. Effectively this restricts the repeat rate to the rate that the characters can be acted on.
User avatar
Posts: 2058
Joined: Tue Oct 11, 2011 8:38 pm