timeBeginPeriod_()
timeEndPeriod_()
timeGetTime_()
Look up timeBeginPeriod and timeEndPeriod and timeGetTime in the PSDK or MSDN, also search these forums, I and several others have posted many examples on these.
timeGetTime is like getTicks only it uses the multimedia code in Windows and you can use timeBegindPeriod to increase the accuracy from um 15ms (on XP I think) down to ~2ms.
You might also consider putting the time stuff in it's own thread with a high priority. Myself in a program I created a timer thread set it to realtime priority and which runs in a loop with a Sleep_(1) in it and it sets a global variable with the value from timeGetTime_() and then I use a macro GetTime() that basically is a macro wrapper for the global variable.
I think I posted a example in Tips and Tricks some time ago.
The benefit of this is that the variable is updated each 1ms (remember to set the period at program start and end) or as close to 1ms as possible but your programs can use the GetTime() macro as much as you want with no additional procedure of API call overhead, only the overhead of reading a variable.
If this is overkill for your program (sounds to me like you might benefit from that particular solution actually) then you might want to redo your loop instead.
In a internet radio player I made all stuff is in the mainloop,
but the gadget checking and gfx vumeter display etc is layed out in a very efficient way.
The loop uses WaitWindowEvent(time) the time is a var that changes depending on wether the program is minimzed or not etc. (the goal is to only use as much cpu/resources as you need when you actually need it).
The code is layed out like this.
*loop start
-Was there an event?
--Yes, was it the main window?
---Yes, which gadget?
----What was the event?
-----Do gui stuff.
--No event timeout was reached, or a 0 event occured.
-Is the GUI visible (not minimized)?
--Yes, is it time yet to updated the graphics? (timer check or var check)
---Yes, draw the gui stuff
*loop end
I'm my case the audio is already in it's own playback thread thanks to BASS library so I won't have to deal with that luckily.
The graphics however will not be updated as long as GUI stuff is being processed (this is intentional to minimize CPU use) but is updated once that is done or if no GUI handling was needed at all.
My advice is get the audio stuff into it's own playback thread if you need to.
Also pay close attention to the gui stuff in the example above,
there is no point reading a trackbar unless an event happen and for that window and for that gadget. So if you are checking the trackbar everytime the loop um loops (pardon the pun) that is horrible coding, and it kinda smells like OOP and Managed coding gone wrong.
I really hope you will not continue to use the trackbar itself to store the value, read it and put it in a variable instead, only read the trackbar if you know the value has changed. As pointed out in the posts above your eating up way more cpu/resources than you truly need due to this.
Only do stuff when you actually need to do it, cache values/data wherever possible thus reducing the overhead of calling functions and procedures all the time, the less code there is inside a loop the better, prepare as much as possible before entering a loop, code inside procedures and functions etc also count as part of the code inside the loop so the less code there are inside those the faster the loop is.
With PureBasic you have the power to do this easily, lean mean code
apparently anyway
