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

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

Happy to be able to help :-)

About the use of dynamic speed in the program. In case the program has
lost a lot of time, it might be an idea to have the update code run in a
while loop and perform multiple steps before next redraw. That way the
movement in each update step is still small enough that you don't get any
extra problems with collision detections.

/Per W

On Fri, 27 Feb 2004, Emiliano wrote:

>
> ----- Original Message -----
> From: "Per Westermark" <pw...@ia...>
> To: "Emiliano" <sky...@fa...>
> Cc: <dev...@li...>
> Sent: Friday, February 27, 2004 6:13 PM
> Subject: Re: [Dev-C++] WinAPI help...
>
>
> > 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.
>
> Yes. I put that just for testing, in the first tests..
>
> > 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.
>
> Thank you!! I found that CreateWT() works quite better! Now I get 50 fps
> with a 20 msecs period, and 94 fps with 10 (well, that difference, about ~
> 0,5 msecs is accettable in a multitasking environment).
>
> Anyway, I DO need to keep drawing and updating as separate tasks. If I don't
> do this, I risk (on crowded and slow scenes) that the update won't take
> place (since the task is busy drawing the scene). This is right what happens
> with the Glut library, which has some timer functions that simply use the
> crappy "SetTimer()" (or similar). So, if you have a long task to do, the
> timer is not seen at all (you have to restart the "GetMessage()" loop,
> despite what the WinAPI docs say!!).
>
> The simplest method is probably to add to all movements, a multiply factor
> that depends on time spent between two frames. Thus, the more time passes,
> the more speed objects must have in the next frame. I think I'll implement
> this later on, since I've tried it now and it would make collision detection
> harder (ie: doesn't work as expected :D).
>
> Anyhow, I still LOOSE escape key presses sometimes... this doesn't happen
> with a single thread, why?? :(((
>
> > See CreateWaitableTimer, SetWaitableTimer, WaitForSingleObject,
> > WaitForMultipleObjects...
>
> > When your application is minimized, you really should teach your drawing
> > thread to just sleep.
>
> Yes this can be easily implemented. Anyway, it could be a feature (maybe one
> wants the rendering to go on while the app is minimized away).
>
> Thanks again, your help is really worth a lot! :)
>
> 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
>