Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / dbWait problem

Author
Message
Jamie_Leigh
7
Years of Service
User Offline
Joined: 15th Dec 2011
Location:
Posted: 10th May 2013 15:27
Hi I'm having some trouble with the dbWait() function.

Here is my code,



The problem is, When I run my code the dbWait function seems to run straight away before the sprite is even loaded and displayed.

Let me know if you need the resource and header file..

Thanks in advance.
Dragon slayer
12
Years of Service
User Offline
Joined: 3rd Nov 2006
Location: Bourbonnais Illinois
Posted: 10th May 2013 16:44
I am going to give this a shot even though I am learning C++ and GDK and I could be wrong. Someone else may jump in here and we both will learn something! I have some problems with GDK commands and may just switch to something else like SFML.

OK so here goes I am not sure how you are accessing your case statements. This code must compile for you. I see no choices for your case statements and I am not really sure how you are using them. I always figured that switch and case statements were for things like menu choices like

if case one is selected then save game, if case 2 is selected display characters. You may be using these commands in a way I have not figured out yet.

It looks like your game() function is accessed right away which has the case commands and your game splash is getting accessed right away in which the first command in the function is dbWait(5000).

To be honest, and I could be wrong I would do away with the Switch/case commands and do that in a different way or make a menu to do what you want.

Just my thoughts and I am not all that experienced with C++
Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 12th May 2013 02:48 Edited at: 12th May 2013 02:51
The problem might be that you're only calling dbSync() once before waiting. Ideally one would think this should be enough, but I seem to recall that sometimes you need to double sync before anything will show on screen (might be related to DB using double buffers, thus writing to the first while rendering the second (that hasn't been set yet) to the screen).

Try slapping in an extra dbSync() at the end of your gamesetup()-function.

Otherwise your code looks fine
A word of advice though; calling dbWait() without re-drawing the screen will cause it to appear frozen, ie. dragging it or any other windows over the screen will interfere with the image.
A better approach would be to keep on refreshing the screen and polling the system timer until it tells you the desired amount of time has passed. You can throw in calls to Sleep() in this loop with short time values as well if you want to reduce CPU-load while you're just waiting anyway.
Something like this:


With this second solution you're continously redrawing the screen, thus a blank buffer at the first frame will quickly be redrawn with the filled buffer version so you won't need an extra dbSync()-call before accessing this function.


"Why do programmers get Halloween and Christmas mixed up?"
Jamie_Leigh
7
Years of Service
User Offline
Joined: 15th Dec 2011
Location:
Posted: 13th May 2013 23:16
Thank you very much guys!

Adding another dbsync() worked great! I have gone with the time.h clock functions though due to the reasons you stated, thanks!

One more question.. On the line of code..



Is "size_t" a class from one of the new header files? Is it even a class? Is it a class defined at that moment?

Okay possibly more than one question, Thanks!
Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 14th May 2013 00:17
size_t is a typedef, that is basically an alias for a type.
I believe it is defined as a unsigned integer of the bit depth of your application (ie 4 bytes for a 32-bit application, identical to DBPro's DWORD type, or 8 bytes if you're compiling a 64-bit program).

As a matter of fact clock() returns a variable of type clock_t. This happens to be defined as the same thing as size_t, which is why the code compiles without warnings. As mentioned earlier, you could also write
, but that is a bit more verbose.
One thing to note when using typedefs is that they might change what they are defined to in a future release of whatever library they come from. While that is highly unlikely to happen for basic types like size_t, it is good to keep on using the same type even if you can use whatever happens to be typedef:ed to the same thing as shown above. The reason is that your code will then compile without frustrating type mismatch errors further down the road should the underlying types actually be changed.


"Why do programmers get Halloween and Christmas mixed up?"

Login to post a reply

Server time is: 2019-09-19 20:27:41
Your offset time is: 2019-09-19 20:27:41