Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 07 Mar 2007
Offline Last Active Aug 25 2014 07:50 PM

Posts I've Made

In Topic: Debugging a system hang (entire OS freezes)

07 August 2014 - 03:02 PM

Ok yeah, I've got trace logging, although this happens so infrequently that I'd hate to have it on all the time. I guess I really should, though. Thanks.

In Topic: OpenGL Camera Concept

16 June 2014 - 10:17 AM

I don't know of any tutorials, but basically all you need to do is give your camera a transform matrix just like any other object in your world. When it comes time to render the scene, invert the Camera's matrix to get the view matrix. At the end of the day, your verts need to be in camera-relative space before doing the projection transformation. So, this last step of inverting the camera matrix to get the view matrix, and then multiplying your world-space verts with this view matrix, cannot be avoided. However, at least with this method, you can think in terms of the camera's position until the very end.

In Topic: Just a couple of Data-Oriented Design questions.

16 June 2014 - 08:13 AM

I'm not trying to use it for every piece of code. I'm trying to use it to speed up entity/component updates. I must say, what I'm asking seems like a totally reasonable request. That is, help me understand how data-oriented design is used in games. So far, I've gotten some good replies along with at least two lectures about how I shouldn't be using data-oriented design like a golden hammer. Is that what I'm doing? Because most of the reading I've done on the subject uses this sort of entity-component update as an example of precisely where DOD comes in handy. Is there some way in which I'm misapplying the concept? If so, it would most helpful if you would be explicit about it.

In Topic: Just a couple of Data-Oriented Design questions.

16 June 2014 - 12:12 AM

Thanks very much for your help! Now that you mention it, I think this plan I'm referring-to will work pretty well with my project, because I'm going to have relatively few entity types, but dozens or hundreds of each. In a project where there are hundreds of entity types, and perhaps only a few of each, and perhaps even entities that dynamically change their composition, then this plan probably wouldn't work that well.


Then again, for an Asteroids clone, anything approaching a data-driven, data-oriented, component-entity system is hugely overkill. :P


But, it's good to have a small project to practice a new concept on.

In Topic: Just a couple of Data-Oriented Design questions.

15 June 2014 - 11:59 PM


However, ignoring for the moment the problem of the dynamic cast, my understanding is that this is not done in a Data-Oriented way

Who cares? Use tools when you need them and don't try to slavishly apply them to every situation.

Even if you do want to write every last bit of your code using data-oriented design... that term doesn't say that you have to avoid every single cache miss ever no matter what. It just says that you should think about your data and how it's accessed when designing your architecture. If you've done that and haven't identified a verifiable issue that needs addressing, have a beer and move on to a real problem that needs your time and attention. smile.png



Point taken, definitely. A lot times I don't feel that I understand a concept unless I've implemented it, though. So the point of this exercise is "Understand Data-Oriented Design". Once I've done that, I'll feel ready to make decisions about where DOD makes sense.