Re: [Dev-C++] WinAPI help...

[Per W. <pw...@ia...>]

I don't think that you should run run your drawing code in
THREAD_PRIORITY_IDLE - it should be THREAD_PRIORITY_BELOW_NORMAL or
THREAD_PRIORITY_LOWEST, since you don't want any background processing on
the machine to starve the drawing code.

Why don't you remove the timer thread, since the work may easily be
performed in the drawing thread? I don't have the exact specifications
available right now, but for WinNT, Win2k, WinXP... you may also use
waitable timers to implement delays.

See CreateWaitableTimer, SetWaitableTimer, WaitForSingleObject,
WaitForMultipleObjects...

When your application is minimized, you really should teach your drawing
thread to just sleep.

/Per W

On Fri, 27 Feb 2004, Emiliano wrote:

>
> First of all, thank you again for your precious hints.
>
> ----- Original Message -----
> From: "Per Westermark" <pw...@ia...>
> To: "Emiliano" <sky...@fa...>
> Cc: <dev...@li...>
> Sent: Friday, February 27, 2004 4:30 PM
> Subject: Re: [Dev-C++] WinAPI help...
>
>
> > Unless this is a movie viewer or similar, where the drawed material
> > requires a fixed frame rate, you shouldn't create the code for a fixed
> > frame rate, since you can't know the speed of the machine, and amount of
> > other programs currently needing processing time.
>
> No, I need just to update the 3d world at regular time intervals. Of course,
> the updating function is supposed to be simple and fast.
>
> > You might use GetTickCount() to getch which millisecond you started draw.
> > When the thread has drawn everything, it calls  GetTickCount() again. The
> > difference between these two represents number of used ms. You may then
> > Sleep(xx-consumed) ms. Call GetTickCount() and check how lock you slept
> > since all you know is that the program slept >= xx-consumed.
> > The disadvantage with the above solution is that if the drawing takes >=
> > allowed time, the machine will spend 100% of available capacity drawing.
>
> > You might instead define that it is the sleep time between end of one
> > frame and start of drawing of next frame that should fixed.
>
> Yes, but if I'm not wrong, in this way I could have a very fast world when
> the scene is simple, and a very slow one when the scene is full of stuff.
>
> > You might also use the DirectX methods for drawing your information - they
> > have functions for synchronizing frame rates. Alas, I don't know how to
> > program with DirectX in the Dev-C++ environment. I have only tried this
> > with M$ VC++.
>
> I think DX won't work with dev-cpp, uh? :))
>
> > About your "strage" framerate: Windows tries to run threads for full
> > time slices before swapping.
>
> Thread with the timer func: "GetMessage() -> Dispatch()" (the doc says that
> with a TimerFunc, no message is posted to the thread queue... but I still
> need GetMessage() for it to work!!!)
>
> Thread handling the window: "GetMessage() -> Dispatch()"
> Thread performing the drawing: "WaitForSingleObject() -> draw()"
>
> Two more questions:
>
> 1) I have the timer running as HIGHEST priority, main task is normal and
> drawing task IDLE. Has this something to do with time slices given to each
> thread? I thougt that with Wait/GetMessage each thread went active only when
> it had a message waiting...
>
> 2) Sometime I press esc, a PostQuitMessage(0); is issued (as the debug
> output says)... but I must be losing it, since the program goes on!! Or the
> win thread goes into starvation?? I can't say.
>
> thanks again,
> Emiliano
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>