Jump to content
  • Advertisement
Sign in to follow this  
eXt_

For each object or for each component?

This topic is 4344 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm architecturing a 3D game engine with a couple of components (Graphics, physics, sound etc) where each of those wants to iterate the objects in the world. Currently each component will iterate the list of objects them self. Would I benefit from doing like this: Pseudocode:
For each object
  doPhysics(ptr)
  doRender(ptr)
  doSound(ptr)
loop
Will the overhead from calling those functions be larger than the overhead with the multiple iterations (one for each component)? I don't have to worry about that the rendering and physics wanting different objects, I have a clever scene manager that fixes that =)

Share this post


Link to post
Share on other sites
Advertisement
Typically you can't render until you know the position which means all physics updates are done. i.e. just because you update the physics on one object doesn't mean the position is final. another object may come along and collide, and cause both to move later. in which case your rendering of object1 is now invalid.

Generally:

1) update all logic
2) render

Otherwise for logic components it's really about what makes more sense to you (unless you're on a platform like the 360 which hates fetching from memory, in which case you want to iterate the objects as few times as possible).

-me

Share this post


Link to post
Share on other sites
Ok, assuming we have some components that can run parallel, like sound and physics, which approach would have the lowest overhead?

EDIT: Also assuming collision sound may be played one frame late.

Share this post


Link to post
Share on other sites
I constructed a simple benchmark to measure the overhead on IA32, (ran on Athlon XP). I thought I would present the results. It's by far much more overhead when calling functions with each object like that compared to letting all the components iterate them self. The only way I was able to beat it was was to inline the functions but I only gained 0.9% performance. When I didn't inline I lost 17%.

My three components did construct strings (with slow sprintf's), did calculations (with lots of data dependency and branch misspredictions), and just waste resources.

Conclusion: At least on IA32, let each component iterate the objects themself. Too much overhead when calling functions that many times. But I also guess this is rather dependent on the cost of fetching from memory so there might be some platforms that gains from it.

Share this post


Link to post
Share on other sites
Quote:
Original post by eXt_
Ok, assuming we have some components that can run parallel, like sound and physics, which approach would have the lowest overhead?


Depends on... well, just about everything - from hardware to the complexity of the operations and the number and size of objects. If you can do either easily (you should be able to), try both methods and profile.

But I'd go with the "for each component" approach by default, since highly orthogonal operations like that, suprisingly enough, are well suited to running on different threads (to take advantage of multiple cores/processors). Or so I've heard.

Share this post


Link to post
Share on other sites
I guess loop unrolling matters a lot too but the problem is the unknown numbers of objects, what objects and the size of them.

I didn't try those methods in my engine which is mostly in the architectural stage right now, but I did create a smaller test scene. You reminded me of threading and that will be easier with running the components like that.

However, don't use a thread for each component like that, it ruins the scheduling. Imagine when 3 components takes 10ms each to calculate and one that takes 50ms, it would still take 50ms to run all components. Divide it into small parts (maybe dependent on other parts) and send it to a job scheduler that shares the work equally on the threads, processes, cores whatever. Using the earlier example the total time might become 30ms instead. The job scheduler is a bit complex thought but definitely worth the job. One day I will write an article about this topic.

I guess I stick with the "for each component" approach.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!