Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Digitalfragment

In need of help understanding dlls & threads

This topic is 5743 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am not new to C++ but i am not a guru either so dont abuse me. Dlls: Is it possible to call functions in the client executable from a dll? I am trying to write a demo 3d engine that uses openGL. What i want to do, is have the rendering code in the executable file, and to have the main loop in the dll. Is this possible? Threads: I sort of know what threads are, but i have a few questions. From my understanding threads are the major part in multitasking and that applications can be multi-threaded. 1. Would it be possible to have one thread running graphics code and another thread running sound code for example? 2. Would this increase game peformance? 3. Can the threads be synchronised, ie so a sound is played and an explosion is drawn at the same time? 4. Can threads even directly communicate with each other? 5. Would this end up making the code to complex? Also another question that i have to ask out of curiosity: Which is quicker for the cpu to calculate? x = 10 * 0.5 or x = 10 / 2 Because i have been told by some that the 1st is, and some by the 2nd is.

Share this post


Link to post
Share on other sites
Advertisement
What i want to do, is have the rendering code in the executable file, and to have the main loop in the dll. Is this possible?
Lookup function pointers. That''s your best bet. Usually, though, the objective is to do things the other way around...

1. Would it be possible to have one thread running graphics code and another thread running sound code for example?
Yes.

2. Would this increase game peformance?
Not necessarily.

3. Can the threads be synchronised, ie so a sound is played and an explosion is drawn at the same time?
Yes, but why not delegate such issues to the graphics and audio subsystems which work on their own dedicated processors (GPU, sound card)?

4. Can threads even directly communicate with each other?
Sure.

5. Would this end up making the code to complex?
Not necessarily. It''s all about how you structure it.

quote:

Also another question that i have to ask out of curiosity:
Which is quicker for the cpu to calculate?

x = 10 * 0.5
or
x = 10 / 2

It depends. The first is a floating point multiplication while the second is an integer division. Division is slow, but floating point operations are slower than integer ops - or at least used to be. The final conclusion is that it doesn''t matter, because those operations are so atomic that they have little impact on overall performance. Premature optimization is the root of much evil, so code, debug, profile and then optimize.

Share this post


Link to post
Share on other sites
quote:

Also another question that i have to ask out of curiosity:
Which is quicker for the cpu to calculate?

x = 10 * 0.5
or
x = 10 / 2

Like Oluseyi said, it depends on the type of x, but any good compiler should choose the best form out of those two, IMO. If you do keep the constants, the result (5) will almost certainly be evaluated at compile-time, so it doesn''t matter. If what you meant is,

x = y * 0.5
or
x = y / 2

A smart compiler should optimize both as x = y >> 2 anyway (if x is an integer)

Cédric

Share this post


Link to post
Share on other sites
If you care about precision and/or you''re doing scientific
or numeric programming, the choice is clear. Use multiplication
when you''re dealing with floating point numbers.

In other words:


// Don''t do this!
double x = 1.0;
x /= 2.0;

// Do this instead
double x = 1.0;
x *= 0.5;




Kami no Itte ga ore ni zettai naru!

Share this post


Link to post
Share on other sites
When thinking about threads, consider that main/WinMain are also threads. It''s obvious, but it goes unsaid. What that means is that you already have experience dealing with threads at that level. A thread merely describes a path of execution within a process. It''s when you launch additional threads that issues arise. Specifically, it''s when more than one thread has an "interest" in a particular piece of data that issues arise. That is where synchronization objects come into play - semaphores, mutexes, critical sections and the like. They act like traffic cops making certain that one thread has the current right of way. Multithreading is cool - but it''s just another tool. That makes the question is it the right tool for the job? Unfortunately, there are no hard and fast answers to that question.

Share this post


Link to post
Share on other sites
Poeple often think that multithreading == faster.

That''s ... wrong. Multithreading is just a very easy way to do several things "at the same time" with different priority without having to code a process controler.

For instance, having a low priority thread to load the next map while you are playing. This will actually slow down the game, but not enough to be noticeable. The map will load very slowly. The result, you are sacrificing little percentage of overall performence to load the maps so that there is no APPARENT loading time.

The only time multithreading will actually boost performence is when you loose tremendous time waiting after resources and locks. You can use this time for usefull things in another thread.

______________________________
Oooh, you found the horadric cube!

Share this post


Link to post
Share on other sites
quote:
Original post by Oluseyi
Division is slow, but floating point operations are slower than integer ops - or at least used to be.


hm.. not really true anymore.. we''ve made a little realtime rastericer, and to get it fast, we used fixedpoint.. then we replaced the typedefs with floats, and still did the whole fixedpoint math (alot of bitshifts wich then got floatdivisions! the most terrible thing in floats:D), the result was a speed drop of about 1fps.. plugging out the float divisions (wich are known to be quite slow), and we where much faster..

integers are by no means that fast, about every major float instruction takes 1 cycle if the cpu can optimize it well.. (else about 3 or so..)

the trig funcs and those are something different.. division is slow as well, but it is on integers, too..

those results are from benches on an amd, and on a p3..

"take a look around" - limp bizkit
www.google.com

Share this post


Link to post
Share on other sites
Ok, it''s like this. If you want to see threads easily then see them as multiple instances of the WinMain() or main() function. It is a thread running until you tell it to stop. (If you are using old C functions it would be with _beginthread() and _endthread())
So, it is just a clean and easy way to do this simultaneously without having to time each and every one from one main process. Each process can communicate with every other process and you can basically do whatever you want with them.

Now DLLs are a little different. A dynamic link library is very similar to a .LIB file, meaning it contains sourcecode that is not stored in .cpp or .c files, but instead compiled into a dll and used at run-time. Windows registers every DLL-file and then if a program needs it, it uses it if:
1. The DLL is in the .exe file''s directory
2. The DLL is in Window/System
3. The DLL is in any other folder specified with PATH at startup.

Those kind of optimizations you are talking about are really ridicilous to do right now. If your game later runs slow, then you can start optimizing big things, floating point multiplication or division comes pretty much in the end when you can improve the way you render, blit and calculate collision.

Share this post


Link to post
Share on other sites
quote:
Original post by Exorcist
x = 10 * 0.5
or
x = 10 / 2


Just write a small test programm, performing 100000 or so multiplications and divisions, and measuring the time. I''d do it, but I''m just performing a dev-c++ auto-update.


_________________________
"Reality is merely an illusion, albeit a very persistent one." (Albert Einstein)
My Homepage

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!