RectF / Coordinate Nightmare...

#1 Only Mac OS and iOS use left,bottom (0,0) as origin. Windows, X11, Android, and everybody else uses left,top (0,0) as origin. As such Torque adopted the same GUI coordinate system as the latter.

As for RectI/F/D classes they are coordinate system neutral. In the GUI sense they are of course used in left,top coordinate system.

#2 So, unfortunately I will need to re-do my stuff. A little disappointing, but at least I know what the problem is now.

Thanks.. Still think it's silly that we're not following mathematical standards here.

#3 And as far back as graphics programming for the Apple ][+ top left was 0,0....

I agree, though - like T2D did, we should establish a common coordinate scheme and stick to it.

#4 I honestly cannot stress how annoying this little revelation was to me in terms of my work I've done, which to this point has assumed a universal transition is positive space coords between the screen and the world.

Just the fact that the 'y' axis is flipped pretty much is forcing me to now rewrite about 45% of my code just to get the position correct, and tbh, I honestly am blanking out in terms of most of these position calculations now. I really wish it was more "known" that this was the coordinates and that they are not the same, or at least given us the option to flip it.

EDIT: In fact I'll actually re-phrase my original to suit the question I'm now facing. How do I translate the standard math coordinates into the coordinate plane presented by the image/gui? Obviously the 'x' is fine, it's the 'y' I need to know. For all assumptions, let's say I know the player's 3D world space (translated to PROPER 2D coords IE: (0,0 +x +y)) and I have the image size (a la texture->mBitmapSize). Essentially, how this is working is the bitmap size matches the world area size and I translate position to the world area like so:

translatedMissionArea.set(obj->getArea().point.x <= 0 ? mAbs(obj->getArea().point.x) : (obj->getArea().point.x)*-1,
				obj->getArea().point.y <= 0 ? mAbs(obj->getArea().point.y) : (obj->getArea().point.y)*-1);
			translatedPosition = playerPos + translatedMissionArea;

Those should transform the origin of the mission area to be (0,0) in standard x/y coords for translatedPosition, but now since the axis has changed, translatedPosition's y coordinate is actually incorrect and this is reflected in game by the radar only rendering to about half way up Y when I hit the northern edge of the map. If I can figure out how to transform these two coordinate systems from one to the other I can solve this in a heartbeat.

#5

Quote:Thanks.. Still think it's silly that we're not following mathematical standards here.

I can't recall Apple ever followed the standards and remained to be a pain in the )*( until this day ;)

Top-left sounds the only correct 0,0 to me!

Sorry to hear you have to do some work again, good luck and heads up!

#6 For reference. It's very common for any 2D graphics to work with a top-left origin. As unfortunate as it is :P.

#7 I even looked it up in my Commodore 64= manual (from 1983).
The origin of the screen was top-left, the same for sprites :-P



Sorry it's in Dutch, it says:
Appendix G, Layout of the screen and colour memory

#8 Yup - just the ancient mechanics of the display (scan lines, memory pixel arrays, etc) popping up in the modern abstracted world-space world. It might be easier to catch it in the calls and just translate it there - perhaps fewer places to make the changes, but now it's in engine....

#9 This still really doesn't help me much other than to re-iterate why this problem is occuring (don't take me as being mad or anything, but it's just frustrating). I know why my problem is occurring ,I'm just looking for the resolution to it now so I can move on to more important parts of the code that are dependant on this calculation being correct.

What I have now is something along the lines of this:

Point2F translatedPosition, playerPos, translatedMissionArea, transGuiPosition;
	   translatedMissionArea.set(obj->getArea().point.x <= 0 ? mAbs(obj->getArea().point.x) : (obj->getArea().point.x)*-1,
				                    obj->getArea().point.y <= 0 ? mAbs(obj->getArea().point.y) : (obj->getArea().point.y)*-1);
	   missionArea.set(0, 0, 
				         (translatedMissionArea.x + (obj->getArea().extent.x)), 
				         (translatedMissionArea.y + (obj->getArea().extent.y)));

			translatedPosition = playerPos + translatedMissionArea;
			transGuiPosition.x = translatedPosition.x;
			transGuiPosition.y = missionArea.extent.y - translatedPosition.y;

Now what should be happening here is the last line should be correcting for the apparent axis flip caused by a top-left orientation, but for some reason instead this is pushing my calculation way off center in terms of 'y' and in order for me to get to the "middle" of the map per say, I'm almost to the point of standing on the top 'y' boundary. Is there anything I'm doing wrong with this calculation here? Because this is getting to the point of frustration (I've been trying to solve this problem for 4 days now) where I'm simply going to drop it and forget about this completely...

EDIT: The coordinates of the image being used is determined by this:

radarBounds.set(transGuiPosition.x - (mRange/2), 
				            (transGuiPosition.y - (mRange/2)), 
				             mRange*2, mRange*2);

#10 *sigh* I seriously need a very very long coffee break or something...

Obviously I'm not going to have the correct render zone when I'm only rendering 1/4 of the top left side of the radar image and the remaining 3/4 is actually to the bottom right of the player...

Looks like I've just got one little position translation problem left on this and it should be working fine...

Point2F GuiAdvancedRadarCtrl::convertWSToGS(Point2F worldSpace) {
	if(missionArea.len_x() == 0 && missionArea.len_y() == 0) {
		Con::errorf("convertWSToGS() - Cannot convert space coordinates without reference object (MissionArea).");
		return Point2F(0, 0);
	}

	Point2F outCoords;
	outCoords.x = worldSpace.x;
	outCoords.y = missionArea.extent.y - worldSpace.y;

	return outCoords;
}

This is working for areas when y ~ ymap really well, but for some reason when y ~ y (mission area extent + mission area pos) it loses it's accuracy by a large factor (about 10m - 25m). So either I've got the translated mission area wrong (translated mission area being the mission area casted to (0, 0) on x,y, or the above code for the y calculation is wrong.

EDIT: Scratch all, I looked over the numbers and my calculations are correct. It's just the positioning that looks weird, but everything should be as is.

#11 Congratulations! Well done, time for a nice, cold beer, eh?

Glad you got it worked out. That's what I've always liked about you Robert - you're persistent and smart. Good show.

#12 Possibly... :x

The sad part is it turned out to be a huge and I do mean a huge novice mistake on my part in the end. I completely forgot that 'extent' was a constant value even throughout translations which is why I never saw the edges of the map when moving to the +x and the +y ends.

I'm now just getting all the last elements together and running through the last calculations. 'y' axis is now 100% done (surprisingly I got that done before 'x') and 'x' just needs an adjustment by the gui distance factor, which I am currently doing a few test runs on. Once I get that done, it's off to distance testing with AI, and then pretty much final packaging for the radar.

Hopefully all goes well and gets done soon enough, I know people really want a video of it, and I don't want to fail to deliver on that promise. :)

#13 Ah sweet sweet success, and finally! Still have a few little kinks to iron out but overall, I've got this down. Thanks again for the help guys.

#14 Hurray! Really nice to see you got that working!

It's still not 1400 hours over here, so I'll toast with coffee instead of beer ;)