Way to execute code while drawing??
Author
Hi, i would like to know if there is a possible way to keep drawing images while another function run or calculates stuff... I dont know i u understand, i want my program to keep moving images while it thinks, calculates. I though maybe at the end of my draw() fonction i would place a call to another function lets say think(). So between each frame the program thinks for a while (lets say i give him 15 milisec to think) and when its over, draws the other frame, then he continues to think from where he were for another 15milisec. etc... But its going to be complicated, so i was wondering if some1 had an idea on how to do this more easily.
Thank you.
I hope u understand what i mean.
What you said, doing your own timeslicing, is going to be the easiest. You can create a new thread that will run concurrently with your main thread, but while that''s easier to start off with, it''ll be impossible to make it robust unless you know exactly what you''re doing, and even then multithreading can be tricky.
Threads might help, but they can raise far worse problems (at least with threads managed by the OS). You could create one thread that draws continuously as fast as it can and another thread that "thinks" as fast as it can, and the OS will bounce back and forth in small quanta, sending commands to the processor in small chunks and storing the results per thread. However, be warned that if both threads access the same data at any point, synchronization problems arise, and the problem becomes infinitely more complex.
If you use two threads, make sure that each thread only accesses variables disjoint from the other thread, ie. if you make the "Draw" thread deal with draw variables then insure that the "Think" thread never tries to manipulate any of the same variables, or even any variables that affect draw variables, or in anyway are related to draw variables.
The problem is this: you can never predict when the OS will jump between threads. Surprisingly, it will usually be in the middle of a command or line of code. So, if one thread tries to move an object by adding (1,1,1) to its position, and midway between the translation the other thread tries to draw the object, it could potentially be in at least three different positions, depending upon when the focus jumps. Also, if two threads try to access the same address in memory or if one thread changes the address of a variable without the other thread knowing, the app will crash and no one will understand why. These events are rare, but when the same calculations cycle through at hundreds of frames per second, they WILL occur, and more often then you might think. Trust me one this one!
For your problem, I suggest scripts instead. You can have your app draw every frame and then execute a few lines of code from a script, save the script''s state, and then repeat. This ensures that no synchronization problems arise. Read up on scripts. They are powerful tools and can make virtually any project easier, especially games.
If you use two threads, make sure that each thread only accesses variables disjoint from the other thread, ie. if you make the "Draw" thread deal with draw variables then insure that the "Think" thread never tries to manipulate any of the same variables, or even any variables that affect draw variables, or in anyway are related to draw variables.
The problem is this: you can never predict when the OS will jump between threads. Surprisingly, it will usually be in the middle of a command or line of code. So, if one thread tries to move an object by adding (1,1,1) to its position, and midway between the translation the other thread tries to draw the object, it could potentially be in at least three different positions, depending upon when the focus jumps. Also, if two threads try to access the same address in memory or if one thread changes the address of a variable without the other thread knowing, the app will crash and no one will understand why. These events are rare, but when the same calculations cycle through at hundreds of frames per second, they WILL occur, and more often then you might think. Trust me one this one!
For your problem, I suggest scripts instead. You can have your app draw every frame and then execute a few lines of code from a script, save the script''s state, and then repeat. This ensures that no synchronization problems arise. Read up on scripts. They are powerful tools and can make virtually any project easier, especially games.
OMG, first of all, thread management is easy. It does not generate problems that are infinitely complex. Sharing data between threads can be implemented in a number of ways, but why don''t you try using Semaphores first. What language are you using to program?? I can give you tips for either C++ or Java threading.
Author
Hi, thank you guys for ur reply im gonna look at both solutions and see which one will be better, but i think im gonna go with threads since anonymous poster suggested it. (he seems like a real good programer because of the other replies ive seen from him in different subject) Right now Im programming this game in C++ using VS.net, and actually, i dont know what Semaphores are. Looks like ive got some reading to do, ill look over the internet. Any1 know some good sites on threads, Semaphores and scripts?? Thanks.
quote:Original post by geez
he seems like a real good programer because of the other replies ive seen from him in different subject
Ummm, "Anonymous Poster" is the name designated to anyone who posts without first inputing a valid username. In other words, the chance of two APs in two different threads being the same person is rather low (heck, this is often true of two AP posts in just one thread).
______________________________________________________________
The Phoenix shall arise from the ashes... ThunderHawk -- ¦þ
MySite
______________________________________________________________
Author
lol! I though it was his logging but ur right : its not written "member since:.... blah blah blah" besind his name. Thanks for the remark.
[edited by - geez on March 31, 2004 1:37:22 PM]
[edited by - geez on March 31, 2004 1:37:22 PM]
quote:
Hi, thank you guys for ur reply im gonna look at both solutions and see which one will be better, but i think im gonna go with threads since anonymous poster suggested it. (he seems like a real good programer because of the other replies ive seen from him in different subject) Right now Im programming this game in C++ using VS.net, and actually, i dont know what Semaphores are. Looks like ive got some reading to do, ill look over the internet. Any1 know some good sites on threads, Semaphores and scripts?? Thanks.
I recommend not using threads unless you need to. Take a look at the nehe basecode. It has exactly the structure you r looking for; update then draw.
Threads are really only applicable in certain situations; nd no you dont need semaphores if your threads are accessing data simultaneously. There are other options like critical sections (essentially using bools to control data access), events, and mutexes.
Threads come in handy in certain situations. For example if you are accessing the disk and need to process an animation you can use a thread. In windows they are used when you have a lengthy computation but need the app to respond to the user at the same time. In a game, however, threads only cause unnecessary overhead; nd that you cant have.
If you are just starting out the most important thing is to finish the project you are working on. Dont try to over complicate things simply because you want to use something fancy; there are tons of more structural and design issues you''ll have to deal with if you''re programming a game. Thats why many video games are still written in c.
Although matrix''s advice is good if you are actually concerned about deadlines & you have to turn in a product & thus don''t want to over-complicate things, but what if you really wanna learn something new? Consider threads as you have been, they are a good thing to learn... & how better to learn them then on your own time & for a fun project. Matrix''s advice on what NOT to use threads for is also correct. You don''t need seperate threads for the "draw" & "update" portions of your game. Look into something called a game-loop, its where you do computations for 1 frame, draw that frame, & then repeat. Take a look at this thread for possible uses for threads:
<a href = "http://www.gamedev.net/community/forums/topic.asp?topic_id=206444">a thread on threads in games</a>
I have a game with several entities involved & I use seperate threads to run each of the enemy entity''s AI modules. It actually removed some bad timing issues in the game & there are nifty ways you can threads. For instance, my entities all run a path-finding routine that can take quite a while even though its optimized. So what was happening was that on the frame where they need to find a new path you would see a small pause... cus that AI module had to run. So instead of running the whole AI module in just 1 frame each time the entity had to make a decision or chance direction, I would run it in a thread & the entity would only update when it finished. That way it spread the computation out over several frames. I do it a little differently, but thats the easiest way to explain it.
<a href = "http://www.gamedev.net/community/forums/topic.asp?topic_id=206444">a thread on threads in games</a>
I have a game with several entities involved & I use seperate threads to run each of the enemy entity''s AI modules. It actually removed some bad timing issues in the game & there are nifty ways you can threads. For instance, my entities all run a path-finding routine that can take quite a while even though its optimized. So what was happening was that on the frame where they need to find a new path you would see a small pause... cus that AI module had to run. So instead of running the whole AI module in just 1 frame each time the entity had to make a decision or chance direction, I would run it in a thread & the entity would only update when it finished. That way it spread the computation out over several frames. I do it a little differently, but thats the easiest way to explain it.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement