Hello
I'm trying to understand how to best implement the concept of *position* for 2D entities using this engine.
The general usage seems to be, if I have a class (such as Body from demo2), that holds an Image*, I store 2 floats (x,y) for position, and when it comes time to draw, I use these values in a Graphics::translate call (after a pushTransform) before the Graphics::drawImage call.
As far as I can tell from experiments, values used in translate affect where the center of the image is drawn.
My confusion stems from the fact that these images are sized in pixels (as far as I can tell), and it seems reasonable to expect that their dimensions will often be even numbers. So, if I have a 64x64 image, which pixel is the "center" ? - it seems to me that there is actually a group of 4 pixels that are all the center pixels, but none of which is the single center point.
So... one problem that would seem ambiguous: if I wanted to do single-pixel-resolution collision: if my 64x64 image has a "position" of (100, 100), does the right-most edge of my image lie in column 132 of screen space? Or column 133?
(I'm assuming pixels in my image, and on the screen, are indexed starting from 0)
A meta problem:
Can anyone suggest the best approach to setup a game where the scale of the world and the entities in it are not sized in pixels? i.e. they are "normalized" to some floating point range, and only at some final step is everything scaled to fit whatever sized window you are playing in.
Another way to state this problem: how do you make a game in this engine that can played at different game window resolutions, but this does not change how much of the world you get to see, just the size of it.
Sorry, I'm not used to thinking in pixels and screen space; much more used to floating point everything in "world space", for 3D worlds.
Thanks in advance,
Greg
|
I understand your confusion; it stems from thinking about discrete pixels instead of a continuous coordinate space. The drawing framework used in the 2DBoy framework (and most 3D graphics libraries, incidentally) uses a continuous coordinate space; i.e. coordinates are real-valued point coordinates, not discrete pixel coordinates. The difference between a point and a pixel is that a point has no size, but a pixel does.
So when you have an image of size 64x64 (pixels, although the unit doesn't really matter) then its centerpoint is in the exact middle, with the top-left corner at (-32,-32) and the bottom-right corner at (32,32) relative to the center point. (Actually, which corner has which coordinates depends on how you choose the axes, but in the 2DBoy framework the X-axis extends to the right and Y-axis downward).
Pixel-aligning such an image is actually very easy. Suppose the game viewport has size 800x600, then its viewport has coordinates from (-400,-300) in the upper-left to (400,300) in the lower-right corner. If you place the centerpoint of the image at (0,0) then it exactly covers the 64x64 square of pixels on the screen from (368,268) to (432, 332).
If you want all your images to be 1-pixel-wide by default, the easiest way to do that is to scale by (1/width, 1/height) before drawing. |
Thanks for the reply Soultaker - that does clarify it somewhat - but I'm still confused about the coordinate system:
You said in your post that a view port of 800x600 has coordinates from -400,-300 to 400,300.
However, I find that when I want to position Images to draw, the viewport coordinates go from 0,0 to w,h?
Also, in a previous post you replied to a transform-stack question I had, and pointed out that:
Quote:
The Windows implementation doesn't seem to clear the current transformation, which is probably what causes the behaviour you observed. (This occurs despite your call to popTransform() because changes to the transform stack don't take effect until WinGraphics::updateTransform() is called, which isn't done by drawLine() because it wasn't supposed to go through the transform stack anyway!)
It's specifically the part about changes in the transform stack not taking effect until WinGraphics::updateTransform is called.
If I do something like:
<br />g->pushTransform();<br />g->translate(100.0f, 100.0f);<br />g->drawImage(image1);<br />g->popTransform();<br /><br /><br />g->pushTransform();<br />g->drawImage(image2);<br />g->popTransform();<br /><br />
my understanding is that image2 should NOT be affected by the transation done for image1 - when we popTransform() we are back to where we were before, no?
I would have expected image1 to be at 100,100, and image2 to be at 0,0.
This is not the behaviour I observe. The above code draws image1 and image2 in the same place!
I was about to submit this post, then I tried doing a:
<br />g->translate(0.0f, 0.0f);<br />g->drawImage(image2);<br />
Now image2 is in the top left corner, but I would have thought a pushTransform(), on a "fresh" stack, would give us an "identity" matrix with no translation in it??
I really am missing something. I suspect popTransform() does not do what I think it does.
Please help
Thanks
Greg
|
No, I think you're right: popTransform() should restore the transformation stack!
This is indeed a "bug" related to the other problem you reported. (I guess drawing stuff without applying any transformations at all is so unlikely that the problem never came up, although I can see how it's confusing when testing.)
Quote: You said in your post that a view port of 800x600 has coordinates from -400,-300 to 400,300. However, I find that when I want to position Images to draw, the viewport coordinates go from 0,0 to w,h?
Ah, you're right, my mistake.
Last modified Fri, 07/31/2009 - 16:29 by Soultaker |
Ok
Thanks again Soultaker.
Seems like as long as I always do a translate (even of 0,0) I should be fine.
Just wanted to understand what was going on.
Cheers
Greg
|
For what it's worth, I've fixed this bug (and the one you discovered earlier) in davidc's Subversion repository. |
You are viewing a static copy of the old 2DBoy forum, which closed in 2010. It is preserved here for historical interest, but it is not possible to reply to topics. For more recent discussion about World of Goo, visit our new forum.