 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Paul Nicholls
Guest
|
 Posted: Mon Sep 13, 2004 4:00 am Post subject: Moving physics updating into separate thread?... |
 |
|
Hi all,
at the moment I am doing some physics sim updating inside the rendering
loop of my app using code like this:
procedure UpdateSim(TimeSlice: Single);
var
fTime: Single;
DoFrame: Boolean;
begin
ProduceParticle(TimeSlice);
// if timestep is greater than framerate timestep then
// use the framerate timestep instead
if(MIN_TIMESTEP > TimeSlice)then
UpdateParticles(TimeSlice)
else
begin
fTime := MIN_TIMESTEP;
DoFrame := true;
while(DoFrame)do
begin
if ( (fTime+MIN_TIMESTEP) < TimeSlice )then
begin
// move as many times as possible in
// the time passed since last frame
UpdateParticles(MIN_TIMESTEP);
fTime := fTime + MIN_TIMESTEP;
end
else
begin
// add remaining movement, it is probably
// so small, it wont have a noticeable
// difference in the players new position
fTime := TimeSlice - fTime;
UpdateParticles(fTime);
DoFrame := false;
end;
end;
end;
end;
This just does the standard thing of breaking down the current frame
timeslice into smaller even steps and updating the sim using these smaller
chunks.
What I want to know is, is it possible to place a physics updating section
into its own thread so it works independently from the rendering code?
It seems that some game programmers have indeed done this, but I haven't
figured out how to synchronise the faster updating of the physics with the
occasional slower rendering...
Any ideas or hints would be great :-)
Thanks in advance,
Paul Nicholls (Delphi 5/6 Professional)
"The plastic veneer of civilization is easily melted in the heat of the
moment" - Paul Nicholls
[email]paul-nicholls (AT) hotmail (DOT) com[/email]
Replace '-' with '_' to reply
|
|
| Back to top |
|
 |
