ok, take any space shooting game
2 alien ships on screen, then there's ur ship, and for sake of argument, there are 2 bullets on screen moving from the alien ships
now
i dont know much about threads, BUT im assuming that every object on screen is it's own thread?
I dont know anything about game programming, but i doubt multiple moving objects is done by threading. Its probably done by having some buffer that represents the objects on the screen and then updating each objects position in the buffer at each time increment then displaying the buffer.
I hope that made sense :/
C Code. C Code Run. Run Code Run... Please!
"Love is like a blackhole, you fall into it... then you get ripped apart"
but each of them would have to have a collision detection and what not. i dont know much about game programming either where things move at the same time... but yea
i know about buffering and double buffering and that is (dunno how to do it th0)
Multithreaded wouldn't be a good idea; too unpredictable pre-empting.
Most likely, the game works by "ticks". E.g. 60 times a second (or whatever) each object is moved and collision is checked, and the screen is drawn anew.
Threads are not guaranteed to be executed in any particular order or at any particular time. Usually all graphics are done in a single thread so that execution order and timing can be controlled.
The word rap as it applies to music is the result of a peculiar phonological rule which has stripped the word of its initial voiceless velar stop.
what if u dont need them to be done in a particular orderThis statement is completely meaningless because it attempts to generalize a platform-dependent facility - That almost always fails. You can get threads to execute in a particular order or at a particular time, if you are programming for an operating system that offers a realtime scheduler and the possbility to modify the scheduling priority of threads. [/B]
i mean, when an alien ship moves around
its basically randomly firing whereever u are
checking to see if its dead (hp<=0)
if it hits with anything else
maybe avoiding ur bullets
like i said before, i havent learned anything about threads yet (thats the next chapter of my java book... actually multithreading)
and im trying to figure some things out so that i have an idea going into the chapter.
True you can do it on some OS's, but its a bad idea to count on that being there. Many platform independent libraries contain threads with implementations specific to the current platform, and will therefore not provide any interface for scheduling threads since it is unlikely to be there.Originally posted by vVv
> Threads are not guaranteed to be executed in any particular order or at any particular time.
This statement is completely meaningless because it attempts to generalize a platform-dependent facility - That almost always fails. You can get threads to execute in a particular order or at a particular time, if you are programming for an operating system that offers a realtime scheduler and the possbility to modify the scheduling priority of threads.
As for the game, its still a good idea to use just one thread, and update a each object in that thread every time you get a callback from a timer function or something like that.
The word rap as it applies to music is the result of a peculiar phonological rule which has stripped the word of its initial voiceless velar stop.
Calculating collisions and such forth will be much easier if you progress with ZachL's approach.
Threading has many uses, and many abuses. What you are proposing in a simple game is not a good use.
Wave upon wave of demented avengers march cheerfully out of obscurity unto the dream.
wow
looks like im very clueless about threads
BTW, this wasnt for anything in general, other than for my own information. actually not even about c++, this is more java related.
so what would a multithread program be used for then?
before anyone says anything about java... i really dont like it too much. i really miss my c++ syntax
Originally posted by adrianxw
Calculating collisions and such forth will be much easier if you progress with ZachL's approach.
whats ZachLs approach
or is that in the FAQ?
Its a couple replies up.Originally posted by revelation437
whats ZachLs approach
or is that in the FAQ?
A couple uses for multithreading come immediately to mind: 1) if long calculations must be performed, separate them from the user interface so it doesn't freeze up; 2) if a problem is computationally very expensive, and can be broken into several disjoint problems, then each problem can be given its own thread, and possibly run in parallel on a separate processor. And I'm sure people around here can think of several others.
Hope that helps.
The word rap as it applies to music is the result of a peculiar phonological rule which has stripped the word of its initial voiceless velar stop.
>>> what would a multithread program be used for then
A typical application for multithreading is if you have an algorithm that does an awful lot of calculations. Once you start it going, unless you interrupt the calculations at regular intervals to see if someone pressed something, your user interface is dead.
Typically, you run your user interface in one thread, then spin off another thread to do the calculation, then the UI thread is still able to process peoples I/O.
If you get into Windows programming, you will come across a beast known as the Windows loop. Stick a long slow routine in your windows loop and you'll soon know what I'm talking about.
>>> whats Zach Ls approach
... as in Zach L's approach in this thread. Do your graphics in a single thread controlled by timers.
*** EDIT ***
You see? Zach L and I were both working on answering your question at the same time - multithreading in action!
Wave upon wave of demented avengers march cheerfully out of obscurity unto the dream.
Games are usually run in a single loop(thread)... then counting ticks if so many ticks have pass since the last update(depending on the speed of the object) then you update your objects position. You must also update the objects last time it was updated so that you can keep track of it.
zMan
Multithreading would be very poor at the graphics idea because you'd have tons of threads, all which needed to operate on the same data, and that slows you WAY down, because you have to coordinate which thread gets access to the shared data.
Essentially, if you multithreaded, you MIGHT be able to get the same performance, assuming you can manually control the timeslicing of your threads. Even then, the solution is still more complicated and error-prone.
And if threads can pre-empt each other and you can't control it, then your problem is much slower and much more complicated.
