red chamber dream
https://daringfireball.net/linked/2017/08/28/nypd-blue the quotes lol
Archived M2K2 Forum
Quote from ryu:
thanks for sharing!
heh, that's clever. did you throw that in as a wild guess, do rigorous testing or even learn how exactly the evnt loop works? first time I got suspicious was when I realized putting processing into that loop would (or should) mean holding a button down halts the whole game loop. I did a test doing exactly that, with a call to SDL_delay() outside the event loop. the delay actually happened every 40 runs, so it seems there's a limit coded in there already.
Code:
#define EVENT_POLL_MAX 100 // only process maximum of 100 events per loop
heh, that's clever. did you throw that in as a wild guess, do rigorous testing or even learn how exactly the evnt loop works? first time I got suspicious was when I realized putting processing into that loop would (or should) mean holding a button down halts the whole game loop. I did a test doing exactly that, with a call to SDL_delay() outside the event loop. the delay actually happened every 40 runs, so it seems there's a limit coded in there already.
I can't remember how I came up with that limit exactly. I wouldn't have thought that holding a button down would halt the loop, since you ought to get one "button pressed" event when the button goes down and then no events until the button is released again, when you get a "button released" event instead. However if you do a lot of mouse movement over the window you would probably get a lot of "mouse moved" events, so I put that limit in there to stop a flood of events from choking the game loop and consuming excessive CPU.
The other more general issue is that if you have any situation in programming where something could theoretically cause an infinite loop, it's a good idea to put in a count and a check as a "safety valve" to make sure that your program can't just freeze up. So even if (as you say) SDL has its own defences against this possibility, it's good practice to put in your own check.
Quote:
Code:
SDL_JoystickEventState(SDL_ENABLE);
was the gamcontroller feature a thing in the version of SDL you used? supposedly that does wonders to pad compatibility (assuming that isn't part of your full code since you mention good compatibility in that)
Oops. That shouldn't actually have been in the example code at all, I just copy/pasted some stuff from my actual event code. I haven't actually been using SDL2's "gamecontroller" stuff, although you're right, I probably should have been using it. I think it's because I started using SDL back in the SDL 1.0 days (probably about fourteen years ago or something -- heh), when all it had was the joystick APIs, so I have my own code which does the same job as the gamecontroller API does (except it doesn't work properly).
Quote:
Code:
Bismarck biss Mark, bis Mark Bismarck biss.
rotfl
Heh, I found that on the internet a few years ago.
Quote:
Your switch is interesting. Here's my test thing that doesn't work:
Comparing it to yours, the problem with my code must be that switching the keyboard button prevents the loop from checking the other cases. problem is I'm not even using a switch here trying to solve that lol
Code:
while(SDL_PollEvent(&sdl_event) != 0) {
if (sdl_event.type == SDL_KEYDOWN) {
if (sdl_event.key.keysym.sym == SDLK_UP) {
up++;
} else {
up = 0;
}
if (sdl_event.key.keysym.sym == SDLK_RIGHT) {
right++;
} else {
right = 0;
}
if (sdl_event.key.keysym.sym == SDLK_ESCAPE) {
quit = 1;
}
SDL_WaitEvent(&sdl_event);
}
}
if (sdl_event.type == SDL_QUIT) {
quit = 1;
}Comparing it to yours, the problem with my code must be that switching the keyboard button prevents the loop from checking the other cases. problem is I'm not even using a switch here trying to solve that lol
I think the problem is that you're calling SDL_WaitEvent(), which will block until another event becomes available, so your code will just halt inside the SDL_WaitEvent() call until another keypress or mouse event or button press arrives.
I don't think you can get round the problem of delays being unreliable. It's just the way operating systems work, they have to schedule all sorts of different processes to share the CPU and they can't guarantee that any delay you ask for will be accurate. Only RTOS (Real-Time Operating Systems) will produce guaranteed delay times, and none of the desktop OSes we use nowadays are RTOS.
SDL_Delay() will probably just call the most accurate delay function available on the OS you're currently using, which will probably be something like nanosleep() on Linux or MacOS. There will be something similar on Windows too, although I don't know the name of it.
But no, I don't think you can really get around the problem of the OS not giving you the delay you asked for. I think you have to have some separate code which measures the amount of time it takes for each loop cycle and then somehow compensates for the difference between the delay you asked for and the delay the OS actually gave you.
I can't remember exactly how I tackled this problem. I think I had some imperfect solution which sort of worked, but IIRC it was one of those things I needed to go back to and improve.
SDL_Delay() will probably just call the most accurate delay function available on the OS you're currently using, which will probably be something like nanosleep() on Linux or MacOS. There will be something similar on Windows too, although I don't know the name of it.
But no, I don't think you can really get around the problem of the OS not giving you the delay you asked for. I think you have to have some separate code which measures the amount of time it takes for each loop cycle and then somehow compensates for the difference between the delay you asked for and the delay the OS actually gave you.
I can't remember exactly how I tackled this problem. I think I had some imperfect solution which sort of worked, but IIRC it was one of those things I needed to go back to and improve.
Quote:
I think the problem is that you're calling SDL_WaitEvent(), which will block until another event becomes available, so your code will just halt inside the SDL_WaitEvent() call until another keypress or mouse event or button press arrives.
Oh wow. Think I'll try again without that in there. I can't even tell why I put it in there anyways.
I just figured out what was up with my event loop. It actually works without WaitEvent, just not in the way I wanted it to. I'm trying to count the frames a button is pressed. It registers all pressed, but only counts the latest one upwards.
Other buttons get stuck at the highest count at the time another button gets pressed as well.
Interestingly the counter takes a while to go from 1 to 2. Seems there's something going on internally to prevent an event from firing rapidly when you want to have it run only once when a button is pressed without waiting for the keyup event.
Code:
while(SDL_PollEvent(&sdl_event) != 0) {
if (sdl_event.type == SDL_QUIT)
quit = 1;
if (sdl_event.type == SDL_KEYDOWN) {
if (sdl_event.key.keysym.scancode == ukm.up) {
p1inp.up++;
}
if (sdl_event.key.keysym.scancode == ukm.right) {
p1inp.right++;
}
}
if (sdl_event.type == SDL_KEYUP) {
if (sdl_event.key.keysym.scancode == ukm.up) {
p1inp.up = 0;
}
if (sdl_event.key.keysym.scancode == ukm.right) {
p1inp.right = 0;
}
}
}Other buttons get stuck at the highest count at the time another button gets pressed as well.
Interestingly the counter takes a while to go from 1 to 2. Seems there's something going on internally to prevent an event from firing rapidly when you want to have it run only once when a button is pressed without waiting for the keyup event.
lol. they can be held as pets. imagine a bunch of them walking around your house...
no problem. my fallback solution seems to be working so far anyways. worst case I won't need the frame counter for presses either. It's just nice to have I think.
Quote:
I'm not 100% sure how SDL_PollEvent() works so I can't really help I don't think
no problem. my fallback solution seems to be working so far anyways. worst case I won't need the frame counter for presses either. It's just nice to have I think.
Probably because it really doesn't do shit. It's a place where people can post short notes, screenshots, and stupid little doodles. I just liked the tingle bottles because it cracked me up to open one up and see that some kid drew some juvenile doodle of a dick that the mods haven't caught yet. Those tingle bottles are surprisingly fun.
I'm not sure then.
I gave up staring at source code to try to find memory corruption bugs a while ago, and nowadays I just use a tool to do all the work for me. There's a great one on Linux called valgrind, which has a module called memcheck. This post suggests a few for Windows -- UMDH, Dr. Memory, Appverifier.
I gave up staring at source code to try to find memory corruption bugs a while ago, and nowadays I just use a tool to do all the work for me. There's a great one on Linux called valgrind, which has a module called memcheck. This post suggests a few for Windows -- UMDH, Dr. Memory, Appverifier.