Re: [pygame] surface.get_flags() and pygame.FULLSCREEN

[Jørgen P. Tjernø]

Brian Fisher wrote:
On Sat, Nov 29, 2008 at 10:54 AM, "Jørgen P. Tjernø" <[EMAIL PROTECTED] 
> wrote:

Sometimes it does regrab fullscreen after a few seconds - and
sometimes it doesn't, continuing to run in windowed. I've recently
set up a "debug server" so I can query the various flags at runtime,
and I'll see if it re-occurs.

The "sometimes it doesn't" sounds like a real bug - other platforms 
(windows and mac OS X for me anyways) go back into exclusive fullscreen 
mode when the app becomes active again. On most windows machines I've 
tested on, it does take a few seconds for the process for that to 
complete, and in such cases I believe the delay is just an exclusive 
mode thing and out of SDL & pygame's hands. However, I've never seen it 
not go back.
Yeah, it's strange. I've set up better routines for debugging (more 
logging, a telnet console to inspect state), so if it occurs again, I 
can try tracing it down. If not, I'll just dismiss it as one of those 
pesky PEBKAC errors from my end. ;-)


I don't suppose you can get a similar problem with your systems alt-tab 
(or equivalent)? The reason I ask, is the whole SSH'ing in and then 
running something to take fullscreen part of things sounds like an 
uncommon usage case to me and I'm curious if the cause of the problem 
here is specific to that behavior.
It's from "normal usage"; a fullscreen pygame spawns a fullscreen VLC in 
its own window, so this takes focus and my app loses it's fullscreen 
status. Later on, when VLC quits, my program is active again, and that's 
when I've experienced it not attaining fullscreen.


I'll send a new email with more info if I catch it happening again. :)

--
Kindest regards, Jørgen P. Tjernø.

Re: [pygame] surface.get_flags() and pygame.FULLSCREEN

[Brian Fisher]

On Sat, Nov 29, 2008 at 10:54 AM, "Jørgen P. Tjernø" <[EMAIL PROTECTED]>wrote:

> Sometimes it does regrab fullscreen after a few seconds - and sometimes it
> doesn't, continuing to run in windowed. I've recently set up a "debug
> server" so I can query the various flags at runtime, and I'll see if it
> re-occurs.
>
> The "sometimes it doesn't" sounds like a real bug - other platforms
(windows and mac OS X for me anyways) go back into exclusive fullscreen mode
when the app becomes active again. On most windows machines I've tested on,
it does take a few seconds for the process for that to complete, and in such
cases I believe the delay is just an exclusive mode thing and out of SDL &
pygame's hands. However, I've never seen it not go back.



> When it doesn't regrab fullscreen, I can't seem to nudge it in the right
> direction as an "end user" (like changing focused window).
>
> again, sounds like a bug, probably an SDL one.

I don't suppose you can get a similar problem with your systems alt-tab (or
equivalent)? The reason I ask, is the whole SSH'ing in and then running
something to take fullscreen part of things sounds like an uncommon usage
case to me and I'm curious if the cause of the problem here is specific to
that behavior.

Re: [pygame] surface.get_flags() and pygame.FULLSCREEN

[Jørgen P. Tjernø]

Brian Fisher wrote:
Your argument is irrelevant to someone with my perspective- it's still a 
fullscreen display - it just can't grab the screen in exclusive mode 
when it's not active. In my opinion, you are misunderstanding what the 
flag means.

Okay, that may be.

You said it does regrab fullscreen, but it just takes a few seconds, is 
that correct? So is the problem here that you want to be able to tell 
when it is in the state where it is active but has not yet gotten 
exclusive mode yet?
Sometimes it does regrab fullscreen after a few seconds - and sometimes 
it doesn't, continuing to run in windowed. I've recently set up a "debug 
server" so I can query the various flags at runtime, and I'll see if it 
re-occurs.


When it doesn't regrab fullscreen, I can't seem to nudge it in the right 
direction as an "end user" (like changing focused window).


I'd love to detect when it's supposed to be fullscreen and isn't, and 
when it's about to regrab full-screen. If I can reproduce the problem 
when it doesn't regrab fullscreen, I'll try querying the various states. :)


--
Kindest regards, Jørgen P. Tjernø

Re: [pygame] QuickDraw warning on Mac OS X

[Brian Fisher]

http://pymunk.googlecode.com/svn/tags/pymunk-0.8.1/docs/api/index.html

