Is this supposed to happen? How can I make it not happen? It seems a bit
strange. Just a simple event queue clearing such as:
while (SDL_PollEvent(&event))
{
}
causes a screen update. This is undesirable.
Is this supposed to happen? How can I make it not happen? It seems a
bit
strange. Just a simple event queue clearing such as:while (SDL_PollEvent(&event))
{
}causes a screen update. This is undesirable.
That sounds pretty weird… I mean, if it’s not your code doing
something, where does the data come from?
What platform is this on?
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Saturday 19 March 2005 11.26, Wayne Marsh wrote:
What do you mean by “causes a screen-update”?
To me, a screen update means that I get a SDL_VIDEOEXPOSE event,
and nothing gets to the screen if I don’t put it there myself.
Do you mean that SDL_VIDEOEXPOSE events are generated just by pooling
events?
(that’s unlikely; beside, if that was the case, your loop would never end).
maybe more info?
Marco
Wayne Marsh wrote:>Is this supposed to happen? How can I make it not happen? It seems a bit
strange. Just a simple event queue clearing such as:
while (SDL_PollEvent(&event))
{
}causes a screen update. This is undesirable.
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
What do you mean by “causes a screen-update”?
Maybe he’s got an event filter installed?
Maybe this is another fruity Windows thing? 
–ryan.
Is this supposed to happen?
No
How can I make it not happen?
If you want to post your source code somewhere, someone on the mailing
list can have a look, and tell you what you’re doing wrong.
It seems a bit strange.
It’s not that strange all the time. Plenty of plenty blame their tools
before themselves.On Mar 19, 2005, at 5:26 AM, Wayne Marsh wrote:
It’s not that strange all the time. Plenty of plenty blame their tools
before themselves.
That wasn’t very polite.
–ryan.
Either way, my habit of always blaming my code first had me waste
about two hours the other day, before it dawned on me that this old
Borland C++ compiler (DOS) I was using (lab instrument “firmware”)
sometimes generates code that leaves garbage values on the FPU
stack… heh
Should have known better, considering that I’ve found several bugs in
it before - but after using gcc for 8 years or something, I sometimes
forget that not all tools are to be blindly trusted.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Sunday 20 March 2005 20.14, Ryan C. Gordon wrote:
It’s not that strange all the time. Plenty of plenty blame their
tools before themselves.That wasn’t very polite.
It’s not that strange all the time. Plenty of plenty blame their
tools before themselves.That wasn’t very polite.
Consider the source.
Either way, my habit of always blaming my code first had me waste
about two hours the other day,
It’s a good habit to have, David. I hope you never give it up.
One principle I always tried to impress on the younger engineers was that if
someone says there’s a bug in your code, then there is a bug in your code,
until proven otherwise. It is incumbent on the software engineer to determine
that the bug does not exist, either by proving the correctness of the code,
or by showing that it is impossible for the code to do what is claimed.
(Someone once reported a bug in one of my projects and I was able to show
that for the software to behave that way, it would have to be able to predict
the future. As a friend of mine use to say, “If I could do that, you couldn’t
afford me.” Not that my code is immune to bugs, this is just an example.)
JPOn Sunday 20 March 2005 12:32 pm, David Olofson wrote:
On Sunday 20 March 2005 20.14, Ryan C. Gordon wrote:
In Tux Paint, the loading sequence showed an animated progress bar,
but never touched the event queue. This meant if the window got covered
(or minimized, or whatever) and then exposed, parts of the image I had
blitted prior to the loading sequence could get destroyed. (The progress
bar worked fine, of course.)
I finally added some code to call SDL_PollEvent(), and that seems to allow
the underlying SDL lib to handle the expose events and keep the window from
turning into garbage.
(It’s also a good place to check for SDL_QUIT events, and abort the loading
sequence, in case the user decides they /didn’t/ want to load the app,
and don’t want to wait 30 seconds for all of the data to load.)
-bill!On Sat, Mar 19, 2005 at 08:52:32PM +0100, Marco Tarini wrote:
What do you mean by “causes a screen-update”?