5 ms·

It sounds like you are overengineeing it. Modern computers are fast; Program it naively and if you see it's too slow (which it probably wouldn't be) optimize t

by ido 17y ago

It sounds like you are overengineeing it. Modern computers are fast; Program it naively and if you see it's too slow (which it probably wouldn't be) optimize the bottlenecks. I am pretty sure you wouldn't need to make this multithereaded.

utx00 17y ago
i thought it sounded pretty clever
- ido 17y ago
  "Clever" and "overengineered" often go hand in hand :)
  - deleted 17y ago
    [deleted]
  - swannodette 17y ago
    But lets not lose sight that without a little bit of cleverness and overengineering we'd still programming in machine code. Also it seems to me that pretty much every popular programming language out there (PHP, C++, Java, Python, Ruby, Erlang, etc.) is the result of overengineering and cleverness. The few languages that aren't overengineered are the ones that either have a very specific domain (JavaSript), slow to change standards (C), or are very new (Clojure). OP's idea also doesn't sound very over engineered to me. The whole draw loop thing is simply a convention and not an obvious one. I've taught many a student who stumbled on the idea of the render loop because there's simply nothing natural or obvious about it. In the real world everything happens at once, there is no update-render-loop. Snapshoting the state of a multithreaded physics engine at discrete intervals in order to render the game state is much closer to a model of how we perceive a fully concurrent reality.
  - utx00 17y ago
    in this case it's a good way of getting smooth animation specially in a dual core whatever whatever :)
scott_s 17y ago
Perhaps he's more interested in experimenting with this kind of architecture?
ajuc 17y ago
I know it's over the top, but it's to try sth different for once. Also - multithreading is because my earlier games was in one thread, and I've always had problems with consistent framerate - some frames was longer, some shorter. When I tried considering last frame duration as multipilier, game became not stable (too long frame and bullets will fly throught the wall, etc). And networked game is difficult to get right with nonuniform duration of frames. So I try to see if this will be better. What's for sure overenginered is using function of time instead of simple numbers for positions. But that is just to make it different.
quizzical 17y ago
I definitely consider it an overreaction to call the described approach over-engineering. Separating simulation and presentation in to separate threads is common and very practical in many games (2d or 3d). It is also common and easy to support a single threaded mode that just runs both simulation and presentation update from one thread. The single threaded mode can make debugging certain issues much easier, but it is rare to have a desire to ship single threaded.

by ido 17y ago

utx00 17y ago

i thought it sounded pretty clever

ido 17y ago
"Clever" and "overengineered" often go hand in hand :)
- deleted 17y ago
  [deleted]
- swannodette 17y ago
  But lets not lose sight that without a little bit of cleverness and overengineering we'd still programming in machine code. Also it seems to me that pretty much every popular programming language out there (PHP, C++, Java, Python, Ruby, Erlang, etc.) is the result of overengineering and cleverness. The few languages that aren't overengineered are the ones that either have a very specific domain (JavaSript), slow to change standards (C), or are very new (Clojure). OP's idea also doesn't sound very over engineered to me. The whole draw loop thing is simply a convention and not an obvious one. I've taught many a student who stumbled on the idea of the render loop because there's simply nothing natural or obvious about it. In the real world everything happens at once, there is no update-render-loop. Snapshoting the state of a multithreaded physics engine at discrete intervals in order to render the game state is much closer to a model of how we perceive a fully concurrent reality.
- utx00 17y ago
  in this case it's a good way of getting smooth animation specially in a dual core whatever whatever :)

scott_s 17y ago

Perhaps he's more interested in experimenting with this kind of architecture?

ajuc 17y ago

I know it's over the top, but it's to try sth different for once. Also - multithreading is because my earlier games was in one thread, and I've always had problems with consistent framerate - some frames was longer, some shorter. When I tried considering last frame duration as multipilier, game became not stable (too long frame and bullets will fly throught the wall, etc). And networked game is difficult to get right with nonuniform duration of frames. So I try to see if this will be better. What's for sure overenginered is using function of time instead of simple numbers for positions. But that is just to make it different.

quizzical 17y ago

I definitely consider it an overreaction to call the described approach over-engineering. Separating simulation and presentation in to separate threads is common and very practical in many games (2d or 3d). It is also common and easy to support a single threaded mode that just runs both simulation and presentation update from one thread. The single threaded mode can make debugging certain issues much easier, but it is rare to have a desire to ship single threaded.