On Fri, Nov 28, 2008 at 8:39 PM, Joe Strout <[EMAIL PROTECTED]> wrote:

> On Nov 28, 2008, at 9:26 PM, René Dudfield wrote:
>
>  this is a known issue.  Newer versions of SDL should fix this.
>> So for now, just ignore the warning.
>>
>
> Super, that's good enough for me.
>
> For what it's worth, I've now modified pymunk's demo_slide_and_pinjoint
> sample so that both the tipping platform and the balls have some friction,
> and the balls are drawn with a rotation indicator, so I can actually see
> that they're rotating.  It all runs smoothly, behaves correctly, and I'm
> having a blast!
>
> Now I just need to figure out how to play a little "bonk" sound when the
> balls collide.  Though pymunk's installation was a breeze and the examples
> are extensive, the documentation is a little... er... nonexistent, AFAICT.
>  Still, I'm happy to keep exploring, because doing so with this stuff is so
> much fun!
>
> Cheers,
> - Joe
>
>
>

Re: [pygame] which Box2D wrapper to use? additional info

[Peter Gebauer]

Just wanted to add, I tried Box2D and PyBox2D from SVN trunk, the ladder 
failed, as do the noobie-style zip-file (Warning! no root directory 
included) that is the downloadable tarball. Like I said, it's all Windows on 
this one or major headache. The various buildscripts interpret environment 
compiler flags differently and there's a far share of warnings before gcc 
croaks.

/Peter

Re: [pygame] which Box2D wrapper to use?

[Peter Gebauer]

Hey Joe.

There are also entirely separate engines to choose from. My experience with 
Box2D is that it's very Microsoftish, I had to edit the header files 
before being able to build it. The project is mainly maintained and written 
through some visual stuff, I don't know what. So, just a heads up if you 
plan on multi platform release.
It does run, I'm just saying multi platform targets isn't it strong suite at 
the moment. I also got an attribute error from Elements' Python code and 
gave up immediately. (latest tarballs)

There's also Chipmunk, another similar library, it too has some Python 
bindings. Then there's the soon-to-be-in-PyGame library from GSOC, but at 
this time it lacks much of the functionality you'd come to expect from 2d 
physics engines. You'll have to see what fits your project best.

Oh, you'll be pleasantly surprised to learn that both Box2D and Chipmunk 
have sort of incredible machine implementations, sandboxes and/or 2d physics 
toys. Go ahead, build yourself a crazy machine.

/Peter


On 2008-11-28 (Fri) 20:23, Joe Strout wrote:
> There appear to be two of them:
>
>   http://www.pygame.org/project/913/
>   http://www.pygame.org/project/723/
>
> Any advice as to which one a newbie should choose?
>
> Thanks,
> - Joe
>
>
>

Re: [pygame] "Crazy Machine" type game?

[Michael George]

I'm working on something along these lines - 
http://sf.net/projects/pen/  Any interest in joining me?


--Mike


Joe Strout wrote:

Hi all,

I'm new to pygame, and only recently returned to Python after nearly a 
decade in the REALbasic world.  So I hope you'll speak slowly and use 
small words.  :)


I've got the bug to create a game similar to the classic games 
"Incredible Machine" and "Crazy Machine".  For those not familiar, it 
amounts to giving the player a palette of pieces that they can arrange 
in a 2D grid to make Rube Goldberg-style machine that accomplishes 
some goal.  Pieces include weights, balls, balloons, electrical 
components, fans, candles, rockets, ropes, pulles, gears, monkeys on 
bicycles, and so on.  It's a little like the Flash game "Fantastic 
Contraption" [1], but with far more (and more fun) parts.


As an open-source networked game, it could be especially fun, as 
anyone could contribute their own challenges, and we could keep stats 
online regarding how many people have attempted or solved each one.


Is there already anything like this started in Python?  (I searched 
the pygame archives, but didn't see anything.)


If not, have you any advice on how to approach it in the Pygame 
world?  I was thinking of trying PyODE for the physics simulation 
(hopefully that will run cleanly on all platforms, and not just 
Windows, as that is a firm constraint for me).  For the graphics, all 
I need is basically 2D sprites that can move, rotate, and change their 
image -- from the Pygame examples I've seen, that should be no 
problem.  But what do y'all think?


Thanks,
- Joe

[1] http://fantasticcontraption.com/