Re: [pygame] Re: loss of rapidly repeated keypresses (from a barcode gun keyboard)
On Thu, Dec 3, 2009 at 6:26 PM, Brian Fisher wrote: > On Thu, Dec 3, 2009 at 8:54 AM, James Paige wrote: > >> ...Although that still doesn't explain why it has no problem with any of >> the non-SDL apps I have tested on Linux. >> >> pyglet is non-SDL, and you saw the same problem with pyglet, yeah? So > either SDL has some problem that pyglet also has, or they both use some > common mechanism that the console and other apps don't. > > pyglet was inspired by SDL, so I assume some parts are similar. > Assuming a new SDL doesn't simply fix it for you, pyglet source should be > easily available and fairly easy to read (being pure python), so you might > be able to understand the problem better by looking at pyglet. And you could > modify it pretty easily too. >
Re: [pygame] Re: loss of rapidly repeated keypresses (from a barcode gun keyboard)
On Thu, Dec 03, 2009 at 09:26:18AM -0800, Brian Fisher wrote: >On Thu, Dec 3, 2009 at 8:54 AM, James Paige >wrote: > > ...Although that still doesn't explain why it has no problem with any of > the non-SDL apps I have tested on Linux. > >pyglet is non-SDL, and you saw the same problem with pyglet, yeah? So >either SDL has some problem that pyglet also has, or they both use some >common mechanism that the console and other apps don't. Ah, interesting! I had mistakenly assumed that pyglet also used sdl (I knew it uses opengl, but I had incorrectly assumed that it was using sdl+opengl together) >Assuming a new SDL doesn't simply fix it for you, pyglet source should be >easily available and fairly easy to read (being pure python), so you might >be able to understand the problem better by looking at pyglet. And you >could modify it pretty easily too. Good idea. maybe I will take a look at that. I was browsing through SDL source code yesterday, but my learning curve was feeling pretty slow :) --- James
Re: [pygame] loss of rapidly repeated keypresses (from a barcode gun keyboard)
On Thu, Dec 03, 2009 at 05:04:05PM +, René Dudfield wrote: >Hi, > >I think this has to do with SDL and xevents. It's possible SDL can lose >events if they come in too fast. Since it tries to prevent flooding of >the event queue. Well it does for mouse events anyway. > >I can't remember if they fixed/changed stuff for the recent 1.2.14 >release... but it's worth trying out if you haven't already. Interesting. My main Linux testing box has SDL 1.2.13. I'll give it a shot. >Also, maybe try out the 'xev' command - which prints x events. Then you >can see if it is printing out all the events at the X level. >man xev I just tried that, and no X events are being lost. Oh, also, I figured out why I was getting almost universal failure in my test app but only the first scan was failing in my production app. In the production app I was only testing with barcodes, and only the first scan would lose repeitious events. In my simplified test app, I was actually switching between the barcode scanner and my regular keyboard. I would scan "222333" and then I would type "z" to have a visual delimiter between that and the next scan. When I did that, almost every single scan would lose events. So it seems that SDL actually only loses events from the first scan after the main keyboard has been used. I tested this further, by launching my test.py script, testing it, then closing it only using the mouse, then running it again only using the mouse. Then the first scan did NOT lose events. This is very encouraging to me, since it means that solving this problem or working around it is no longer a critical issue for me, since this barcode application is going to be running on an embedded computer with no main keyboard anyway.. But I do still want to solve this mystery from a mystery-solving perspective. I just no longer need to solve it from a getting-my-work-done perspective :) --- James
Re: [pygame] Re: loss of rapidly repeated keypresses (from a barcode gun keyboard)
On Thu, Dec 3, 2009 at 8:54 AM, James Paige wrote: > ...Although that still doesn't explain why it has no problem with any of > the non-SDL apps I have tested on Linux. > > pyglet is non-SDL, and you saw the same problem with pyglet, yeah? So either SDL has some problem that pyglet also has, or they both use some common mechanism that the console and other apps don't. Assuming a new SDL doesn't simply fix it for you, pyglet source should be easily available and fairly easy to read (being pure python), so you might be able to understand the problem better by looking at pyglet. And you could modify it pretty easily too.
Re: [pygame] loss of rapidly repeated keypresses (from a barcode gun keyboard)
Hi, I think this has to do with SDL and xevents. It's possible SDL can lose events if they come in too fast. Since it tries to prevent flooding of the event queue. Well it does for mouse events anyway. I can't remember if they fixed/changed stuff for the recent 1.2.14 release... but it's worth trying out if you haven't already. Also, maybe try out the 'xev' command - which prints x events. Then you can see if it is printing out all the events at the X level. man xev cu,
Re: [pygame] loss of rapidly repeated keypresses (from a barcode gun keyboard)
On Thu, Dec 03, 2009 at 12:12:14AM -0600, Jake b wrote:
>Have you tried changing .key.set_repeat(something_small) ?
I tried that, but it made no difference.
>And how are you polling for the events?
Here is my test code:
#!/usr/bin/env python
import pygame
from pygame.locals import *
pygame.init()
screen = pygame.display.set_mode((640, 480))
font = pygame.font.Font(None, 24)
clock = pygame.time.Clock()
text = ""
def say(s, ypos, col=(255,255,255)):
img = font.render(s, True, col)
screen.blit(img, (0, ypos))
if img.get_rect().width > screen.get_rect().width:
return True # overflowed the screen width
return False
while True:
clock.tick(60)
for event in pygame.event.get():
if event.type == pygame.QUIT:
raise SystemExit
if event.type == pygame.KEYDOWN:
if event.key == K_ESCAPE:
raise SystemExit
text += event.unicode
screen.fill((0,0,0))
say("If first input comes from a barcode gun keyboard,", 0)
say("repeated characters will be lost.", 20)
if say(text, 80, (128, 255, 128)):
text = ""
pygame.display.flip()
Re: [pygame] Re: loss of rapidly repeated keypresses (from a barcode gun keyboard)
On Wed, Dec 02, 2009 at 04:39:00PM -0800, Brian Fisher wrote: >What that suggests to me is that the problem lies with the way the USB >barcode scanner interacts with system components, well below the >application layer. So like maybe with the HID driver or windowing system >of your computer. > >I'd try it on a different platform, to confirm. I just wanted to mention that I tested this on a Mac OS X 10.3 box today, and the barcode scanner never dropped any characters at all with pygame, so you may be on to something here. ...Although that still doesn't explain why it has no problem with any of the non-SDL apps I have tested on Linux. --- James Paige
Re: [pygame] Make a sprite fall with realistic gravity?
2009/12/3 Bill Coderre > > Now we have laptops and GUIs, and Alan and conspirators have been inventing > new programming systems with Squeak (a newer version of Smalltalk) as their > "assembly language core." Etoys is one of them, and if you haven't tried it, > you should.[1] > > > [1] http://www.squeakland.org/ -- you simply must download and try Etoys. > > When I visit that web page I just get the page source
