Jump to content

  • Log In with Google      Sign In   
  • Create Account

mvc ,games and multicore


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
5 replies to this topic

#1 giugio   Members   -  Reputation: 215

Like
0Likes
Like

Posted 17 March 2013 - 07:07 AM

hello.
I'm studing the mvc pattern and how i can apply it to a game.
There is some documentation on this(related to the games)?
Because I think perhaps it is a good solution for parallelization on cpu for logic and other parallel stuff
In google i found and read a lot on mvc, but for apply it to games and parallelization, little.

books, advice , links ?
thanks.



Sponsor:

#2 Lightness1024   Members   -  Reputation: 739

Like
2Likes
Like

Posted 17 March 2013 - 09:01 AM

mvc is far from helping parallelization, it just separates data from view. if you have a process that operates in parallel on your data and you were careful to make the data<->view links thread safe, then you can talk about parallelization but mvc didn't help for it once bit.

some parallelization can be done with chunk separation if treatment is independant, like kernels in Cuda/OpenCL or fragments in shader language. this concept can be applied by thrust library on C++ containers for example, or OpenMP on loops as compiler pragmas.

Or thread groups managed by hand. none of those concepts relate to mvc.

there are other parallelization ideas in promises and futures, or procedural programming with immutable data that open the door to parallel treatment but I have no knowledge of this applied in practice.

 

how mvc is applied to a game depends on the subsystem, but there is mostly never the choice anyway because what resides in the graphic card must be copied most of the time. so your model is the level representation in CPU memory, and the view what is displayed by the engine. the controller is the player and other dynamic mechanics...

 

this also applies on smaller scales in various places.



#3 giugio   Members   -  Reputation: 215

Like
0Likes
Like

Posted 18 March 2013 - 05:26 AM

there are other parallelization ideas in promises and futures, or procedural programming with immutable data that open the door to parallel treatment but I have no knowledge of this applied in practice.

thanks Lightness1024 and what are these parallel new ideas?

can you advice to me a link or a book?

thnaks,



#4 sbradl   Members   -  Reputation: 116

Like
0Likes
Like

Posted 20 March 2013 - 04:16 AM

Intel has a very interesting paper about multithreading in games (http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine).

The idea in short: let each subsystem (rendering, physics, AI) operate on their on data. So every subsystem starts with a copy of the initial data. When for example the physics calculation leads to a movement of an object, an event for this movement is generated. Subsystems which are interested in this event can handle it (e.g. renderer updates its own data with the data from the event).

#5 Lightness1024   Members   -  Reputation: 739

Like
0Likes
Like

Posted 20 March 2013 - 09:55 AM

there are other parallelization ideas in promises and futures, or procedural programming with immutable data that open the door to parallel treatment but I have no knowledge of this applied in practice.

thanks Lightness1024 and what are these parallel new ideas?

can you advice to me a link or a book?

thnaks,

I'm not sure about what to buy really, but I was talking about that:

http://link.springer.com/chapter/10.1007%2F3-540-55984-1_25

and the fact that some functional programming ideology has historically been considered as giving the opportunity for parallilization done by the interpreter/compiler itself, even though the code is not written explicitely to ask for any parallelization.

this is possible because functional programming states invariants, it is somehow more "declarative" than "imperative" and therefore the interpreter/compiler can "know" things about the future.

I'm not a language expert so my explanation sucks. but I surely some googling will help smile.png

 

edit: by the way, you can notice that this theory is far from new (1992) there hasn't been much change anyway since then


Edited by Lightness1024, 20 March 2013 - 09:57 AM.


#6 giugio   Members   -  Reputation: 215

Like
0Likes
Like

Posted 20 March 2013 - 11:26 AM

thanks to all, by






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS