Thread: [Dev-C++] linking to .dll's

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi all,

I need to statically link my application to a comercially provided .dll =
file. I have the .h and .lib files associated with the dll file.

How do I tell dev-cpp to link to the dll?
Hi Don and all,

Once again, I had forgotten to check if I replied to the list or not... could somebody add the
"Reply-to: Dev...@li..." field in the headers please? :)

On Thu, 26 Feb 2004 11:50:53 -0700, Don Raikes <dnr...@ho...> wrote:

>I need to statically link my application to a comercially provided .dll file.
> I have the .h and .lib files associated with the dll file.
>
>How do I tell dev-cpp to link to the dll?

I just learned recently (yeah, I'm new at this too :) ) that we can link directly with a dll.
According to the ld docs:

"The cygwin/mingw ports of ld support the direct linking, including data symbols, to a dll without
the usage of any import libraries"

"... All that is needed from the developer's perspective is an understanding of this search, in
order to force ld to select the dll instead of an import library. 

For instance, when ld is called with the argument -lxxx it will attempt to find, in the first
directory of its search path, 

libxxx.dll.a
xxx.dll.a
libxxx.a
cygxxx.dll (*)
libxxx.dll
xxx.dll"

So all that you have to do in Dev-cpp is to add the -lxxx in Project options/Parameters/Linker. I
tried it and it does work.

Hope this helps.
--
Mario B.
My Landsat images:
http://pages.infinit.net/starged/landsat/home.html

To any Win programmer listening... who would be sure better than me :)

I have this problem: I have a 3 threaded app. One thread is for timing, one
for drawing, and the last reads windows messages.

I need a working temporization. I've used both the "TimerFunc()" and the
"Sleep()" functions in the timer thread but both don't seem to be too
precise. The timer thread uses an Event object to awake the drawing thread.

I used a timeout of 20 ms and I get 32 fps (instead of 50). I've tried with
10 ms, and I get 64 fps :D instead of 1000/10 = 100...!! I know I can reach
that speed, since I draw a very simple scene, and my system can do it
(tested with other apps), and the video-refresh of my current video mode is
right 100-101 Hz.

Is there some better way to achieve decent temporization? some library that
allows using interrupts or something similar?

thanks in advance,
Emiliano

PS I need this for an OpenGL program, I've only found nasty busy-waiting
loops with "PeekMessage()" and some drawFrame() + SwapBuffers() elsewhere...
that works ok most of the time, but if you try to put your window in the
background, the CPU usage reaches instantly 100%, and that sucks!!

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.

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.

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++.

About your "strage" framerate: Windows tries to run threads for full
time slices before swapping.

/Per W

On Fri, 27 Feb 2004, Emiliano wrote:

> To any Win programmer listening... who would be sure better than me :)
>
> I have this problem: I have a 3 threaded app. One thread is for timing, one
> for drawing, and the last reads windows messages.
>
> I need a working temporization. I've used both the "TimerFunc()" and the
> "Sleep()" functions in the timer thread but both don't seem to be too
> precise. The timer thread uses an Event object to awake the drawing thread.
>
> I used a timeout of 20 ms and I get 32 fps (instead of 50). I've tried with
> 10 ms, and I get 64 fps :D instead of 1000/10 = 100...!! I know I can reach
> that speed, since I draw a very simple scene, and my system can do it
> (tested with other apps), and the video-refresh of my current video mode is
> right 100-101 Hz.
>
> Is there some better way to achieve decent temporization? some library that
> allows using interrupts or something similar?
>
> thanks in advance,
> Emiliano
>
> PS I need this for an OpenGL program, I've only found nasty busy-waiting
> loops with "PeekMessage()" and some drawFrame() + SwapBuffers() elsewhere...
> that works ok most of the time, but if you try to put your window in the
> background, the CPU usage reaches instantly 100%, and that sucks!!
>
>
>
> -------------------------------------------------------
> 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
>

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

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
>

----- 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

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
>

----- Original Message ----- 
From: "Per Westermark" <pw...@ia...>
To: "Emiliano" <sky...@fa...>
Cc: <dev...@li...>
Sent: Friday, February 27, 2004 8:18 PM
Subject: Re: [Dev-C++] WinAPI help...

> 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.

Good idea... now it only remains the key problem... the window procedure
gets the message (WK_KEYDOWN), the PostQuitMessage() is called, even
multiple times, but "GetMessage()" won't notice it at all!!

Maybe too many messages waiting?? but the WM_QUIT should be dealt with
sooner or later. Or is it lost (tragic) or bypassed??

Emiliano

Thread: [Dev-C++] linking to .dll's

Open Source C & C++ IDE for Windows

dev-cpp-users