2
\$\begingroup\$

Should Update take care of calculating the drawing position of element or should it be done exlusively in Draw method?

If I calculate the drawing position of element in Update and then store it as element property then I can reuse it in Draw method. I can only run the update if the element (or camera) moved so it seems it would be good for performance. Is this good approach? Or should I never store the draw position of an element and always calculate it in Draw method?

EDIT:

It seems my question wasn't clear enough. I'm not talking about elements Draw method but the Draw method of manager/renderer that draws them on the screen. The elements themselves do not have Draw method.

\$\endgroup\$
0

3 Answers 3

2
\$\begingroup\$

Trick question. The correct answer is that elements should not have a Draw method. A renderer of some sort should contain the collection of objects to draw which it then can efficiently pack or instance in one big go after culling.

The final drawing position will be dependent on a camera, which the renderer is likely to have easy access to but the individual elements would not. You'd usually do the actual draw position calculating on the GPU (either with fixed function or programmable pipelines). A common HLSL shader for this might be:

float4x4 ModelMatrix;
float4x4 CameraMatrix;
float4x4 ProjectionMatrix;

void main(in float3 input : POSITION, out float4 output : SV_POSITION) {
  output = mul(float4(input, 1), ModelMatrix);
  output = mul(output, CameraMatrix);
  output = mul(output, ProjectionMatrix);
}

The position of the element itself is written to the ModelMatrix as a translation. The actual drawing position is calculated using the camera and projection.

There are cases where you want to do this on the CPU. The math is the exact same, you just use whatever your CPU-side math library is instead of using HLSL.

A big win for the renderer approach - especially if you're doing sprites (you didn't specify) or particles - is that you can avoid drawing each element individually. It can be much more efficient to using hardware instancing or to do the CPU-side math and pack all the objects into a single vertex buffer (profile to find out which is faster for your specific uses on your target hardware, of course).

In general, focus on approaches where systems or manager of some kind operate on collections of objects rather than having an approach where objects operated on themselves. The extreme (IMO overly so) version of this is an Entity Component System.

Another approach which I'm coming to prefer lately is to simply have separate hierarchies. You have a scene graph of some kind that is nothing more than a collection of renderable objects efficiently managed by a renderer. You have a physics simulation which is nothing except bodies and physics materials managed by the physics engine (which is exactly what you get when you use physics middleware like Bullet, Box2D, Havok, PhysX, etc.). Your game objects then simply handle the game-specific logic and "glue" to keep these hierarchies meaningfully up to date. Your renderer or physics engine are typically going to be heavily specialized in purpose and design and don't really need or want to be constrained by game objects, nor do you want your game objects constrained by every special system. It is definitely more common in most custom engines to integrated graphics/physics with the game objects/components directly, though, and that's a perfectly valid approach.

\$\endgroup\$
2
  • \$\begingroup\$ I'm sorry I wasn't specific enough. Elements I'm talking about (map tiles in this case) do not draw themselves nor have any Draw method. I have a TileMapManager class that does that. My question was should I calculate the position it should be drawn in XNA's Update method and store it in the tile (the tile does not know about camera or anything else) or should I calculate it in the XNA's Draw method itself. \$\endgroup\$
    – kasztelan
    Jul 27, 2013 at 17:47
  • \$\begingroup\$ Y'know, although this wasn't a direct answer to the question given, this is kinda helpful for me. In most basic XNA engines I write, I find myself giving singleton references to Camera, or haphazardly passing it around, and I'm always thinking "This can't be right..." \$\endgroup\$
    – Katana314
    Jul 29, 2013 at 20:43
1
\$\begingroup\$

To store the Screen location in the Element is not a good approach, because

  • drawing of components should be as loosly coupled as possible
  • Screen location calculations are done with tansformations of the Camera, so the object has to know the location/transformation of the camera -> bad
\$\endgroup\$
0
\$\begingroup\$

You should separate logic space coordinates from rendering space coordinates.

Usually at logic space coordinates (world coordinates), your tiles will be size(1,1), your calculations will be easier and simpler.

and when you draw the tiles you will apply a camera transform that depending on scale will let you draw tiles with the size that you need, without affect your logic calculations.

Using a camera transform lets you perform screen oeprations as scrolls, zooms and rotations in an easy way, and is easy to determine the visible tiles too.

it has a lots of benefits... so NO.. is a bad idea at logic stage to calculate the screen position and size of a tile... is much better to use a camera to transform from world coordinates to screen coordinates.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .