What would be a good and reliable way to delay a few seconds between displaying two things? Preferably, cross-platform compatible.
(Sorry for the double post, but meh, I'm tired of editing and I don't think edits show up as new posts)
So far, I've seen things using timers and platform-specific methods that are far from exact and use variants of sleep().
Is there anything better?
Whatever cross-platform display framework you are using almost assuredly has timing support, use it.
If this is a console app, there isn't cross platform way to do it, so suck it up and write a couple of #IFDEFs.
Kllrnohj wrote:
Whatever cross-platform display framework you are using almost assuredly has timing support, use it.
If this is a console app, there isn't cross platform way to do it, so suck it up and write a couple of #IFDEFs.
Exactly this. If it's console. Sleep() and usleep() (or sleep(), if you prefer) works well enough.
KermMartian wrote:
Kllrnohj wrote:
Whatever cross-platform display framework you are using almost assuredly has timing support, use it.
If this is a console app, there isn't cross platform way to do it, so suck it up and write a couple of #IFDEFs.
Exactly this. If it's console. Sleep() and usleep() (or sleep(), if you prefer) works well enough.
Don't they only guarantee a minimum delay? Or is the internet lying to me? Also, for graphical games, are they bad functions to use?
Also, anybody know a thing or two about moving sprites with transparent areas around a screen?
KeithJohansen wrote:
Don't they only guarantee a minimum delay?
Or is the internet lying to me?
They don't *guarantee* squat. They don't even promise that it will sleep at all, it might immediately return.
Quote:
Also, for graphical games, are they bad functions to use?
If you *EVER* sleep in a game you're doing it wrong. You never, ever, ever call any form of sleep in a game. NEVER
Quote:
Also, anybody know a thing or two about moving sprites with transparent areas around a screen?
Depends on what graphical library you are using.
Kllrnohj wrote:
KeithJohansen wrote:
Don't they only guarantee a minimum delay?
Or is the internet lying to me?
They don't *guarantee* squat. They don't even promise that it will sleep at all, it might immediately return.
What the heck is the point of them anyway if they're so... useless?
Kllrnohj wrote:
Quote:
Also, for graphical games, are they bad functions to use?
If you *EVER* sleep in a game you're doing it wrong. You never, ever, ever call any form of sleep in a game. NEVER
Figured as much. If I want to somehow delay between the displaying of things (such as a title and a subtitle), how would I go about doing that?
Kllrnohj wrote:
Quote:
Also, anybody know a thing or two about moving sprites with transparent areas around a screen?
Depends on what graphical library you are using.
Forgot to edit this question out. I figured out for myself how to get a sprite moving around. Whether or not I did it correctly, however, is an entirely different story.
Keith, most of the time they will do what it says on the tin. I've noticed that different languages do things differently. Sleep() and sleep() in C/C++ tend to be minimums, while time.sleep() in Python is a maximum, for example.
KeithJohansen wrote:
What the heck is the point of them anyway if they're so... useless?
I didn't say they are useless, they just aren't useful for what you want. An example use of sleep is if you have to do polling because there isn't an event based option available. But as Kerm said, they usually get pretty close to the value you specified.
Quote:
Figured as much. If I want to somehow delay between the displaying of things (such as a title and a subtitle), how would I go about doing that?
So games run inside of a while(true) renderFrame() loop, more or less. So what you do is grab the most accurate available time source at the start of a frame (usually system clock in milliseconds), and you use that to figure out how much time has elapsed since the last frame and thus how much you need to increment all your various animations.
So if you want to show the title, and then 5 seconds later show a subtitle, you'd do something like the following:
Frame 1: drawTitle, set trigger for now + 5000ms (this can be as simple as a list of structs you keep that just has the time to trigger, and a callback function)
Frame 2: check for expired triggers
Frame 3: check for expired triggers
Frame 4-500: ditto
Frame 501: now > trigger, drawSubtitle now starts rendering too
To be clear, the triggers I talk about are something YOU create and manage, not something provided by some API. This sort of thing is usually very engine specific (as it is deeply tied into the animation framework and game logic processing and such), so a general timing solution is not what you want.
And since your scene is probably going to be very simple and thus render very quickly, you will probably want to limit the frame rate - which is where sleep can come into play 
Ideally you would just use triple buffering + vsync, which solves various other issues, but you could even just do something simple like calculate how long it took you to render the frame, and then sleep for <render_time> - 1000/<target_fps>. So if it took you 10ms to render, and you want a limit of 60FPS (or 16.6667ms per frame), you would then sleep for ~6ms after your frame renders. This is a pretty bad way to do it, but it's simple and keeps CPU usage low (which is probably the bigger issue for you - I assume you don't want your CPU pegged at 100%)
Kllrnohj wrote:
KeithJohansen wrote:
What the heck is the point of them anyway if they're so... useless?
I didn't say they are useless, they just aren't useful for what you want. An example use of sleep is if you have to do polling because there isn't an event based option available. But as Kerm said, they usually get pretty close to the value you specified.
Ah, I see. Makes sense. I stand corrected
Kllrnohj wrote:
Quote:
Figured as much. If I want to somehow delay between the displaying of things (such as a title and a subtitle), how would I go about doing that?
So games run inside of a while(true) renderFrame() loop, more or less. So what you do is grab the most accurate available time source at the start of a frame (usually system clock in milliseconds), and you use that to figure out how much time has elapsed since the last frame and thus how much you need to increment all your various animations.
So if you want to show the title, and then 5 seconds later show a subtitle, you'd do something like the following:
Frame 1: drawTitle, set trigger for now + 5000ms (this can be as simple as a list of structs you keep that just has the time to trigger, and a callback function)
Frame 2: check for expired triggers
Frame 3: check for expired triggers
Frame 4-500: ditto
Frame 501: now > trigger, drawSubtitle now starts rendering too
To be clear, the triggers I talk about are something YOU create and manage, not something provided by some API. This sort of thing is usually very engine specific (as it is deeply tied into the animation framework and game logic processing and such), so a general timing solution is not what you want.
And since your scene is probably going to be very simple and thus render very quickly, you will probably want to limit the frame rate - which is where sleep can come into play Ideally you would just use triple buffering + vsync, which solves various other issues, but you could even just do something simple like calculate how long it took you to render the frame, and then sleep for <render_time> - 1000/<target_fps>. So if it took you 10ms to render, and you want a limit of 60FPS (or 16.6667ms per frame), you would then sleep for ~6ms after your frame renders. This is a pretty bad way to do it, but it's simple and keeps CPU usage low (which is probably the bigger issue for you - I assume you don't want your CPU pegged at 100%)
Ah, I mostly get it now. Thanks for all the help, Kllrnohj
I still don't quite understand how all the frame rate stuff works (or if it's even important to think about considering how ... not intensive... my game is graphically) though.
Regardless, I'll take a stab at some trigger-based coding tomorrow morning and see how that works. I'll do some textbook reading first, though. It's always good to RTFM 
Well, since you usually want to do movement, title changing, etc based on a wallclock than on the exact number of frames rendered (since someone with a fast graphics card would of course see everything in the game go faster), you should use some precise measurement of system time in a tight loop to figure out if it's time to do the next thing yet, as demonstrated in Kllrnohj's title/subtitle example.
KeithJohansen wrote:
Ah, I mostly get it now. Thanks for all the help, Kllrnohj
I still don't quite understand how all the frame rate stuff works (or if it's even important to think about considering how ... not intensive... my game is graphically) though.
Regardless, I'll take a stab at some trigger-based coding tomorrow morning and see how that works. I'll do some textbook reading first, though. It's always good to RTFM
The switch you have to make is from thinking "I'll draw this, wait five seconds, then draw that" to "draw draw draw draw draw draw oh wait that happened we need to start drawing that too more draw more draw more draw more draw". In other words, your game needs to be more stateful, and before every frame try and figure out what happened in the last time "chunk".
Nothing can really loop. Your animations can't just loop until they are finished. So instead you process chunks of time and events at the start of each draw loop. At the beginning of the loop you figure out everything whose state needs to change. Player position needs to react to input, game events, and animations need to react to change in wallclock time.
And yes, you *DO* need to think about how all the frame rate stuff works. The goal of your computer is to do what you tell it as fast as possible. If you don't put limits on your FPS, your non-graphically intense game *will* use 100% of your CPU (or at least 100% of one core), which probably won't make you to happy. You'll be rendering dozens if not hundreds of frames that aren't shown. For your needs, the simplest would be to just flip on vsync and assume you can maintain 60FPS.
Btw, it doesn't matter at all if your game is super simple or a multi-million endeavor - it's the same rough process.
question! How exactly would I get system clock in milliseconds? I've been googling things but haven't found what I need, although I may be looking right at it and not seeing it.
Also, is this a C++ thing or can it be done in plain C as well?
KeithJohansen wrote:
question! How exactly would I get system clock in milliseconds? I've been googling things but haven't found what I need, although I may be looking right at it and not seeing it.
Your drawing library almost assuredly has a way of getting this. If not, consider something like Boost or you'll need to dig into platform specifics. The only way you will ever be cross-platform in C/C++ is by using libraries that do the hard work for you, or by writing a bunch of #ifdefs. The standard C library doesn't do much.
Quote:
Also, is this a C++ thing or can it be done in plain C as well?
It can be done in C.
@Kerm: clock() also does the wrong thing. Did you read those links yourself? http://www.manpagez.com/man/3/clock/ Clock reports *PROCESSOR* time used, not wall time. Two extremely different things.
I bothered reading the Stackoverflow page, because I used the techniques there in the gCnClient. I didn't bother researching the clock() solution, because it wasn't relevant to my application.
Edit: from the gcnclient:
Code: #ifdef WINDOWS
hidtime = GetTickCount();
#else
gettimeofday(&hidtime, NULL);
#endif
[...later...]
#ifdef WINDOWS
hidtime2 = GetTickCount();
if (hidtime2 - hidtime > USBHID_TIMEOUT*1000) {
#else
gettimeofday(&hidtime2,NULL);
if (0.5+((hidtime2.tv_sec-hidtime.tv_sec)*1000+
(hidtime2.tv_usec-hidtime.tv_usec)/1000)
> USBHID_TIMEOUT*1000) {
#endif
fprintf(stderr,"USB HID bridge stopped responding!\n");
[...more stuff...]
I figured out how to do delays using Allegro's timer features. I was pretty much just being an idiot
Structs. Anybody have any "for idiots" tutorials for them?
What do you need to know? They're "variables" in C/C++, they contain other variables or pointers. You can create arrays of structs. You can create structs and pointers to structs. Elements of structs are addressed as mystruct.x or mystruct.velocity; elements of pointers to structs are addressed as mystruct->x or mystruct->velocity.
As Tari was saying in IRC, I could use a struct to store object coordinates for use with my environment engine. How exactly would that work?
How would I store massive map information if I'm going to use structs in the above manner?
KeithJohansen wrote:
As Tari was saying in IRC, I could use a struct to store object coordinates for use with my environment engine. How exactly would that work?
How would I store massive map information if I'm going to use structs in the above manner?
First, define massive. Exactly how much information are you loading? What you may think of as "massive" may turn out to be pretty small.
Streaming data from storage is something generally only needed for major games with significant assets - something tells me yours is not one of those.
If you can't load your game world into memory, your in memory storage method is very wrong.
