TVScreen2DImmediate.Draw_Texture

[Korax]

I've got a problem with the dimensions this function generates.
Its the only one I've tried, not sure of theres others doing the same thing.

It seems to create 2D surfaces with an extra pixel x and y.

To Explain:

Say I have a loaded texture I want to render 2D (console, conchars etc) and now this texture have a width and height of 128x128 and I want to begin render it at, say, position 100x100.

(x1) x = 100
(y1) y = 100
(x2) x + 128
(y2) y + 128

So i'm expecting:
x1 should plot at 100, y1 should plot at 100.
x2 should plot at 228, y2 should plot at 228.

x2 and y2 actually plots at 229.

I did another test by plotting another textureless Draw_Texture() and this time plotting x1 and y1 using the previous Draw_Texture()'s x2 and x2 coords.
(I += the texture width and height.. in this case being 128)

Instead of the vertexes touching each other there was a 1 pixel overlap.

To get the function to render correctly on the screen for a 128 image 1:1 I needed to do this: (since the surface renders as 129x129)

(x1) x = 100
(y1) y = 100
(x2) x + 128 - 1
(y2) y + 128 - 1

It doesnt feel right.

I also tried using Draw_Custom() but couldnt get that to work. (pref)


MTV3D65.TV_CUSTOM2DVERTEX[] c2dv = new MTV3D65.TV_CUSTOM2DVERTEX[4];

c2dv[0].x = x + 8;
c2dv[0].y = y + 8;
c2dv[0].tu = fcol + size;
c2dv[0].tv = frow + size;

c2dv[1].x = x + 8;
c2dv[1].y = y;
c2dv[1].tu = fcol + size;
c2dv[1].tv = frow;

c2dv[2].x = x;
c2dv[2].y = y;
c2dv[2].tu = fcol;
c2dv[2].tv = frow;

c2dv[3].x = x;
c2dv[3].y = y + 8;
c2dv[3].tu = fcol;
c2dv[3].tv = frow + size;

CProgram.vTVScreen2DImmediate.Draw_Custom(CProgram.vTVGlobals.GetTex(conchars.name), MTV3D65.CONST_TV_PRIMITIVETYPE.TV_TRIANGLEFAN, c2dv, 4);

[sybixsus]

That's not a bug, that's correct.

If it rendered from 100-228 it would be 129 pixels wide, not 128. It's probably easier if I bring the numbers right down. If an image is drawn from 100 to 102, that's three pixels, right? The pixel at 100, the pixel at 101 and the pixel at 102. So yes, you always have to calculate 2d drawing by saying position+width-1,position+height-1.

[Korax]

The way I reason is that the 2D surfaces are built with vertexes and not pixels.
If that was the case then we should not have a screen coordinate value of 0, because then we wont have 640, we will have 641 if you count 0.. if we are saying pixels and not vertexes.

What I'm saying is rendering with primitives orthographically with vertexes should at least match how they are done for example in OpenGL.

Rendering on my values in OpenGL renders orthographically correct results, but rendering with TV3D gives this 1pixel extra on each dimention.

If surfaces are rendered as pixel points and not vertex points then position 0, 0 should be invalid/offscreen?

Basically, what happens is this: 0 + 640 = 641.

It doesnt feel correct, doing a -1 compensation everywhere sounds insane.

[newborn]

It doesnt feel correct, doing a -1 compensation everywhere sounds insane.

Yep, but since there is no other way, thats what we all do: insane stuff 

[sybixsus]

The way I reason is that the 2D surfaces are built with vertexes and not pixels.

Well by this argument, you don't want 0 and 640 at all, because those are pixel units. Drawing in vertex units would be between 0 and 1. Honestly, I can't think of another engine which does 2D in 3D differently to how TV does it, and I've used a lot. It's just human nature to think in pixels when you're drawing 2d.

If that was the case then we should not have a screen coordinate value of 0, because then we wont have 640, we will have 641

Correct, we shouldn't have a 640, and from my results, we don't have one.

What I'm saying is rendering with primitives orthographically with vertexes should at least match how they are done for example in OpenGL.

Well by that argument, TV should use a right-handed coordinate system too. Sorry, but TV doesn't even use OpenGL so there's no logical reason for TV to ape OpenGL.

It doesnt feel correct, doing a -1 compensation everywhere sounds insane.

It doesn't feel correct to you because you're used to OpenGL. Lots of things will be different moving from OpenGL to an API built on DirectX. Things working on ATI drivers, for example. (Joke!)

I don't really see the problem, to be honest. If you really find it awkward, just wrap TV's drawing commands with a function which subtracts 1. Then you only ever have to do it once.

[Korax]

Is TV3D's way of working with 2D primitives based on how DirectX handles 2D primitived.
I'm asking because I didnt do any 2D work on DirectX.

Basically I'm asking if the method/way TV3D does it simmilar to a general DirectX way of doing 2D operations using primitives?

Since I'm only experienced in OpenGL methods, so my arguments are based on that.

[sybixsus]

I have no idea how DirectX handles 2d primitives, which was kind of my point. Most people using TV3D and engines like it are doing so because they don't want to have to deal with such low level thinking.

[kwazai]

Is TV3D's way of working with 2D primitives based on how DirectX handles 2D primitived.
I'm asking because I didnt do any 2D work on DirectX.

Basically I'm asking if the method/way TV3D does it simmilar to a general DirectX way of doing 2D operations using primitives?

Since I'm only experienced in OpenGL methods, so my arguments are based on that.

I've been reading a book on game programming math which is based on DX rather than opengl and some of the math is backwards for opengl (or viceversa). (column vectors verus rowvectors for matrix operations).
mike