Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


#Actualfir

Posted 31 August 2013 - 04:52 AM

 

 

Ok, except that all ai() render() and physics() need to acces the same game state data and all it need to be still and coherent,

 

how would you resolve that?

 

I don't know smile.png I guess it's something for you to figure out. What I said wasn't the answer nor did I say how it to be done exactly. It was a hasty example just to show the idea behind threading and why it may be used, not necesarily how to do it. Sadly I don't know, I haven't done it yet... Though once my engine reaches the need for multi-threading... I can't wait to jump in happy.png

 

 

ye, without it your example is not too much 'usable' ;-) though youre right I can try to figure some things out here (and maybe add some explanations)

 

For example is seem render can be paralelised because it only read game state so you could just binary copy it then render this copy and in the same time update the oryginal state

 

 - but doing ai movements and physics object movements would be harder because in general movements may interact and collide

 

(If you even resolve al detailed collisions by locks it is yet 

still the problem of race conditions i think - the outcome of

(besides that deterministic) frame update would bring different

results depending of reaces of the threads in the time line over the entities - I am not sure if such races in some extents are acceptable or should be avoided at all (I would like to better avoid that)

 

So it is mess - maybe some other ways of paralelizing it 

could be done - maybe some lenghty and temporaly and

ram independant routines can be found then it could be run 

in parallel - depending what is lenghty and what can be 

doin in parallel, It need practical knowledge about such

game internals and also is somewhat spoiled by the fact

that you need to paralelise in small time granulality (frame

is about 20 milisekonds ) So I do not know if speaking about general answer


#4fir

Posted 31 August 2013 - 04:50 AM

 

 

Ok, except that all ai() render() and physics() need to acces the same game state data and all it need to be still and coherent,

 

how would you resolve that?

 

I don't know smile.png I guess it's something for you to figure out. What I said wasn't the answer nor did I say how it to be done exactly. It was a hasty example just to show the idea behind threading and why it may be used, not necesarily how to do it. Sadly I don't know, I haven't done it yet... Though once my engine reaches the need for multi-threading... I can't wait to jump in happy.png

 

 

ye, without it your example is not too much 'usable' ;-) though youre right I can try to figure some things out here (and maybe add some explanations)

 

For example is seem render can be paralelised because it only read game state so you could just binary copy it then render this copy and in the same time update the oryginal state

 

 - but doing ai movements and physics object movements would be harder because in general movements may interact and collide

 

(If you even resolve al detailed collisions by locks it is yet 

still the problem of race conditions i think - the outcome of

(besides that deterministic) frame update would bring different

results depending of reaces of the threads in the time line over the entities - I am not sure if such races in some extents are acceptable or should be avoided at all (I would like to better avoid that)

 

So it is mess - maybe some other ways of paralelizing it 

could be done - maybe some lenghty and temporaly and

ram independant routines can be found then it could be run 

in parallel - depending what is lenghty and what can be 

doin in parallel, It need practical knowledge about such

game internals and also is somewhat spoiled by the fact

that you need to paralelise in small time granulality (frame

is about 20 milisekonds ) So I do not know 


#3fir

Posted 31 August 2013 - 04:42 AM

 

 

Ok, except that all ai() render() and physics() need to acces the same game state data and all it need to be still and coherent,

 

how would you resolve that?

 

I don't know smile.png I guess it's something for you to figure out. What I said wasn't the answer nor did I say how it to be done exactly. It was a hasty example just to show the idea behind threading and why it may be used, not necesarily how to do it. Sadly I don't know, I haven't done it yet... Though once my engine reaches the need for multi-threading... I can't wait to jump in happy.png

 

 

ye, without it your example is not too much 'usable' ;-) though youre right I can try to figure some things out here (and maybe add some explanations)

 

For example is seem render can be paralelised because it only read game state so you could just binary copy it then render this copy and in the same time update the oryginal state

 

 - but doing ai movements and physics object movements would be harder because in general movements may interact and collide

 

(If you even resolve al detailed collisions by locks it is yet 

still the problem of race conditions i think - the outcome of

(besides that deterministic) frame update would bring different

results depending of reaces of the threads over the entities

- I am not sure if such races in some extents are acceptable

or should be avoided at all (I would like to better avoid that)

 

So it is hard - maybe some other ways of paralelizing it 

could be done - maybe some lenghty and temporaly and

ram independant routines can be found then it could be run 

in parallel - depending what is lenghty and what can be 

doin in parallel, It need practical knowledge about such

game internals and also is somewhat spoiled by the fact

that you need to paralelise in small time granulality (frame

is about 20 milisekonds ) So I do not know 

 

 

 

 

- so it 


#2fir

Posted 31 August 2013 - 03:50 AM

 

 

Ok, except that all ai() render() and physics() need to acces the same game state data and all it need to be still and coherent,

 

how would you resolve that?

 

I don't know smile.png I guess it's something for you to figure out. What I said wasn't the answer nor did I say how it to be done exactly. It was a hasty example just to show the idea behind threading and why it may be used, not necesarily how to do it. Sadly I don't know, I haven't done it yet... Though once my engine reaches the need for multi-threading... I can't wait to jump in happy.png

 

 

ye, without it your example is not too much 'usable' ;-) though youre righ I can try to figure some things out here (and maybe add some explanations)


#1fir

Posted 31 August 2013 - 03:49 AM

 

 

Ok, except that all ai() render() and physics() need to acces the same game state data and all it need to be still and coherent,

 

how would you resolve that?

 

I don't know smile.png I guess it's something for you to figure out. What I said wasn't the answer nor did I say how it to be done exactly. It was a hasty example just to show the idea behind threading and why it may be used, not necesarily how to do it. Sadly I don't know, I haven't done it yet... Though once my engine reaches the need for multi-threading... I can't wait to jump in happy.png

 

 

ye, without it your example is not too much 'usable' ;-) though youre righ I can try to figure some things out here 


PARTNERS