Or make e-mailing a specific address start the registration process
(put a script on it)… which would be a variant of a custom captcha
in some sense (serves the same purpose).On the other hand, years ago a forum I used to go (Senntient) implemented a custom captcha because it kept getting bots all the time. Now, that thing is probably extremely easy to by-pass, but since no bot was programmed for it at all the spam block rate was 100% (and in fact I think it still is, but I haven’t gone there in ages). Probably the e-mail idea is better though. The user is more likely to understand to send an e-mail than to solve a captcha (which can be troublesome with people with disabilities, or on browsers with features disabled for the sake of performance or something else, e.g. disabling images to save bandwidth on a phone plan). 2013/5/28, Brian Barnes : Sam wrote:
FYI, we’re getting about 100 spam accounts created per hour. I’m probably
going to add some human verification step to the wiki account creation
which should help with this.
I don’t think that, or the other suggestions, will work in the long run.
I run a message board for dim3 and I’m obviously much lower visibility
than SDL, and I was getting 100 spam accounts a week. Everytime I added
captcha or human verification step it stopped … for about a month.
Then it started right up again.
Some human answered the questions and went through all the captchas and
added it to some database. You’ll probably get turned off much faster
than I did.
It’s annoying, but everybody knows your email, just make them have to
contact you and you’ll add an account for them. I finally moved to that
after spending way too much time cleaning up bad accounts.
I’ve actually set it up to block user names only, not page titles,
based upon patterns in the previously created spam accounts. Two
regular expressions and no more spam since half a year.
Guess it should not be hard to come up with something similar for the
Wiki SDL is using.
KaiOn Tue, May 28, 2013 at 9:28 PM, Brian Barnes wrote:
Sam wrote:
FYI, we’re getting about 100 spam accounts created per hour. I’m probably
going to add some human verification step to the wiki account creation
which should help with this.
I don’t think that, or the other suggestions, will work in the long run. I
run a message board for dim3 and I’m obviously much lower visibility than
SDL, and I was getting 100 spam accounts a week. Everytime I added captcha
or human verification step it stopped … for about a month. Then it started
right up again.
Some human answered the questions and went through all the captchas and
added it to some database. You’ll probably get turned off much faster than
I did.
It’s annoying, but everybody knows your email, just make them have to
contact you and you’ll add an account for them. I finally moved to that
after spending way too much time cleaning up bad accounts.
I have an issue in iOS, not interactive sequences, where there is only
some output like a progress bar, without possible interaction, like loading
screens, with at the moment result in a black screen, you need a
"pumpevents" to display anything on the screen.
This is due to the removal of the implicit pump events in underlying of
RenderPresent.
I can off course find the places where I’m updating the screen without
checking events and add an explicit call in my games, but I’m not sure this
side effect is wanted, I think almost every SDL app will have this problem
at least in the initial startup phase.
I’m not reporting this to bugzilla since I don’t know if it has to be
considered a bug or it’s a wanted behaviour.On Mon, May 27, 2013 at 6:20 AM, Sam Lantinga wrote:
I have an issue in iOS, not interactive sequences, where there is only
some output like a progress bar, without possible interaction, like loading
screens, with at the moment result in a black screen, you need a
"pumpevents" to display anything on the screen.
This is due to the removal of the implicit pump events in underlying of
RenderPresent.
I can off course find the places where I’m updating the screen without
checking events and add an explicit call in my games, but I’m not sure this
side effect is wanted, I think almost every SDL app will have this problem
at least in the initial startup phase.
I’m not reporting this to bugzilla since I don’t know if it has to be
considered a bug or it’s a wanted behaviour.
–
Bye,
Gabry
If I recall correctly they removed the event pumping to prevent iOS apps
from receiving certain callbacks at the wrong time, I guess it’s something
we need to live with.> On Mon, May 27, 2013 at 6:20 AM, Sam Lantinga wrote:
Wait a second, why did RenderPresent pump the events in the first
place? You are already supposed to be pumping them constantly in the
main loop, that sounds redundant to me
You mention the screen won’t refresh until the next time events are
handled, maybe it has something to do with programs updating the
screen after dealing with the events, rather than before? (though even
in that case at worst you should just get a frame of lag) Maybe we
should tell programmers to update the screen before entering the
event loop? (this is what I usually do anyway, to help reduce the lag
between user input and program logic)
2013/5/31, Gabriel Jacobo :> 2013/5/31 Gabriele Greco <gabriele.greco at darts.it>
On Mon, May 27, 2013 at 6:20 AM, Sam Lantinga wrote:
I have an issue in iOS, not interactive sequences, where there is only
some output like a progress bar, without possible interaction, like
loading
screens, with at the moment result in a black screen, you need a
"pumpevents" to display anything on the screen.
This is due to the removal of the implicit pump events in underlying of
RenderPresent.
I can off course find the places where I’m updating the screen without
checking events and add an explicit call in my games, but I’m not sure
this
side effect is wanted, I think almost every SDL app will have this
problem
at least in the initial startup phase.
I’m not reporting this to bugzilla since I don’t know if it has to be
considered a bug or it’s a wanted behaviour.
–
Bye,
Gabry
If I recall correctly they removed the event pumping to prevent iOS apps
from receiving certain callbacks at the wrong time, I guess it’s something
we need to live with.
I think the right thing to do is tickle iOS to draw the view without
pumping events. Does anyone know how to do this correctly?On Fri, May 31, 2013 at 9:14 AM, Gabriele Greco <gabriele.greco at darts.it>wrote:
On Mon, May 27, 2013 at 6:20 AM, Sam Lantinga <@slouken> wrote:
I have an issue in iOS, not interactive sequences, where there is only
some output like a progress bar, without possible interaction, like loading
screens, with at the moment result in a black screen, you need a
"pumpevents" to display anything on the screen.
This is due to the removal of the implicit pump events in underlying of
RenderPresent.
I can off course find the places where I’m updating the screen without
checking events and add an explicit call in my games, but I’m not sure this
side effect is wanted, I think almost every SDL app will have this problem
at least in the initial startup phase.
I’m not reporting this to bugzilla since I don’t know if it has to be
considered a bug or it’s a wanted behaviour.
I’m updating SMPEG for SDL 2.0 and putting MP3 support back into SDL_mixer
for the release.
If you’re looking for a video playback solution, webm is a much better
alternative to using the old MPEG-2 support in SMPEG. I have some code
that plays webm movies with SDL 2.0 that I can clean up and post if people
are interested.On Mon, May 27, 2013 at 1:44 PM, Sam Lantinga <@slouken> wrote:
The latest version of SDL_mixer drops MP3 support by default in favor of
Vorbis, given licensing and patent issues. If you need to stick with MP3,
then you should probably keep what you have.
The iOS and Android versions are pretty stable. I just released an iOS
game earlier this month using SDL 2.0: https://itunes.apple.com/us/app/equate-game/id571543425?mt=8
For iOS it’s pretty easy to to add your own custom views. We had to
support that for Game Center support and so forth.
I haven’t released an Android game myself, but other people have, and can
speak to how well that works. I don’t know how easy it is to extend with
Java UI, but you can extend the SDL base activity class and customize it
for your needs.
The video API between 1.2 and 2.0 is completely different. It’s been
largely rewritten to support hardware acceleration and mobile devices. You
should carefully weigh the benefits of upgrading before diving into it.
Cheers!
On Mon, May 27, 2013 at 1:22 PM, Joshua Granick < bulkmail at joshuagranick.com> wrote:
**
I am sorry if this has been answered on the mailing list recently, or if
it is on the wiki (and I am not seeing it)
We use SDL 1.2, and by and large it works for us, except that SDL_mixer
has issues. I am curious if there have been improvements since 1.2 that
would make this nicer? In the version we have, it becomes unstable if we
allow for stopping, pausing, resuming, or starting from a position further
than the beginning if it is done too often. We also have trouble with users
needing/wanting more than one MP3 track. Have there been changes in the new
version or underlying fixes in SDL’s audio support that may be helpful?
I also am curious how stable you believe Android and iOS to be, as well
as whether it is simple to extend with custom Objective-C or Java instead
of a full-screen app. We maintain separate Android and iOS targets that do
not rely on SDL, but merging onto one low-level API would be nice. We use
SDL for BlackBerry, Windows, Mac and Linux (and legacy webOS support),
which makes the maintenance much better.
Thanks for your help and congratulations on the release candidate!
On Sun, 26 May 2013 21:20:44 -0700, Sam Lantinga <@slouken> wrote:
I’m updating SMPEG for SDL 2.0 and putting MP3 support back into SDL_mixer
for the release.
If you’re looking for a video playback solution, webm is a much better
alternative to using the old MPEG-2 support in SMPEG. I have some code
that plays webm movies with SDL 2.0 that I can clean up and post if people
are interested.
That would be very nice Sam.
VittorioOn Sun, Jun 2, 2013 at 5:40 AM, Sam Lantinga wrote:
If I recall correctly they removed the event pumping to prevent iOS apps
from receiving certain callbacks at the wrong time, I guess it’s something
we need to live with.
That’s correct but as far as i remember isn’t a PumpEvents an implicit
function of Poll/Wait Event?
VittorioOn Fri, May 31, 2013 at 6:34 PM, Gabriel Jacobo wrote:
I just updated to the latest changeset (7970a2839280) and am using a Debug
build of SDL2 with my game on Windows XP.
I just noticed that when changing from fullscreen mode to windowed again,
the window freezes and the CPU spikes. It seems to be an error deep within
SDL_PumpEvents(). I change the window by calling:
SDL2.dll!WIN_WindowProc(HWND__ * hwnd, unsigned int msg, unsigned int
wParam, long lParam) Line 277 + 0xf bytes C
user32.dll!7e418734()
user32.dll!7e418816()
user32.dll!7e42a013()
user32.dll!7e42a039()
opengl32.dll!5ed2699b()
user32.dll!7e418734()
user32.dll!7e418734()
user32.dll!7e418816()
user32.dll!7e428ea0()
user32.dll!7e428eec()
ntdll.dll!7c90e453()
user32.dll!7e4194d2()
user32.dll!7e428f10()
user32.dll!7e419402()
user32.dll!7e418a10()
SDL2.dll!WIN_PumpEvents(SDL_VideoDevice * _this) Line 774 C
SDL2.dll!SDL_PumpEvents() Line 310 + 0xf bytes C
SDL2.dll!SDL_WaitEventTimeout(SDL_Event * event, int timeout) Line 344 C
SDL2.dll!SDL_PollEvent(SDL_Event * event) Line 325 + 0xb bytes C
bitfighter.exe!Zap::idle() Line 467 + 0xc bytes C++
bitfighter.exe!Zap::dedicatedServerLoop() Line 498 + 0x5 bytes C++
bitfighter.exe!SDL_main(int argc, char * * argv) Line 1267 C++
bitfighter.exe!main(int argc, char * * argv) Line 145 + 0xd bytes C
bitfighter.exe!__tmainCRTStartup() Line 278 + 0x19 bytes C
bitfighter.exe!mainCRTStartup() Line 189 C
kernel32.dll!7c817067()
—snap—
Any ideas?
Thanks!
DavidOn Sun, May 26, 2013 at 10:20 PM, Sam Lantinga wrote:
I just updated to the latest changeset (7970a2839280) and am using a Debug
build of SDL2 with my game on Windows XP.
I just noticed that when changing from fullscreen mode to windowed again,
the window freezes and the CPU spikes. It seems to be an error deep within
SDL_PumpEvents(). I change the window by calling:
SDL2.dll!WIN_WindowProc(HWND__ * hwnd, unsigned int msg, unsigned int
wParam, long lParam) Line 277 + 0xf bytes C
user32.dll!7e418734()
user32.dll!7e418816()
user32.dll!7e42a013()
user32.dll!7e42a039()
opengl32.dll!5ed2699b()
user32.dll!7e418734()
user32.dll!7e418734()
user32.dll!7e418816()
user32.dll!7e428ea0()
user32.dll!7e428eec()
ntdll.dll!7c90e453()
user32.dll!7e4194d2()
user32.dll!7e428f10()
user32.dll!7e419402()
user32.dll!7e418a10()
SDL2.dll!WIN_PumpEvents(SDL_VideoDevice * _this) Line 774 C
SDL2.dll!SDL_PumpEvents() Line 310 + 0xf bytes C
SDL2.dll!SDL_WaitEventTimeout(SDL_Event * event, int timeout) Line 344
C
SDL2.dll!SDL_PollEvent(SDL_Event * event) Line 325 + 0xb bytes C
bitfighter.exe!Zap::idle() Line 467 + 0xc bytes C++
bitfighter.exe!Zap::dedicatedServerLoop() Line 498 + 0x5 bytes C++
bitfighter.exe!SDL_main(int argc, char * * argv) Line 1267 C++
bitfighter.exe!main(int argc, char * * argv) Line 145 + 0xd bytes C
bitfighter.exe!__tmainCRTStartup() Line 278 + 0x19 bytes C
bitfighter.exe!mainCRTStartup() Line 189 C
kernel32.dll!7c817067()
—snap—
Any ideas?
Thanks!
David
On Sun, May 26, 2013 at 10:20 PM, Sam Lantinga <@slouken> wrote:
Oh neat! I had no idea you could do that! (I’m normally a Linux user.)
Here is the same trace: when I pause the application after it spikes the
CPU:
—snip—
ntdll.dll!_KiFastSystemCallRet at 0()
ntdll.dll!_ZwFindAtom at 12() + 0xc bytes
kernel32.dll!_InternalFindAtom at 12() + 0x9c bytes
kernel32.dll!_GlobalFindAtomW at 4() + 0x11 bytes
user32.dll!_GetPropW at 8() + 0x4108 bytes
SDL2.dll!WIN_WindowProc(HWND__ * hwnd, unsigned int msg, unsigned int
wParam, long lParam) Line 277 + 0xf bytes C
user32.dll!_InternalCallWinProc at 20() + 0x28 bytes
user32.dll!_UserCallWinProcCheckWow at 32() + 0xb7 bytes
user32.dll!_CallWindowProcAorW at 24() + 0x51 bytes
user32.dll!_CallWindowProcW at 20() + 0x1b bytes
opengl32.dll!_wglWndProc at 16() + 0x21b bytes
user32.dll!_InternalCallWinProc at 20() + 0x28 bytes
user32.dll!_UserCallWinProcCheckWow at 32() + 0xb7 bytes
user32.dll!_DispatchClientMessage at 20() + 0x4d bytes
user32.dll!___fnDWORD at 4() + 0x24 bytes
ntdll.dll!_KiUserCallbackDispatcher at 12() + 0x13 bytes
user32.dll!_NtUserDispatchMessage at 4() + 0xc bytes
user32.dll!_DispatchMessageW at 4() + 0xf bytes
SDL2.dll!WIN_PumpEvents(SDL_VideoDevice * _this) Line 774 C
SDL2.dll!SDL_PumpEvents() Line 310 + 0xf bytes C
SDL2.dll!SDL_WaitEventTimeout(SDL_Event * event, int timeout) Line
344 C
SDL2.dll!SDL_PollEvent(SDL_Event * event) Line 325 + 0xb bytes C
bitfighter.exe!Zap::idle() Line 467 + 0xc bytes C++
bitfighter.exe!Zap::dedicatedServerLoop() Line 498 + 0x5 bytes C++
bitfighter.exe!SDL_main(int argc, char * * argv) Line 1267 C++
bitfighter.exe!main(int argc, char * * argv) Line 145 + 0xd bytes C
bitfighter.exe!__tmainCRTStartup() Line 278 + 0x19 bytes C
bitfighter.exe!mainCRTStartup() Line 189 C
kernel32.dll!_BaseProcessStart at 4() + 0x23 bytes
—snap—On Tue, Jun 4, 2013 at 10:15 PM, Sam Lantinga wrote:
On Mon, Jun 3, 2013 at 11:18 PM, D B <@D_B> wrote:
Hi,
I just updated to the latest changeset (7970a2839280) and am using a
Debug build of SDL2 with my game on Windows XP.
I just noticed that when changing from fullscreen mode to windowed again,
the window freezes and the CPU spikes. It seems to be an error deep within
SDL_PumpEvents(). I change the window by calling:
SDL2.dll!WIN_WindowProc(HWND__ * hwnd, unsigned int msg, unsigned
int wParam, long lParam) Line 277 + 0xf bytes C
user32.dll!7e418734()
user32.dll!7e418816()
user32.dll!7e42a013()
user32.dll!7e42a039()
opengl32.dll!5ed2699b()
user32.dll!7e418734()
user32.dll!7e418734()
user32.dll!7e418816()
user32.dll!7e428ea0()
user32.dll!7e428eec()
ntdll.dll!7c90e453()
user32.dll!7e4194d2()
user32.dll!7e428f10()
user32.dll!7e419402()
user32.dll!7e418a10()
SDL2.dll!WIN_PumpEvents(SDL_VideoDevice * _this) Line 774 C
SDL2.dll!SDL_PumpEvents() Line 310 + 0xf bytes C
SDL2.dll!SDL_WaitEventTimeout(SDL_Event * event, int timeout) Line
344 C
SDL2.dll!SDL_PollEvent(SDL_Event * event) Line 325 + 0xb bytes C
bitfighter.exe!Zap::idle() Line 467 + 0xc bytes C++
bitfighter.exe!Zap::dedicatedServerLoop() Line 498 + 0x5 bytes C++
bitfighter.exe!SDL_main(int argc, char * * argv) Line 1267 C++
bitfighter.exe!main(int argc, char * * argv) Line 145 + 0xd bytes C
bitfighter.exe!__tmainCRTStartup() Line 278 + 0x19 bytes C
bitfighter.exe!mainCRTStartup() Line 189 C
kernel32.dll!7c817067()
—snap—
Any ideas?
Thanks!
David
On Sun, May 26, 2013 at 10:20 PM, Sam Lantinga wrote:
Hmm, nothing suspicious there, at least offhand. I’m guessing there’s a
spam of a huge number of windows messages. You could turn on the logging
to see what’s happening (look for WMMSG_DEBUG in SDL_windowsevents.c)
Oh neat! I had no idea you could do that! (I’m normally a Linux user.)
Here is the same trace: when I pause the application after it spikes the
CPU:
—snip—
ntdll.dll!_KiFastSystemCallRet at 0()
ntdll.dll!_ZwFindAtom at 12() + 0xc bytes
kernel32.dll!_InternalFindAtom at 12() + 0x9c bytes
kernel32.dll!_GlobalFindAtomW at 4() + 0x11 bytes
user32.dll!_GetPropW at 8() + 0x4108 bytes
SDL2.dll!WIN_WindowProc(HWND__ * hwnd, unsigned int msg, unsigned int
wParam, long lParam) Line 277 + 0xf bytes C
user32.dll!_InternalCallWinProc at 20() + 0x28 bytes
user32.dll!_UserCallWinProcCheckWow at 32() + 0xb7 bytes
user32.dll!_CallWindowProcAorW at 24() + 0x51 bytes
user32.dll!_CallWindowProcW at 20() + 0x1b bytes
opengl32.dll!_wglWndProc at 16() + 0x21b bytes
user32.dll!_InternalCallWinProc at 20() + 0x28 bytes
user32.dll!_UserCallWinProcCheckWow at 32() + 0xb7 bytes
user32.dll!_DispatchClientMessage at 20() + 0x4d bytes
user32.dll!___fnDWORD at 4() + 0x24 bytes
ntdll.dll!_KiUserCallbackDispatcher at 12() + 0x13 bytes
user32.dll!_NtUserDispatchMessage at 4() + 0xc bytes
user32.dll!_DispatchMessageW at 4() + 0xf bytes
SDL2.dll!WIN_PumpEvents(SDL_VideoDevice * _this) Line 774 C
SDL2.dll!SDL_PumpEvents() Line 310 + 0xf bytes C
SDL2.dll!SDL_WaitEventTimeout(SDL_Event * event, int timeout) Line
344 C
SDL2.dll!SDL_PollEvent(SDL_Event * event) Line 325 + 0xb bytes C
bitfighter.exe!Zap::idle() Line 467 + 0xc bytes C++
bitfighter.exe!Zap::dedicatedServerLoop() Line 498 + 0x5 bytes C++
bitfighter.exe!SDL_main(int argc, char * * argv) Line 1267 C++
bitfighter.exe!main(int argc, char * * argv) Line 145 + 0xd bytes
C
bitfighter.exe!__tmainCRTStartup() Line 278 + 0x19 bytes C
bitfighter.exe!mainCRTStartup() Line 189 C
kernel32.dll!_BaseProcessStart at 4() + 0x23 bytes
—snap—
On Tue, Jun 4, 2013 at 10:15 PM, Sam Lantinga <@slouken> wrote:
I just updated to the latest changeset (7970a2839280) and am using a
Debug build of SDL2 with my game on Windows XP.
I just noticed that when changing from fullscreen mode to windowed
again, the window freezes and the CPU spikes. It seems to be an error deep
within SDL_PumpEvents(). I change the window by calling:
SDL2.dll!WIN_WindowProc(HWND__ * hwnd, unsigned int msg, unsigned
int wParam, long lParam) Line 277 + 0xf bytes C
user32.dll!7e418734()
user32.dll!7e418816()
user32.dll!7e42a013()
user32.dll!7e42a039()
opengl32.dll!5ed2699b()
user32.dll!7e418734()
user32.dll!7e418734()
user32.dll!7e418816()
user32.dll!7e428ea0()
user32.dll!7e428eec()
ntdll.dll!7c90e453()
user32.dll!7e4194d2()
user32.dll!7e428f10()
user32.dll!7e419402()
user32.dll!7e418a10()
SDL2.dll!WIN_PumpEvents(SDL_VideoDevice * _this) Line 774 C
SDL2.dll!SDL_PumpEvents() Line 310 + 0xf bytes C
SDL2.dll!SDL_WaitEventTimeout(SDL_Event * event, int timeout) Line
344 C
SDL2.dll!SDL_PollEvent(SDL_Event * event) Line 325 + 0xb bytes C
bitfighter.exe!Zap::idle() Line 467 + 0xc bytes C++
bitfighter.exe!Zap::dedicatedServerLoop() Line 498 + 0x5 bytes C++
bitfighter.exe!SDL_main(int argc, char * * argv) Line 1267 C++
bitfighter.exe!main(int argc, char * * argv) Line 145 + 0xd bytes C
bitfighter.exe!__tmainCRTStartup() Line 278 + 0x19 bytes C
bitfighter.exe!mainCRTStartup() Line 189 C
kernel32.dll!7c817067()
—snap—
Any ideas?
Thanks!
David
On Sun, May 26, 2013 at 10:20 PM, Sam Lantinga <@slouken>wrote:
Seems like an infinite loop somewhere… I am unfamiliar with Windows
calls.
Am I supposed to be reverting from full screen mode in a different manner?
Thanks!On Wed, Jun 5, 2013 at 12:46 AM, Sam Lantinga wrote:
Hmm, nothing suspicious there, at least offhand. I’m guessing there’s a
spam of a huge number of windows messages. You could turn on the logging
to see what’s happening (look for WMMSG_DEBUG in SDL_windowsevents.c)
You can also try out a profiling tool to see what’s going on:
On Tue, Jun 4, 2013 at 10:11 PM, D B <@D_B> wrote:
Oh neat! I had no idea you could do that! (I’m normally a Linux user.)
Here is the same trace: when I pause the application after it spikes the
CPU:
—snip—
ntdll.dll!_KiFastSystemCallRet at 0()
ntdll.dll!_ZwFindAtom at 12() + 0xc bytes
kernel32.dll!_InternalFindAtom at 12() + 0x9c bytes
kernel32.dll!_GlobalFindAtomW at 4() + 0x11 bytes
user32.dll!_GetPropW at 8() + 0x4108 bytes
SDL2.dll!WIN_WindowProc(HWND__ * hwnd, unsigned int msg, unsigned
int wParam, long lParam) Line 277 + 0xf bytes C
user32.dll!_InternalCallWinProc at 20() + 0x28 bytes
user32.dll!_UserCallWinProcCheckWow at 32() + 0xb7 bytes
user32.dll!_CallWindowProcAorW at 24() + 0x51 bytes
user32.dll!_CallWindowProcW at 20() + 0x1b bytes
opengl32.dll!_wglWndProc at 16() + 0x21b bytes
user32.dll!_InternalCallWinProc at 20() + 0x28 bytes
user32.dll!_UserCallWinProcCheckWow at 32() + 0xb7 bytes
user32.dll!_DispatchClientMessage at 20() + 0x4d bytes
user32.dll!___fnDWORD at 4() + 0x24 bytes
ntdll.dll!_KiUserCallbackDispatcher at 12() + 0x13 bytes
user32.dll!_NtUserDispatchMessage at 4() + 0xc bytes
user32.dll!_DispatchMessageW at 4() + 0xf bytes
SDL2.dll!WIN_PumpEvents(SDL_VideoDevice * _this) Line 774 C
SDL2.dll!SDL_PumpEvents() Line 310 + 0xf bytes C
SDL2.dll!SDL_WaitEventTimeout(SDL_Event * event, int timeout) Line
344 C
SDL2.dll!SDL_PollEvent(SDL_Event * event) Line 325 + 0xb bytes C
bitfighter.exe!Zap::idle() Line 467 + 0xc bytes C++
bitfighter.exe!Zap::dedicatedServerLoop() Line 498 + 0x5 bytes
C++
bitfighter.exe!SDL_main(int argc, char * * argv) Line 1267 C++
bitfighter.exe!main(int argc, char * * argv) Line 145 + 0xd
bytes C
bitfighter.exe!__tmainCRTStartup() Line 278 + 0x19 bytes C
bitfighter.exe!mainCRTStartup() Line 189 C
kernel32.dll!_BaseProcessStart at 4() + 0x23 bytes
—snap—
On Tue, Jun 4, 2013 at 10:15 PM, Sam Lantinga wrote:
I just updated to the latest changeset (7970a2839280) and am using a
Debug build of SDL2 with my game on Windows XP.
I just noticed that when changing from fullscreen mode to windowed
again, the window freezes and the CPU spikes. It seems to be an error deep
within SDL_PumpEvents(). I change the window by calling:
SDL2.dll!WIN_WindowProc(HWND__ * hwnd, unsigned int msg, unsigned
int wParam, long lParam) Line 277 + 0xf bytes C
user32.dll!7e418734()
user32.dll!7e418816()
user32.dll!7e42a013()
user32.dll!7e42a039()
opengl32.dll!5ed2699b()
user32.dll!7e418734()
user32.dll!7e418734()
user32.dll!7e418816()
user32.dll!7e428ea0()
user32.dll!7e428eec()
ntdll.dll!7c90e453()
user32.dll!7e4194d2()
user32.dll!7e428f10()
user32.dll!7e419402()
user32.dll!7e418a10()
SDL2.dll!WIN_PumpEvents(SDL_VideoDevice * _this) Line 774 C
SDL2.dll!SDL_PumpEvents() Line 310 + 0xf bytes C
SDL2.dll!SDL_WaitEventTimeout(SDL_Event * event, int timeout) Line
344 C
SDL2.dll!SDL_PollEvent(SDL_Event * event) Line 325 + 0xb bytes C
bitfighter.exe!Zap::idle() Line 467 + 0xc bytes C++
bitfighter.exe!Zap::dedicatedServerLoop() Line 498 + 0x5 bytes C++
bitfighter.exe!SDL_main(int argc, char * * argv) Line 1267 C++
bitfighter.exe!main(int argc, char * * argv) Line 145 + 0xd bytes C
bitfighter.exe!__tmainCRTStartup() Line 278 + 0x19 bytes C
bitfighter.exe!mainCRTStartup() Line 189 C
kernel32.dll!7c817067()
—snap—
Any ideas?
Thanks!
David
On Sun, May 26, 2013 at 10:20 PM, Sam Lantinga wrote:
Seems like an infinite loop somewhere… I am unfamiliar with Windows
calls.
Am I supposed to be reverting from full screen mode in a different manner?
Thanks!
On Wed, Jun 5, 2013 at 12:46 AM, Sam Lantinga wrote:
Hmm, nothing suspicious there, at least offhand. I’m guessing there’s a
spam of a huge number of windows messages. You could turn on the logging
to see what’s happening (look for WMMSG_DEBUG in SDL_windowsevents.c)
You can also try out a profiling tool to see what’s going on:
On Tue, Jun 4, 2013 at 10:11 PM, D B <@D_B> wrote:
Oh neat! I had no idea you could do that! (I’m normally a Linux user.)
Here is the same trace: when I pause the application after it spikes the
CPU:
—snip—
ntdll.dll!_KiFastSystemCallRet at 0()
ntdll.dll!_ZwFindAtom at 12() + 0xc bytes
kernel32.dll!_InternalFindAtom at 12() + 0x9c bytes
kernel32.dll!_GlobalFindAtomW at 4() + 0x11 bytes
user32.dll!_GetPropW at 8() + 0x4108 bytes
SDL2.dll!WIN_WindowProc(HWND__ * hwnd, unsigned int msg, unsigned
int wParam, long lParam) Line 277 + 0xf bytes C
user32.dll!_InternalCallWinProc at 20() + 0x28 bytes
user32.dll!_UserCallWinProcCheckWow at 32() + 0xb7 bytes
user32.dll!_CallWindowProcAorW at 24() + 0x51 bytes
user32.dll!_CallWindowProcW at 20() + 0x1b bytes
opengl32.dll!_wglWndProc at 16() + 0x21b bytes
user32.dll!_InternalCallWinProc at 20() + 0x28 bytes
user32.dll!_UserCallWinProcCheckWow at 32() + 0xb7 bytes
user32.dll!_DispatchClientMessage at 20() + 0x4d bytes
user32.dll!___fnDWORD at 4() + 0x24 bytes
ntdll.dll!_KiUserCallbackDispatcher at 12() + 0x13 bytes
user32.dll!_NtUserDispatchMessage at 4() + 0xc bytes
user32.dll!_DispatchMessageW at 4() + 0xf bytes
SDL2.dll!WIN_PumpEvents(SDL_VideoDevice * _this) Line 774 C
SDL2.dll!SDL_PumpEvents() Line 310 + 0xf bytes C
SDL2.dll!SDL_WaitEventTimeout(SDL_Event * event, int timeout) Line
344 C
SDL2.dll!SDL_PollEvent(SDL_Event * event) Line 325 + 0xb bytes C
bitfighter.exe!Zap::idle() Line 467 + 0xc bytes C++
bitfighter.exe!Zap::dedicatedServerLoop() Line 498 + 0x5 bytes
C++
bitfighter.exe!SDL_main(int argc, char * * argv) Line 1267 C++
bitfighter.exe!main(int argc, char * * argv) Line 145 + 0xd
bytes C
bitfighter.exe!__tmainCRTStartup() Line 278 + 0x19 bytes C
bitfighter.exe!mainCRTStartup() Line 189 C
kernel32.dll!_BaseProcessStart at 4() + 0x23 bytes
—snap—
On Tue, Jun 4, 2013 at 10:15 PM, Sam Lantinga wrote:
I just updated to the latest changeset (7970a2839280) and am using a
Debug build of SDL2 with my game on Windows XP.
I just noticed that when changing from fullscreen mode to windowed
again, the window freezes and the CPU spikes. It seems to be an error deep
within SDL_PumpEvents(). I change the window by calling:
SDL2.dll!WIN_WindowProc(HWND__ * hwnd, unsigned int msg, unsigned
int wParam, long lParam) Line 277 + 0xf bytes C
user32.dll!7e418734()
user32.dll!7e418816()
user32.dll!7e42a013()
user32.dll!7e42a039()
opengl32.dll!5ed2699b()
user32.dll!7e418734()
user32.dll!7e418734()
user32.dll!7e418816()
user32.dll!7e428ea0()
user32.dll!7e428eec()
ntdll.dll!7c90e453()
user32.dll!7e4194d2()
user32.dll!7e428f10()
user32.dll!7e419402()
user32.dll!7e418a10()
SDL2.dll!WIN_PumpEvents(SDL_VideoDevice * _this) Line 774 C
SDL2.dll!SDL_PumpEvents() Line 310 + 0xf bytes C
SDL2.dll!SDL_WaitEventTimeout(SDL_Event * event, int timeout) Line
344 C
SDL2.dll!SDL_PollEvent(SDL_Event * event) Line 325 + 0xb bytes C
bitfighter.exe!Zap::idle() Line 467 + 0xc bytes C++
bitfighter.exe!Zap::dedicatedServerLoop() Line 498 + 0x5 bytes C++
bitfighter.exe!SDL_main(int argc, char * * argv) Line 1267 C++
bitfighter.exe!main(int argc, char * * argv) Line 145 + 0xd bytes C
bitfighter.exe!__tmainCRTStartup() Line 278 + 0x19 bytes C
bitfighter.exe!mainCRTStartup() Line 189 C
kernel32.dll!7c817067()
—snap—
Any ideas?
Thanks!
David
On Sun, May 26, 2013 at 10:20 PM, Sam Lantinga wrote:
Seems like an infinite loop somewhere… I am unfamiliar with Windows
calls.
Am I supposed to be reverting from full screen mode in a different manner?
Thanks!
On Wed, Jun 5, 2013 at 12:46 AM, Sam Lantinga <@slouken> wrote:
Hmm, nothing suspicious there, at least offhand. I’m guessing there’s a
spam of a huge number of windows messages. You could turn on the logging
to see what’s happening (look for WMMSG_DEBUG in SDL_windowsevents.c)
You can also try out a profiling tool to see what’s going on:
Oh neat! I had no idea you could do that! (I’m normally a Linux user.)
Here is the same trace: when I pause the application after it spikes the
CPU:
—snip—
ntdll.dll!_KiFastSystemCallRet at 0()
ntdll.dll!_ZwFindAtom at 12() + 0xc bytes
kernel32.dll!_InternalFindAtom at 12() + 0x9c bytes
kernel32.dll!_GlobalFindAtomW at 4() + 0x11 bytes
user32.dll!_GetPropW at 8() + 0x4108 bytes
SDL2.dll!WIN_WindowProc(HWND__ * hwnd, unsigned int msg, unsigned
int wParam, long lParam) Line 277 + 0xf bytes C
user32.dll!_InternalCallWinProc at 20() + 0x28 bytes
user32.dll!_UserCallWinProcCheckWow at 32() + 0xb7 bytes
user32.dll!_CallWindowProcAorW at 24() + 0x51 bytes
user32.dll!_CallWindowProcW at 20() + 0x1b bytes
opengl32.dll!_wglWndProc at 16() + 0x21b bytes
user32.dll!_InternalCallWinProc at 20() + 0x28 bytes
user32.dll!_UserCallWinProcCheckWow at 32() + 0xb7 bytes
user32.dll!_DispatchClientMessage at 20() + 0x4d bytes
user32.dll!___fnDWORD at 4() + 0x24 bytes
ntdll.dll!_KiUserCallbackDispatcher at 12() + 0x13 bytes
user32.dll!_NtUserDispatchMessage at 4() + 0xc bytes
user32.dll!_DispatchMessageW at 4() + 0xf bytes
SDL2.dll!WIN_PumpEvents(SDL_VideoDevice * _this) Line 774 C
SDL2.dll!SDL_PumpEvents() Line 310 + 0xf bytes C
SDL2.dll!SDL_WaitEventTimeout(SDL_Event * event, int timeout) Line
344 C
SDL2.dll!SDL_PollEvent(SDL_Event * event) Line 325 + 0xb bytes C
bitfighter.exe!Zap::idle() Line 467 + 0xc bytes C++
bitfighter.exe!Zap::dedicatedServerLoop() Line 498 + 0x5 bytes
C++
bitfighter.exe!SDL_main(int argc, char * * argv) Line 1267 C++
bitfighter.exe!main(int argc, char * * argv) Line 145 + 0xd
bytes C
bitfighter.exe!__tmainCRTStartup() Line 278 + 0x19 bytes C
bitfighter.exe!mainCRTStartup() Line 189 C
kernel32.dll!_BaseProcessStart at 4() + 0x23 bytes
—snap—
On Tue, Jun 4, 2013 at 10:15 PM, Sam Lantinga <@slouken>wrote:
I just updated to the latest changeset (7970a2839280) and am using a
Debug build of SDL2 with my game on Windows XP.
I just noticed that when changing from fullscreen mode to windowed
again, the window freezes and the CPU spikes. It seems to be an error deep
within SDL_PumpEvents(). I change the window by calling:
SDL2.dll!WIN_WindowProc(HWND__ * hwnd, unsigned int msg, unsigned
int wParam, long lParam) Line 277 + 0xf bytes C
user32.dll!7e418734()
user32.dll!7e418816()
user32.dll!7e42a013()
user32.dll!7e42a039()
opengl32.dll!5ed2699b()
user32.dll!7e418734()
user32.dll!7e418734()
user32.dll!7e418816()
user32.dll!7e428ea0()
user32.dll!7e428eec()
ntdll.dll!7c90e453()
user32.dll!7e4194d2()
user32.dll!7e428f10()
user32.dll!7e419402()
user32.dll!7e418a10()
SDL2.dll!WIN_PumpEvents(SDL_VideoDevice * _this) Line 774 C
SDL2.dll!SDL_PumpEvents() Line 310 + 0xf bytes C
SDL2.dll!SDL_WaitEventTimeout(SDL_Event * event, int timeout) Line
344 C
SDL2.dll!SDL_PollEvent(SDL_Event * event) Line 325 + 0xb bytes C
bitfighter.exe!Zap::idle() Line 467 + 0xc bytes C++
bitfighter.exe!Zap::dedicatedServerLoop() Line 498 + 0x5 bytes C++
bitfighter.exe!SDL_main(int argc, char * * argv) Line 1267 C++
bitfighter.exe!main(int argc, char * * argv) Line 145 + 0xd bytes C
bitfighter.exe!__tmainCRTStartup() Line 278 + 0x19 bytes C
bitfighter.exe!mainCRTStartup() Line 189 C
kernel32.dll!7c817067()
—snap—
Any ideas?
Thanks!
David
On Sun, May 26, 2013 at 10:20 PM, Sam Lantinga <@slouken>wrote:
I have tried all last night and this morning to get a simple test program,
but to no avail. I did turn on WMMSG_DEBUG and I got a 1MB file in a few
seconds with calls like this:
Received windows message: 000B0352 WM_PAINT – 0x0, 0x0
CPU stayed locked up and it looks like SDL was stuck in the while loop in
WIN_PumpEvents() at SDL_windowsevents.c
Any further suggestions?
Thanks!
DOn Wed, Jun 5, 2013 at 9:47 PM, Sam Lantinga wrote:
Great, can you report a bug in bugzilla with a little program to help us
reproduce it and fix this? http://bugzilla.libsdl.org
Thanks!
On Tue, Jun 4, 2013 at 11:58 PM, D B <@D_B> wrote:
I used a neat tools called ‘Sleepy’ to profile. Here are my results in
picture form:
Seems like an infinite loop somewhere… I am unfamiliar with Windows
calls.
Am I supposed to be reverting from full screen mode in a different manner?
Thanks!
On Wed, Jun 5, 2013 at 12:46 AM, Sam Lantinga wrote:
Hmm, nothing suspicious there, at least offhand. I’m guessing there’s a
spam of a huge number of windows messages. You could turn on the logging
to see what’s happening (look for WMMSG_DEBUG in SDL_windowsevents.c)
You can also try out a profiling tool to see what’s going on:
Oh neat! I had no idea you could do that! (I’m normally a Linux user.)
Here is the same trace: when I pause the application after it spikes
the CPU:
—snip—
ntdll.dll!_KiFastSystemCallRet at 0()
ntdll.dll!_ZwFindAtom at 12() + 0xc bytes
kernel32.dll!_InternalFindAtom at 12() + 0x9c bytes
kernel32.dll!_GlobalFindAtomW at 4() + 0x11 bytes
user32.dll!_GetPropW at 8() + 0x4108 bytes
SDL2.dll!WIN_WindowProc(HWND__ * hwnd, unsigned int msg, unsigned
int wParam, long lParam) Line 277 + 0xf bytes C
user32.dll!_InternalCallWinProc at 20() + 0x28 bytes
user32.dll!_UserCallWinProcCheckWow at 32() + 0xb7 bytes
user32.dll!_CallWindowProcAorW at 24() + 0x51 bytes
user32.dll!_CallWindowProcW at 20() + 0x1b bytes
opengl32.dll!_wglWndProc at 16() + 0x21b bytes
user32.dll!_InternalCallWinProc at 20() + 0x28 bytes
user32.dll!_UserCallWinProcCheckWow at 32() + 0xb7 bytes
user32.dll!_DispatchClientMessage at 20() + 0x4d bytes
user32.dll!___fnDWORD at 4() + 0x24 bytes
ntdll.dll!_KiUserCallbackDispatcher at 12() + 0x13 bytes
user32.dll!_NtUserDispatchMessage at 4() + 0xc bytes
user32.dll!_DispatchMessageW at 4() + 0xf bytes
SDL2.dll!WIN_PumpEvents(SDL_VideoDevice * _this) Line 774 C
SDL2.dll!SDL_PumpEvents() Line 310 + 0xf bytes C
SDL2.dll!SDL_WaitEventTimeout(SDL_Event * event, int timeout)
Line 344 C
SDL2.dll!SDL_PollEvent(SDL_Event * event) Line 325 + 0xb bytes
C
bitfighter.exe!Zap::idle() Line 467 + 0xc bytes C++
bitfighter.exe!Zap::dedicatedServerLoop() Line 498 + 0x5 bytes
C++
bitfighter.exe!SDL_main(int argc, char * * argv) Line 1267 C++
bitfighter.exe!main(int argc, char * * argv) Line 145 + 0xd
bytes C
bitfighter.exe!__tmainCRTStartup() Line 278 + 0x19 bytes C
bitfighter.exe!mainCRTStartup() Line 189 C
kernel32.dll!_BaseProcessStart at 4() + 0x23 bytes
—snap—
On Tue, Jun 4, 2013 at 10:15 PM, Sam Lantinga wrote:
I just updated to the latest changeset (7970a2839280) and am using a
Debug build of SDL2 with my game on Windows XP.
I just noticed that when changing from fullscreen mode to windowed
again, the window freezes and the CPU spikes. It seems to be an error deep
within SDL_PumpEvents(). I change the window by calling:
SDL2.dll!WIN_WindowProc(HWND__ * hwnd, unsigned int msg,
unsigned int wParam, long lParam) Line 277 + 0xf bytes C
user32.dll!7e418734()
user32.dll!7e418816()
user32.dll!7e42a013()
user32.dll!7e42a039()
opengl32.dll!5ed2699b()
user32.dll!7e418734()
user32.dll!7e418734()
user32.dll!7e418816()
user32.dll!7e428ea0()
user32.dll!7e428eec()
ntdll.dll!7c90e453()
user32.dll!7e4194d2()
user32.dll!7e428f10()
user32.dll!7e419402()
user32.dll!7e418a10()
SDL2.dll!WIN_PumpEvents(SDL_VideoDevice * _this) Line 774 C
SDL2.dll!SDL_PumpEvents() Line 310 + 0xf bytes C
SDL2.dll!SDL_WaitEventTimeout(SDL_Event * event, int timeout) Line
344 C
SDL2.dll!SDL_PollEvent(SDL_Event * event) Line 325 + 0xb bytes C
bitfighter.exe!Zap::idle() Line 467 + 0xc bytes C++
bitfighter.exe!Zap::dedicatedServerLoop() Line 498 + 0x5 bytes C++
bitfighter.exe!SDL_main(int argc, char * * argv) Line 1267 C++
bitfighter.exe!main(int argc, char * * argv) Line 145 + 0xd bytes
C
bitfighter.exe!__tmainCRTStartup() Line 278 + 0x19 bytes C
bitfighter.exe!mainCRTStartup() Line 189 C
kernel32.dll!7c817067()
—snap—
Any ideas?
Thanks!
David
On Sun, May 26, 2013 at 10:20 PM, Sam Lantinga wrote:
