- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
This is one of the best ones in a while.
Admin
Admin
Yea. You can use "for" delays on machines you know always use the same clock speed (0.980 Mhz on the C64). This mean also on old videogame consoles, Nintendo, Atari, etc. But I dont think is a good idea on modern ones, because the 100% CPU useage and because modern consoles sould have already proper lenguajes to code (C, C++, etc)
Just for fun, can be interesting to check how sleep is implemented on a compiler...
Admin
Unless your app is something like "Watching Paint Dry 2.0" I can't think of any reason you would make your users stare at a static screen while your for loop maxes out the CPU especially on a C64.
The trick on the C64 was to implement your own thread switching by hooking the timer interrupt (from memory). That way your little guy's legs could still dance around, or the star field could twinkle, even when nothing else was happening.
Ahhh, mutexes in 6502 assembler, those were the days...
Admin
What happens if a timezone change happens, or something else causes the system clock to change? Perhaps this function behaves better than Sleep() does (or is thread-safe when Sleep() isn't---sorry, I'm not a Windows programmer.)
Admin
<font face="tahoma,arial,helvetica,sans-serif">A "Project Manager (contractor/consultant)" would write</font>
<font face="tahoma,arial,helvetica,sans-serif">They can.
</font>
Admin
actually sleep() is not a good choice in a windows program as obviously the posted code is written for although it does give an implication like the tip of an iceberg how the rest of the design is...
Admin
Please correct me if I'm wrong (hobby programmer with rather theoretical experience in threading here) but doesn't sleep actually freeze the whole process instead of just one thread?
Admin
Well looking up:
DWORD WaitForSingleObject(
HANDLE hHandle, // handle of object to wait for
DWORD dwMilliseconds // time-out interval in milliseconds
);
MHO would be that he didn't need to create a timer at all... if he specified the second param to 60 secs (the long equ of 60secs)
Admin
(Without having read all comments) Could it be that sleep() applies to the whole process, while this WaitableTimer only halts execution of a single thread?
The function is called ExitThreadAfterDelay after all.
Admin
--Tei
Admin
The clock does not stop, it does a rollover after 24 days (ticks getting bigger than max)
Thought you all ought to know.
Captcha: shizzle
Admin
C64 interupts were probably the best out of the old 8 bit machines. You also had a couple of hardware timers you could use, or simply hooking a counter onto the raster interupt would give you sec/50 resolution.
Admin
Apart from all the silliness around not using Sleep(), I'm pretty impressed by the failure modes.
If the thread DOES manage to exit, it leaks a handle.
More interestingly, under some circumstances, the function named ExitThreadAfterDelay() may not, in fact, exit the thread at all. It will just return (but at least it closes the handle).
Any bets on whether the caller of ExitThreadAfterDelay is expecting to receive control back after the call?
Captcha - "paula", Brillant!
Admin
No.
Admin
Straight from the horses mouth:
The Sleep function suspends the execution of the current thread for a specified interval.
VOID Sleep(
DWORD dwMilliseconds // sleep time in milliseconds
);
Admin
Sleep() (note the capital S) only suspends the current thread.
Admin
... or anything even bigger that might cost you an arm...
Admin
Fun. Even more fun, judging from this post, it sounds like the fix (or possibly some other fix - not clear) may have broken timekeeping on Linux. (Wouldn't suprise me).
Admin
Just like old vga dos games, you can sync your app to the vblank (or even scanline) from the VIC chip. Assuming 60(30?) Hz video refresh rate and 525 scanlines on a NTSC display, you should be able to work out the math pretty easily for relative time between two events. There is no such thing as time of day on such a machine, and it's been a couple of years since I've played with this, but that's the basic (no pun intended) idea I've used.
Admin
Admin
If there were a "Programmer/Developer V" designation, they would write
delay(60.0);
...but, alas, there are no "Programmer/Developer V" jobs any more.
Admin
Hrm. The alternative would be to say, create an event object, pass it into WaitForSingleObject with *gasp*, a 60,000 msec timeout! Then CloseHandle() the event object...
(You can't pass in NULL for a handle into WaitForSingleObject or WaitForMultipleObjects - it returns with WAIT_FAILED).
Admin
Actually, there are valid reasons to delay a thread before closing. Especially if you are controlling stuff in teh real world (machines etc) there will be a lot of times you will have to wait some minimum before you can go on. If the 'go on' trigger is the exiting of your thread, then you might need this function in certain cases
The way it's done is really 'WTF" tho. And in in this case the need to wait is probably a WTF as well since this programmer seems to be new to the whole threading/syncing/kernel handles field :)
Admin
Definitely could be worse. I wrote a high performance app (Game) and tried to use sleep to time the frames. Turns out that sleep(1) will wait anywhere between 0 and 20 ms even if you tell windows to increase the accuracy. Just like 'timeGetTime()' will return the same value for many calls in a row, and then suddenly return a new value thats skipped a whole bunch.
Didn't solve it with waitable timers though. Just took the lazy way out - created a signal handle and then waited for n milliseconds timeout, without ever signalling it (letting it time out). Veeeryy accurate.
Admin
Now imagine a C compiler designed for it.
I imagine SDCC will autogenerate some beautiful WTF's in the future.
Admin
I've used that trick before in batch files, for example:
:loop(command that needs to be run every 10 seconds)
ping -n 10 127.0.0.1 > nul
goto loop
Admin
Wouldn't it have been easier to use a central event loop?
I don't know whether all the C64's tricks were possible, but a good many were. I had several books which described a few of these graphical effects and included floppy disks with example code. I think one of the effects was to switch the character map after every n-th HSYNC (the timing could be obtained through the video adapter's DAC registers) such that the text mode looks like a graphical mode. Another effect was to produce colored horizontal bars as previously seen in C64 games. With VGA came the possibility to use double buffering and wait for a VSYNC before switching buffers, this would entirely eliminate flicker. Obviously, many of these tricks won't work with a TFT display any more. :-)