You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I can see it being useful information when developing and trying to debug a problem related to vsync on a particular system. What is really needed is a -verbose type flag to pygame to produce more warnings and information like this that you don't always want all the time.
Perhaps another environment variable that defaults to off - similar to what we have for the pygame welcome message but in reverse?
Perhaps another environment variable that defaults to off - similar to what we have for the pygame welcome message but in reverse?
The warnings in display.c are default python warnings that already can be disabled.
So I don't know if a pygame specific variable is really needed... and if it is, it could simply modify the warnings filter.
But I wonder if it should be on or off by default. 🤔 Pygame is, I think, mostly used by people who are learning and hiding warnings by default means that some people would miss them because they don't even know they exist. If they are on by default, they always can be disabled by the programmer for the release version of something.
What is really needed is a -verbose type flag
Multiple warning categories also could be used for this. Only the most important warnings would be displayed by default and the less useful ones (like the one @lordmauve mentioned) would need to be turned on.
Setting a default warning level and then flipping some above and below that level sounds like a solid plan to me. I think the vsync warning, for example, is likely something that only a relatively advanced user would ever want to know rather than somebody just making their first game.
I think its important for us to default to a moderately verbose communication, like the intro prompt with version data, purely because of the userbase of pygame. Most users of pygame aren't using many other libraries they are beginners learning how to code in schools and universities not writing their own modules, and many of them probably don't even know the term dependency. I'd prefer to default to slightly annoying power users rather than making pygame support and development harder for beginners. That is a long running debate though and there are other issues discussing it.
I think handing over control to users as to what kind of warnings and other, non-error output, is produced is the right choice. Maybe three warning levels: 'default', 'verbose', 'quiet'
I will say that for end users of finished pygame apps you should probably just hide the console entirely and not worry about it.
Supporting vsync cross-platform is tricky, and even when you see no warning, it might not work. Do you think it should silently fail in all cases, even if vsync was requested explicitly but PyGame knows it could not be enabled?
Well, if we think people care if vsync was requested but is unavailable, then we should raise an exception.
Or we could treat everything that was passed to set_mode() as a hint and provide a function to query back what we actually got. This is probably the way forward because you don't necessarily even get the dimensions you requested.
The difference is that vsync is a new parameter in pygame 2.0, so we can decide to throw an exception when it is incorrectly used with non-accelerated windows without breaking backward compatibility. If it were up to me, we'd also print warnings on other impossible flag combinations.
The text was updated successfully, but these errors were encountered:
Issue №2132 opened by lordmauve at 2020-10-01 10:00:51
When I call
pygame.display.set_mode(..., vsync=True)
, it prints a warning.As a user, there's nothing I can do about this. I don't want to be warned.
Comments
# # MyreMylar commented at 2020-10-01 14:24:20
I can see it being useful information when developing and trying to debug a problem related to vsync on a particular system. What is really needed is a
-verbose
type flag to pygame to produce more warnings and information like this that you don't always want all the time.Perhaps another environment variable that defaults to off - similar to what we have for the pygame welcome message but in reverse?
# # ghost commented at 2020-10-02 00:38:50
The warnings in display.c are default python warnings that already can be disabled.
So I don't know if a pygame specific variable is really needed... and if it is, it could simply modify the warnings filter.
But I wonder if it should be on or off by default. 🤔 Pygame is, I think, mostly used by people who are learning and hiding warnings by default means that some people would miss them because they don't even know they exist. If they are on by default, they always can be disabled by the programmer for the release version of something.
Multiple warning categories also could be used for this. Only the most important warnings would be displayed by default and the less useful ones (like the one @lordmauve mentioned) would need to be turned on.
# # MyreMylar commented at 2020-10-02 08:26:42
Setting a default warning level and then flipping some above and below that level sounds like a solid plan to me. I think the vsync warning, for example, is likely something that only a relatively advanced user would ever want to know rather than somebody just making their first game.
# # lordmauve commented at 2020-10-02 08:38:05
More important than what developer see is what end users see; I don't want to pass Pygame warnings/announcement to users of my game (or framework).
I try to always [suppress the "hey, you're using Pygame" chatter](https://github.com/lordmauve/wasabi2d/blob/080c5bb041b34405406eace628bde26c67ff30ef/wasabi2d/__init__.py# L6) which in my view is not appropriate (what if every library did that? Would I need to set an environment variable for every dependency?)
Does Pygame need a "release mode" that has a broader effect?
Maybe
?
# # MyreMylar commented at 2020-10-02 12:37:03
I think its important for us to default to a moderately verbose communication, like the intro prompt with version data, purely because of the userbase of pygame. Most users of pygame aren't using many other libraries they are beginners learning how to code in schools and universities not writing their own modules, and many of them probably don't even know the term dependency. I'd prefer to default to slightly annoying power users rather than making pygame support and development harder for beginners. That is a long running debate though and there are other issues discussing it.
I think handing over control to users as to what kind of warnings and other, non-error output, is produced is the right choice. Maybe three warning levels: 'default', 'verbose', 'quiet'
I will say that for end users of finished pygame apps you should probably just hide the console entirely and not worry about it.
# # ghost commented at 2020-10-02 14:03:44
Edit: This will turn off all python warnings... So maybe having pygame specific warning categories would be a good idea.
In the meantime, in case someone finds this issue while searching for a way to hide the warnings:
-W ignore
at the command line works (python3 -W ignore
)That way, the warnings are off by default unless turned on with
-W default
# # robertpfeiffer commented at 2020-10-03 07:42:10
Supporting vsync cross-platform is tricky, and even when you see no warning, it might not work. Do you think it should silently fail in all cases, even if vsync was requested explicitly but PyGame knows it could not be enabled?
# # lordmauve commented at 2020-10-03 09:55:37
Well, if we think people care if vsync was requested but is unavailable, then we should raise an exception.
Or we could treat everything that was passed to set_mode() as a hint and provide a function to query back what we actually got. This is probably the way forward because you don't necessarily even get the dimensions you requested.
# # robertpfeiffer commented at 2020-10-11 08:51:13
The difference is that vsync is a new parameter in pygame 2.0, so we can decide to throw an exception when it is incorrectly used with non-accelerated windows without breaking backward compatibility. If it were up to me, we'd also print warnings on other impossible flag combinations.
The text was updated successfully, but these errors were encountered: