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.

Author
Message
Code Maker
8
Years of Service
User Offline
Joined: 4th Dec 2015
Location:
Posted: 19th Jul 2017 15:48 Edited at: 22nd Jul 2017 14:03
I just made this small pice of code for use in a game i'm making,
because the load and building time of the levels got quite big,
and i thought my game needed some kind of animation while building
the next level, if for nothing else so just to indicate to the player
that the program is still active and not frozen.
So i decided to make this code snippet and create a interrupt timer
just before i enter the build level routine, and kill the interrupt
timer again just before i exit it again, this results in a small,
smoot, stabile and consistend animation while my level is building.

I am sure there is many other applications opportunities for an
interrupt timer like this.

Notes.

1.
You sould try to keep the timer delay above 10 milliseconds or
else it will overload your system, to quote MS API SDK help files
"Periodic timer events with an event delay of 10 milliseconds or less
consume a significant portion of CPU resources."

2.
The interrupt timer will bee killed if the window to which it has been
associated is closed.


Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 21st Jul 2017 11:18
That looks like a useful utility to me. Thanks for posting.

Just one small comment. I think you meant the opposite of what you actually said here:

Quote: "You sould try to keep the frequency of the interrupt timer as high as
possible or else it will overload your system, to quote MS API SDK help
files "Periodic timer events with an event delay of 10 milliseconds or
less consume a significant portion of CPU resources.""


I think you meant to say "as low as possible", i.e. as high an event delay as you can (because high frequency implies a short event delay ).
Code Maker
8
Years of Service
User Offline
Joined: 4th Dec 2015
Location:
Posted: 21st Jul 2017 15:26
Hi GG, glad you find it useful, what i ment was to keep the actual value of the integer variable "timerfreq" as high as possible
but i see how it can bee misinterpreted, i have just entered the code into the "code snippet"
section where i have clarified/reworded that.
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 21st Jul 2017 22:34
Quote: " i have just entered the code into the "code snippet"
section where i have clarified/reworded that."


I don't think you have. Your code snippet still has the same confusing comment as before - and your post doesn't show as edited.
Code Maker
8
Years of Service
User Offline
Joined: 4th Dec 2015
Location:
Posted: 30th Jul 2017 19:00
Post is now edited and code reworded for clarity
Mage
17
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 2nd Aug 2017 02:52 Edited at: 2nd Aug 2017 16:20
Thanks for contributing.
Using Windows API calls is some advanced stuff. In the interest of being constructive I will begin poking holes.

Clarification: This technique is a time based "interrupt" and is supposed to stop the program execution (to interrupt it) so that the interrupt code can be run. Then the execution returns to where the game left off and continues along like nothing happened. To be clear this is not multi-threading.


Real World Test

This code is the example code modified to load The Matrix movie in looped batches of 20 to simulate real world media loading. The program has also been modified to post the timestamps of the interrupts down the left side of the window.



The Result



As you can see there are times in milliseconds listed down the left side of the window. They are how much time passed since the first interrupt since the numbers are easier to read this way than huge long timer values.


What Does This Mean?

1. Loading media can and does delay the interrupts. Look at the times they should be 1000ms apart. They are not. So this has no real advantage over updating the screen between loaded items.

2. Delayed interrupts begin to stack up. Look at the times, many of them are grouped on the same/similar time as the interrupt before. This means that hell or high water you will execute every missed or delayed interrupt. You will delay loading more media until the program can catch up. So this is worse than traditional methods. It also means that backlogged "Interrupts" can interrupt other "Interrupts" as they stack making the program potentially unstable. I didn't test for it, but I would likely see some of those grouped Interrupts are out of order.

3. I have noticed that if the program crashes, this thing will make the program unresponsive and difficult to close. It interferes with the event handling of the mouse click in the error popup window. So this has compatibility problems.


Additional Gripes

4. It seems somewhat dangerous syncing the screen with media loading, in a manner where any indiscriminate place in the code could be stopped for a screen update or other things. One might expect screen oddities or even a crash in the worst case scenario. If you don't want your program to crash when the screen is locked or laptop lid is closed, you have to handle recovering from a loss of screen device error. So if your interrupt updates the screen it also has to perform a recovery of all the loaded assets. Only now you have a half loaded level to recover, maybe you were mid way through setting up an asset like a character. Then the interrupt just ends and the program is supposed to pickup exactly where the loading left off. This would be a nightmare to manage. So now you are back in some function adding a shader to an object, only now the object is loaded under a different object index (if you even managed to perform a recovery) and the variable storing the objects index is wrong so the commands using it fail and the program crashes. Or you performed no recovery at all and the program crashes. You would have to load everything exactly the same even the half loaded asset whose setup was interrupted. Unrealistic.

5. There is an apparent lack of control. You are basically handing control of the visual flow over to windows.


Thoughts of actual multi-threading aside, why not just program the game to update the screen between loading items if more than 1000ms has passed since the last update?
Simpler, safer, more control, easier to read, more efficient.
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 2nd Aug 2017 18:08
Several good points there.

Login to post a reply

Server time is: 2024-02-23 07:25:40
Your offset time is: 2024-02-23 07:25:40