Rene Tschaggelar
Guest
|
| Posted: Mon Sep 13, 2004 9:18 am Post subject: Re: Moving physics updating into separate thread?... |
|
|
Paul Nicholls wrote:
| Quote: | Hi all,
at the moment I am doing some physics sim updating inside the
rendering loop of my app using code like this:
procedure UpdateSim(TimeSlice: Single);
|
[snip]
| Quote: |
What I want to know is, is it possible to place a physics updating
section into its own thread so it works independently from the
rendering code?
It seems that some game programmers have indeed done this, but I
haven't figured out how to synchronise the faster updating of the
physics with the occasional slower rendering...
Any ideas or hints would be great 
|
Yes, you can have the simulation in a seperate thread and
update the visual model occasionally. Eg by placing the data
in a record that is copied before drawing. Such that the
visual part just takes arbitrary point sets. Or you can
draw every 100th.
Rene
--
Ing.Buro R.Tschaggelar http://www.ibrtses.com
Your newsgroups @ http://www.talkto.net
|
|
| Back to top |
|
|
Nils Haeck
Guest
|
| Posted: Mon Sep 13, 2004 3:53 pm Post subject: Re: Moving physics updating into separate thread?... |
|
|
First of all, you must ensure that your physics modelling classes are
threadsafe. This usually means they are not referred to directly by your
main application, and that they do not have any global variables if you run
more than one physics thread.
Then, when you update the physics, use a call wrapped in Synchronize()
inside your physics thread.
But it is a misconception that adding threads speeds up things, it is
usually the other way around, unless you have a multi-processor machine. So
if you can avoid threads (like with code below) then do so :)
Nils
"Paul Nicholls" <.> wrote
| Quote: | Hi all,
at the moment I am doing some physics sim updating inside the
rendering
loop of my app using code like this:
procedure UpdateSim(TimeSlice: Single);
var
fTime: Single;
DoFrame: Boolean;
begin
ProduceParticle(TimeSlice);
// if timestep is greater than framerate timestep then
// use the framerate timestep instead
if(MIN_TIMESTEP > TimeSlice)then
UpdateParticles(TimeSlice)
else
begin
fTime := MIN_TIMESTEP;
DoFrame := true;
while(DoFrame)do
begin
if ( (fTime+MIN_TIMESTEP) < TimeSlice )then
begin
// move as many times as possible in
// the time passed since last frame
UpdateParticles(MIN_TIMESTEP);
fTime := fTime + MIN_TIMESTEP;
end
else
begin
// add remaining movement, it is probably
// so small, it wont have a noticeable
// difference in the players new position
fTime := TimeSlice - fTime;
UpdateParticles(fTime);
DoFrame := false;
end;
end;
end;
end;
This just does the standard thing of breaking down the current frame
timeslice into smaller even steps and updating the sim using these smaller
chunks.
What I want to know is, is it possible to place a physics updating section
into its own thread so it works independently from the rendering code?
It seems that some game programmers have indeed done this, but I haven't
figured out how to synchronise the faster updating of the physics with the
occasional slower rendering...
Any ideas or hints would be great :-)
Thanks in advance,
Paul Nicholls (Delphi 5/6 Professional)
"The plastic veneer of civilization is easily melted in the heat of the
moment" - Paul Nicholls
[email]paul-nicholls (AT) hotmail (DOT) com[/email]
Replace '-' with '_' to reply
|
|
|
| Back to top |
|
|
Paul Nicholls
Guest
|
| Posted: Mon Sep 13, 2004 10:50 pm Post subject: Re: Moving physics updating into separate thread?... |
|
|
"Rene Tschaggelar" <ee123123wqe12 (AT) sd242323 (DOT) com> wrote
| Quote: | Paul Nicholls wrote:
Hi all,
at the moment I am doing some physics sim updating inside the
rendering loop of my app using code like this:
procedure UpdateSim(TimeSlice: Single);
[snip]
What I want to know is, is it possible to place a physics updating
section into its own thread so it works independently from the
rendering code?
It seems that some game programmers have indeed done this, but I
haven't figured out how to synchronise the faster updating of the
physics with the occasional slower rendering...
Any ideas or hints would be great :-)
Yes, you can have the simulation in a seperate thread and
update the visual model occasionally. Eg by placing the data
in a record that is copied before drawing. Such that the
visual part just takes arbitrary point sets. Or you can
draw every 100th.
|
Would you have some simple pseudo code (or actual simple real code)?
I do have a physics update method in a separate thread, but I'm not sure
what to put in it...
Cheers,
Paul.
|
|
| Back to top |
|
|
Paul Nicholls
Guest
|
| Posted: Mon Sep 13, 2004 10:57 pm Post subject: Re: Moving physics updating into separate thread?... |
|
|
"Nils Haeck" <n.haeckno (AT) spamchello (DOT) nl> wrote
| Quote: | First of all, you must ensure that your physics modelling classes are
threadsafe. This usually means they are not referred to directly by your
main application, and that they do not have any global variables if you
run
more than one physics thread.
Then, when you update the physics, use a call wrapped in Synchronize()
inside your physics thread.
But it is a misconception that adding threads speeds up things, it is
usually the other way around, unless you have a multi-processor machine.
So
if you can avoid threads (like with code below) then do so :)
|
Even if it ends up being slower I would like to work out how to do it anyway
as a learning experience, would you have some simple pseudo code (or even
real code) you could share?
I already have a separate physics thread class like so:
TThreadedPhysicsSim = class(TThread)
protected
procedure Update(TimeSlice: Single); virtual;
procedure Execute; override;
end;
{...}
procedure TThreadedPhysicsSim.Update(TimeSlice: Single);
begin
// what to do in here for the inherited class with regards to allowing
access by the main program when rendering...
end;
procedure TThreadedPhysicsSim.Execute;
begin
InitialiseTiming; // setups some timing class
while(not Terminated)do
Update(GetTimeTaken); // gets the ellapsed time since the last
call from some timing class
end;
Cheers,
Paul.
|
|
| Back to top |
|
|
Joris Van Damme
Guest
|
| Posted: Tue Sep 14, 2004 1:17 pm Post subject: Re: Moving physics updating into separate thread?... |
|
|
Paul,
| Quote: | TThreadedPhysicsSim = class(TThread)
protected
procedure Update(TimeSlice: Single); virtual;
procedure Execute; override;
end;
{...}
procedure TThreadedPhysicsSim.Update(TimeSlice: Single);
begin
// what to do in here for the inherited class with regards to allowing
access by the main program when rendering...
end;
procedure TThreadedPhysicsSim.Execute;
begin
InitialiseTiming; // setups some timing class
while(not Terminated)do
Update(GetTimeTaken); // gets the ellapsed time since the last
call from some timing class
end;
|
The context is not very clear to me, neither is the nature and structure of
this 'physics' data. All of that is important when trying to decide the best
possible multi-threading scheme.
For instance, suppose this thread does not do any calculation, but you just
need it to give a signal back to your main thread every InitialiseTiming
interval. Much like a timer. In that case, the (not only, but best) possible
way is to send a message to a form in your main thread. For instace:
TForm1 = class
private
procedure ThreadMessage(var a: TMessage); message WM_USER+0;
end;
procedure TThreadedPhysicsSim.Execute;
begin
InitialiseTiming; // setups some timing class
while(not Terminated)do
begin
Sleep(TargetAwakeTime-CurrentTime)
Update(GetTimeTaken);
end;
end;
procedure TThreadedPhysicsSim.Update(TimeSlice: Single);
begin
PostMessage(Form1.Handle,WM_USER+0,0,0);
end;
Things are never very simple, not even in this case. For instance, the
thread touches 'Form1.Handle'. TForm1 might be a multi-instance form class,
that you create and destroy dynamically. Or even if it isn't, design
application logic must guarantee that there always is a Form1.Handle to
access when the thread does. Otherwise, this, too becomes another seperate
synchronization issue...
Also, I do not really recommend using 'Terminated', but hey, let's keep it
simple for now and reuse what we can.
Suppose there is some calculation to be done, instead. In that case, your
main loop would look like this
procedure TThreadedPhysicsSim.Execute;
begin
InitialiseTiming; // setups some timing class
while(not Terminated)do
begin
DoProcessing;
Sleep(TargetAwakeTime-CurrentTime)
Update(GetTimeTaken);
end;
end;
Where the Update procedure is responsable for posting the Updated date back
into the main loop. This could go like this:
procedure TThreadedPhysicsSim.Update(TimeSlice: Single);
begin
PostMessage(Form1.Handle,WM_USER+0,0,LParam(MakeCopy(TheData)));
end;
procedure TForm1.ThreadMessage(var a: TMessage);
begin
FData.Free;
FData:=TData(a.LParam);
end;
Of course, again, it's not completely this simple. You'll have to design
things such that you're absolutely sure Form1 will be there to catch the
message, otherwise you have a leak, etc. But worry about those things only
after you get the general picture and decide on the general design.
The above way of doing things solves the multiple-thread access to the Data
by maintaining different copies. It is most suitable if both threads have
extensive and elaborate access to the data all of the time. It is least
suitable if the Data is huge.
Other schemes or possible, like protecting a single copy of the data with a
critical section. Essentially, only one context can 'enter' a critical
section at any one time, so if you wrap access to the data inside an
EnterCriticalSection and LeaveCriticalSection statement, in both threads,
you guarantee only a single thread is accessing it at any one time. Of
course, this is best only if logical data access is only short an infrequent
(and leaving it in a logically correct state any other thread can work from
each time). It is not very suitable if the data is huge and elaborately
accessed by long processing, since, essentially, that makes the other thread
wait, which steps on your multi-threading point and reduces processing
activity back to a single thread.
More elaborate schemes might use multiple Critical Sections for access to
multiple logically seperate pieces in the data, etc. In the end, you always
end up doing many very specific context and data sensitive things, before
ending up with a real good scheme. Don't ever let anyone tell you to 'just
call synchronize', like Borland is trying to tell us, because that means to
essentially 'just use multiple thread that end up in single-threading at any
one time'. It's always more complicated to do it really right, but... true
multi-threading is also very interesting and rewarding.
Joris Van Damme
[email]info (AT) awaresystems (DOT) be[/email]
http://www.awaresystems.be
Download your free TIFF tag viewer for windows here:
http://www.awaresystems.be/imaging/tiff/astifftagviewer.html
|
|
| Back to top |
|
|
Paul Nicholls
Guest
|
| Posted: Tue Sep 14, 2004 11:23 pm Post subject: Re: Moving physics updating into separate thread?... |
|
|
"Joris Van Damme" <PleaseReplyTo (AT) TheGroupInstead (DOT) be> wrote
| Quote: | Paul,
TThreadedPhysicsSim = class(TThread)
protected
procedure Update(TimeSlice: Single); virtual;
procedure Execute; override;
end;
{...}
procedure TThreadedPhysicsSim.Update(TimeSlice: Single);
begin
// what to do in here for the inherited class with regards to
allowing
access by the main program when rendering...
end;
procedure TThreadedPhysicsSim.Execute;
begin
InitialiseTiming; // setups some timing class
while(not Terminated)do
Update(GetTimeTaken); // gets the ellapsed time since the
last
call from some timing class
end;
The context is not very clear to me, neither is the nature and structure
of
this 'physics' data. All of that is important when trying to decide the
best
possible multi-threading scheme.
SNIP |
Thanks for the post Joris :-)
Just to let you know, the physics stuff would normally be used like so:
If called in a single thread program, the physics Update() method would be
used something like this (warning newsreader code):
procedure UpdateAllPhysicsObjectsLocationEtc(TimeSlice: Single);
begin
// upate all physics objects locations using forces, etc.
end;
procedure Update(TimeSlice: Single);
const
MIN_TIME_SLICE = 10 * 1E-3;
var
i: Integer;
t: Single;
begin
t := 0;
for i := 1 to (TimeSlice div MIN_TIME_SLICE) do
begin
UpdateAllPhysicsObjectsLocationEtc(MIN_TIME_SLICE);
t := t + MIN_TIME_SLICE;
end;
if(t < TimeSlice)then
UpdateAllPhysicsObjectsLocationEtc(TimeSlice - t);
end;
procedure RenderProcedure(TimeSlice: Single);
begin
Update(TimeSlice);
DrawAllPhyicsObjects;
end;
What I would now like to know is how to have the Update method in the
separate TThreadedPhysicsSim class to do the same thing, and the rendering
procedure to only do the drawing of the objects and not do the updating.
The problem is that the drawing of the objects would most likely happen
during an Update() call, and I don't know how to deal with this...
I hope I am making more sense now :-)
cheers,
Paul.
|
|
| Back to top |
|
|
Joris Van Damme
Guest
|
| Posted: Wed Sep 15, 2004 12:56 am Post subject: Re: Moving physics updating into separate thread?... |
|
|
| Quote: | I hope I am making more sense now
|
No, it doesn't, I'm sorry. The trouble is that I know next to nothing about
this stuff. I know something about multi-threading, but that is so very
context dependent (which is why you cannot find clearcut simple
general-purpose examples, unless they synchronize everything back into the
main thread).
I'll try and help, but please forgive me for not understanding your exact
context (yet).
What you call physics, is data, right? Like eg, suppose their is an opening
door in your game. You'd have a data structure that is the door, that is
part of your 'physics'. Am I understanding this correctly?
What you call updating, is recalculating the time-dependent parts of the
data, from the time, and the designed data parts, right? Like eg, the door
has a fixed axis, and a state member 'opening at this speed, currently this
angle'. Updating is then recalculating the 'angle' part, possible deducting
that it's completely opened, when it is, and thus possibly also recalculting
its state to change from 'opening' to 'fully opened'. Is that right?
Drawing, then, is reading the data, and doing the actual drawing. The door,
at this or that angle, as stated in the data. Right?
And what you're after, is having the updating part in a worker thread, while
keeping the drawing in the main thread? Or do you want both parts in the
worker thread, only synchronizing a flat display-sized resulting bitmap into
the main thread who needs to draw it?
Or am I misunderstanding things completely?
Joris Van Damme
[email]info (AT) awaresystems (DOT) be[/email]
http://www.awaresystems.be
Download your free TIFF tag viewer for windows here:
http://www.awaresystems.be/imaging/tiff/astifftagviewer.html
|
|
| Back to top |
|
|
Paul Nicholls
Guest
|
| Posted: Wed Sep 15, 2004 1:09 am Post subject: Re: Moving physics updating into separate thread?... |
|
|
"Joris Van Damme" <PleaseReplyTo (AT) TheGroupInstead (DOT) be> wrote
| Quote: | I hope I am making more sense now :-)
No, it doesn't, I'm sorry. The trouble is that I know next to nothing
about
this stuff. I know something about multi-threading, but that is so very
context dependent (which is why you cannot find clearcut simple
general-purpose examples, unless they synchronize everything back into the
main thread).
I'll try and help, but please forgive me for not understanding your exact
context (yet).
|
:-)
| Quote: | What you call physics, is data, right? Like eg, suppose their is an
opening
door in your game. You'd have a data structure that is the door, that is
part of your 'physics'. Am I understanding this correctly?
|
yes :-)
| Quote: | What you call updating, is recalculating the time-dependent parts of the
data, from the time, and the designed data parts, right? Like eg, the door
has a fixed axis, and a state member 'opening at this speed, currently
this
angle'. Updating is then recalculating the 'angle' part, possible
deducting
that it's completely opened, when it is, and thus possibly also
recalculting
its state to change from 'opening' to 'fully opened'. Is that right?
|
yes this is correct :-)
| Quote: | Drawing, then, is reading the data, and doing the actual drawing. The
door,
at this or that angle, as stated in the data. Right?
|
yup :-)
| Quote: | And what you're after, is having the updating part in a worker thread,
while
keeping the drawing in the main thread?
|
I want to to the first option if I can :-)
| Quote: | Or do you want both parts in the
worker thread, only synchronizing a flat display-sized resulting bitmap
into
the main thread who needs to draw it?
Or am I misunderstanding things completely?
|
You are doing just fine with your understanding :-)
cheers,
Paul.
|
|
| Back to top |
|
|
Joris Van Damme
Guest
|
| Posted: Wed Sep 15, 2004 1:51 am Post subject: Re: Moving physics updating into separate thread?... |
|
|
| Quote: | You are doing just fine with your understanding
|
OK, but then, things still depend on the size of your data, the elaboratness
of the updating stage, the need to be able to draw and update at the same
time, etc.
Suppose that the 'elaboratness' of the updating stage is relatively huge,
and the amount of data is relatively small. In that case, the best option
might be to maintain two copies of the data. First one is private in the
worker thread, nothings accesses it but the worker thread.
In the update code, the worker thread can read and write to it, without
problem.
Next, the worker thread would enter a critical section, and update the
second copy of the data, that is accessed in both threads, from its own
private copy. It would next leave the critical section, and post a message
into the main thread. This main thread would enter the critical section, use
the shared data to draw, and leave the critical section.
The benefit of this scheme is that the two major parts of processing
(update, reading and writing the worker thread private data, and drawing,
protected reading of shared data) can happen at the same time. The major
drawback is that there is a copying stage, and duplicate memory use. That is
why it is only the best scheme if the amount of data is relatively small
compared to the amount of processing required by update and draw. Otherwise,
you start wasting a lot of memory, and the copying itself becomes a major
player, and this cannot be done at the same time as drawing, etc...
Suppose on the other hand that the data is relatively huge, and the
'elaboratness' of the updating stage is not much more then cycling through
the data accompanied by some minor recalculating of only a few things... In
this case, I would probably opt for a single shared copy, and, if logically
possible, a 'narrow' protection of the single shared copy. Meaning, use a
seperate critical section for 'each door'. This way, the copying stage is
eliminated, and the drawing thread can be drawing any door that is not
currently being recalculated.
Of course there's drawbacks in this scheme, too. For example, if your data
is very large, and you go individually protecting to narrow a blocks, you
might end up using so many critical sections that this becomes troublesome
to the system...
If you find yourself in the situation where any of these schemes presents
major drawbacks... you might even need to rethink the division of workload
between threads, and have the worker thread do all the drawing, and thus
sharing nothing but a single displaywide resulting bitmap between threads.
That resulting bitmap, clearly, is best synchronized using the 'duplicate
copy' scheme. You might decide to keep two bitmaps, each seperatly
protected, and having the worker thread update on while the main thread is
able to blit the other to the screen...
This is what is so challenging and at the same time exciting and rewarding
about real multi-threading: you always need to fit every piece of the puzzle
very carefully.
Does any of the above rambling seem to fit your data?
Joris Van Damme
[email]info (AT) awaresystems (DOT) be[/email]
http://www.awaresystems.be
Download your free TIFF tag viewer for windows here:
http://www.awaresystems.be/imaging/tiff/astifftagviewer.html
|
|
| Back to top |
|
|
Paul Nicholls
Guest
|
| Posted: Wed Sep 15, 2004 3:17 am Post subject: Re: Moving physics updating into separate thread?... |
|
|
"Joris Van Damme" <PleaseReplyTo (AT) TheGroupInstead (DOT) be> wrote
| Quote: | You are doing just fine with your understanding :-)
OK, but then, things still depend on the size of your data, the
elaboratness
of the updating stage, the need to be able to draw and update at the same
time, etc.
Suppose that the 'elaboratness' of the updating stage is relatively huge,
and the amount of data is relatively small. In that case, the best option
might be to maintain two copies of the data. First one is private in the
worker thread, nothings accesses it but the worker thread.
In the update code, the worker thread can read and write to it, without
problem.
Next, the worker thread would enter a critical section, and update the
second copy of the data, that is accessed in both threads, from its own
private copy. It would next leave the critical section, and post a message
into the main thread. This main thread would enter the critical section,
use
the shared data to draw, and leave the critical section.
The benefit of this scheme is that the two major parts of processing
(update, reading and writing the worker thread private data, and drawing,
protected reading of shared data) can happen at the same time. The major
drawback is that there is a copying stage, and duplicate memory use. That
is
why it is only the best scheme if the amount of data is relatively small
compared to the amount of processing required by update and draw.
Otherwise,
you start wasting a lot of memory, and the copying itself becomes a major
player, and this cannot be done at the same time as drawing, etc...
Suppose on the other hand that the data is relatively huge, and the
'elaboratness' of the updating stage is not much more then cycling through
the data accompanied by some minor recalculating of only a few things...
In
this case, I would probably opt for a single shared copy, and, if
logically
possible, a 'narrow' protection of the single shared copy. Meaning, use a
seperate critical section for 'each door'. This way, the copying stage is
eliminated, and the drawing thread can be drawing any door that is not
currently being recalculated.
Of course there's drawbacks in this scheme, too. For example, if your data
is very large, and you go individually protecting to narrow a blocks, you
might end up using so many critical sections that this becomes troublesome
to the system...
If you find yourself in the situation where any of these schemes presents
major drawbacks... you might even need to rethink the division of workload
between threads, and have the worker thread do all the drawing, and thus
sharing nothing but a single displaywide resulting bitmap between threads.
That resulting bitmap, clearly, is best synchronized using the 'duplicate
copy' scheme. You might decide to keep two bitmaps, each seperatly
protected, and having the worker thread update on while the main thread is
able to blit the other to the screen...
This is what is so challenging and at the same time exciting and rewarding
about real multi-threading: you always need to fit every piece of the
puzzle
very carefully.
Does any of the above rambling seem to fit your data?
|
Thanks for the informative post :-)
I can indeed see why it would be challenging <G>
The different situations that you outline do make sense :-)
Just to let you know a bit more about my situation:
The data I will be updating in my game will be an unknown number of objects,
lets say, particles.
For example
TParticle = class
Pos: TVector3d;
Vel: TVector3d;
Forces: TVector3d;
procedure Stop;
procedure ApplyForce(F: TVector3d);
procedure Update(TimeSlice: Single);
end;
A particle can represent either the location of a ship, other game objects
like asteroids, etc. or actual particles in a particle system used for
special effects.
Each particle will be responding to forces using Newtronian physics and each
particle update I guess would be relatively quick in the scheme of things.
My rendering loop is using OpenGL to draw the objects if this helps...
I will digest what you have posted and try different things :-)
Cheers,
Paul.
|
|
| Back to top |
|
|
Lord Crc
Guest
|
| Posted: Wed Sep 15, 2004 1:47 pm Post subject: Re: Moving physics updating into separate thread?... |
|
|
On Wed, 15 Sep 2004 13:17:37 +1000, "Paul Nicholls"
<paul_nichollsNOSPAM (AT) hotmail (DOT) com> wrote:
| Quote: | My rendering loop is using OpenGL to draw the objects if this helps...
|
I havent followed this closely, but I suspect you want to now be able
to basically do
while not Terminated do
UpdatePhysics(Fixed_Timestep);
in the worker thread?
If so, I think it'd have a lock in the worker thread, and do something
like this:
procedure Execute:
while not Terminated do
begin
FCriticalSection.Enter;
UpdatePhysics(Fixed_Timestep);
FCriticalSection.Leave;
end;
then the worke thread has a method which returns a list of simple
particles (which contain only what you need for rendering: position,
possibly kind/velocity, whatever):
type
TRenderParticle = class
Position: Vector3d;
Kind: TParticleKind;
end;
procedure GetParticleData(List: TObjectList);
var
rp: TRenderParticle;
begin
FCriticalSection.Enter;
for i:= 0 to FParticles.Count-1 do
begin
rp:= TRenderParticle.Create;
rp.Position:= FParticles[i].Position;
rp.Kind:= ...
List.Add(rp);
end;
FCriticalSection.Leave;
end;
This allows the physics thread to do what i want while the frame is
beeing rendered. Of course if you have a gig of data, that's a bit
unpractical, and you'll simply have to block the physics thread while
rendering, which sort of defeats the purpose i guess? :)
- Asbjørn
|
|
| Back to top |
|
|
Paul Nicholls
Guest
|
| Posted: Wed Sep 15, 2004 10:52 pm Post subject: Re: Moving physics updating into separate thread?... |
|
|
"Lord Crc" <lordcrc (AT) hotmail (DOT) com> wrote
| Quote: | On Wed, 15 Sep 2004 13:17:37 +1000, "Paul Nicholls"
[email]paul_nichollsNOSPAM (AT) hotmail (DOT) com[/email]> wrote:
My rendering loop is using OpenGL to draw the objects if this helps...
I havent followed this closely, but I suspect you want to now be able
to basically do
while not Terminated do
UpdatePhysics(Fixed_Timestep);
in the worker thread?
If so, I think it'd have a lock in the worker thread, and do something
like this:
procedure Execute:
while not Terminated do
begin
FCriticalSection.Enter;
UpdatePhysics(Fixed_Timestep);
FCriticalSection.Leave;
end;
then the worke thread has a method which returns a list of simple
particles (which contain only what you need for rendering: position,
possibly kind/velocity, whatever):
type
TRenderParticle = class
Position: Vector3d;
Kind: TParticleKind;
end;
procedure GetParticleData(List: TObjectList);
var
rp: TRenderParticle;
begin
FCriticalSection.Enter;
for i:= 0 to FParticles.Count-1 do
begin
rp:= TRenderParticle.Create;
rp.Position:= FParticles[i].Position;
rp.Kind:= ...
List.Add(rp);
end;
FCriticalSection.Leave;
end;
This allows the physics thread to do what i want while the frame is
beeing rendered. Of course if you have a gig of data, that's a bit
unpractical, and you'll simply have to block the physics thread while
rendering, which sort of defeats the purpose i guess? :)
|
Thanks for the interesting post Asbjørn :-)
It sounds like this may work for me, I'll give it a go :-)
I'll do some digesting <G>
cheers,
Paul.
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
