In "Tutorial 4: Make a game in 60 minutes" the GameConstants.cs file has the following values:

//camera constants
public const float CameraHeight = 25000.0f;
public const float PlayfieldSizeX = 16000f;
public const float PlayfieldSizeY = 12500f;

Ok so the CameraHeight is simple, but could someone please explain where the PlayfieldSizeX and PlayfieldSizeY values come from? i.e. how can I calc the Playfield sizes for any given Camera Height.

Ok I could do PlayfieldSizeX = (16000 / 25000) * CameraHeight) but that feels like cheating and I still wouldn't be comfortable as I still wouldn't know where the values came from.

Thanks for your help
Ben

<beg>
Please?
</beg>

If I had to guess (because I don't know for sure), I'd bet they were chosen using good ol' trial and error. There isn't always some mathematical solution for things. Perhaps the author chose those values simply by trying a bunch and using the ones that produced the best results.

---

---

Nick Gravelyn -- Microsoft XNA MVP
XNA Wiki | Zune Games

I can tell you how I calculated them for SpaceWar.... I let the ships drift to the edge and put in code that printed the x,y position when i hit spacebar. Then I hit the space bar.

Its possible to work it out. You know the projection and view matrices so you just have to transform the screen frustum from screen space into world space and you will have your limits. But 3 lines of code was quicker ;-)

 

---

---

The ZBuffer - News and information for XNA and Managed DirectX

Thanks everyone for your replies.

For me trial and error probably wont be good enough as I will be allowing the camera to zoom in and out and pan around (Still always overhead view and no rotation), so I need to calculate the X and Y boundaries on the Z = 0 plane in realtime so that I don't waste time telling the graphics card to draw objects that are completely outside of the viewing area.

Ideas I've thought of to do this include:
1. For every object I could get a bounding sphere and comparing it with a BoundingFrustrum that represents the viewing frustrum.
2. I could take the screen coords for top-left (0,0), top-right, bottom-left and bottom-right and use the "Project" method to find the world-space co-ords at Z=0.

Option 1 sounds computationally expensive, and would require testing every object even if you are only viewing a very small window onto a massive world. So I don't think this is a sensible option.

Hopefullly option 2 will work. I haven't looked at the "Project" method yet
, so hopefully it gives me what I need.

Thanks for your help
Ben

From memory I think the playfiled size was mentioned in the tutorial :)

It was set at that size so that the asteroids would be able to go just outside of the viewport before they rotated to the other side of the screen. This way the user would not see them just disapear. The camera and system in that game was not designed to allow the zoom in and out of the camera.

---

Glenn "Mykre" Wilson - (XNA / DirectX MVP)
Virtual Realm :- XNA News and Resources from Down Under

Thanks Glenn,

Sure I understand that they want the playfieldsize to be slightly oversized for the reason you mentioned, but I was still wondering how those magic numbers were found.

The zooming and panning functionality is something I'm adding, but in order to do that I need to understand where the magic numbers have come from.

I've solved the problem now though using the Viewport Project/Unproject methods, so now my ship can move around a much bigger world with the camera just showing a small window onto that world.


Thanks for your help
Ben