How to get unnormalized texture coordinates ?

Finally got it working !

I search HIGH, I searched _low_

I saw people all over the internet mentioning that it was working and that
they were making stupid mistakes.

I was like how the **** can they get it working and now me huh ?! Must
try harder me thought...

So me searched HIGH and _low_ everywhere... in opengl api, just
everywhere...

Finally I searched with google for: "cg arb rectangular sampler"

Because I think I started to wonder if maybe I had to use special keywords
for the shader code...

So I came across this guy/website/tutorial:

http://www.cycling74.com/docs/max5/t...chapter43.html

And he shows an example of how to use a rectangular texture !

And then I tested it in FX Composer 2.5 first to make sure that it worked
there... (However FX Composer 2.5 cannot render the texture from a file
because it says "auto texture" I guess, me not sure about that but anyway
the blue constant was showing so I got hopefull knowing that at least it
compiled and all keywords recgonized... I had to mess with it a bit further
but finally it worked out well).

So the secret is a couple of things:

1. Must use "samplerRECT" instead of "sampler2D".

Example:

samplerRECT mTexture = sampler_state
{
// Texture = <SpaceShipTexture>;
MinFilter = Linear;
MipFilter = Linear;
MagFilter = Linear;
AddressU = Clamp;
AddressV = Clamp;
};

2. Must use: "sampler2DRect" instead of sampler2D":

// struct etc
const uniform sampler2DRect mTexture;

3. Must use: "texRECT" function instead of "tex2D"

And voila !!!!!!

Texture coordinates can now be "unnormalized" !

YEAH FOR THAT !

That gonna save me a **** load of nssty bullshit work ?!

I hope it gonna be good and worth it... because I spent a **** load of time
trying to figure this **** out !

GJEZUS ****ING CHRIST ?!

Pretty stupid that tex2D and texRECT is not the same ?

Same can be said for sampler2D and samplerRECT

^ Gjezus ****ing christ ?!

Bye,
Skybuck =D











"Skybuck Flying" <> wrote in message
news:f1d6a$4ac1e331$d53372a9$ .home.nl...
>I tried one last thing:
>
> mTextureTarget[vTextureIndex] := GL_TEXTURE_RECTANGLE_ARB;
> mTextureInternalFormat[vTextureIndex] := GL_RGBA;
> mTexturePixelFormat[vTextureIndex] := GL_RGBA;
> mTexturePixelType[vTextureIndex] := GL_FLOAT;
>
> ^ Also not working (
>
> Oh well... been trying to find any other texture targets... so far nada.
>
> I guess I will have to be using My****ingValue/My****ingMaximum
>
> All the ****ing time ?!
>
> Bye,
> Skybuck.
>

There is now only one little problem remaining which for me is probably not
much of a problem...

The strange vertical line remains when * is enabled and the other two lines
disabled...

Can anybody shed some light on this ?!?!?

float4x4 WorldViewProj : WorldViewProjection;

struct TVertexShaderIn
{
float3 mPosition : POSITION;
float2 mTextureCoordinate0 : TEXCOORD0;
};

struct TVertexShaderOut
{
float4 mPosition : POSITION;
float2 mTextureCoordinate0 : TEXCOORD0;
};

// return routines/functions do work in nvidia shader debugger:
TVertexShaderOut TVertexShader_Main( in TVertexShaderIn ParaIn )
{
TVertexShaderOut ParaOut;

ParaOut.mPosition = mul(WorldViewProj, float4(ParaIn.mPosition.xyz, 1.0));
// ParaOut.mTextureCoordinate0 = ParaIn.mTextureCoordinate0; // * causes
strange vertical line (left side)
ParaOut.mTextureCoordinate0.x = ParaIn.mPosition.x;
ParaOut.mTextureCoordinate0.y = ParaIn.mPosition.y;

return ParaOut;
}

Bye,
Skybuck.

Also the current solution is still not perfect...

It's not a perfect copy... actually it's worse... if I remember correctly
GL_TEXTURE_2D was ultimately perfected...

Now suddenly some pixels are slightly different off by 1... hmm...

Bye,
Skybuck.

The problem could be related to gluOrtho2D investigating it now...

Otherwise I see little other possibilities... except for rare floating point
issue's or so...

Maybe it's because of the nvidia floating point format ?

Hmm...

Bye,
Skybuck.

It's starting to see that opengl might be unsuited for gpgpu computing at
least when it comes to rendering to the screen... and also when it comes to
texture coordinates and/or rectangle_arb...

Ortho2D is inexact...

(However with texture_2d I got it working by calculating the texture
coordinates manually... this could mean a bug somewhere in opengl... really
weird)

Me wonders if DirectX is better ?!?

Bye,
Skybuck.

HeeeeeeeeELLLLLLLEEEEELLLUUUUUYAAAA.

The incorrect colors problem was driving me nuts ?!

For some reason the colors where slightly incorrect.

It turns out it's a floating point format problem. Apperently there are two
floating point formats...
or even multiple...

One must use the correct floating point format otherwise you gonna get
ass-****ed ! LOL.

Example of ass-****ing in action:

// CAUSES PROBLEMS !:
mTextureTarget[vTextureIndex] := GL_TEXTURE_RECTANGLE_ARB;
mTextureInternalFormat[vTextureIndex] := GL_RGBA32F_ARB; // CAUSES
PROBLEMS
// mTextureInternalFormat[vTextureIndex] := GL_FLOAT_RGBA32_NV; // CAUSES
PROBLEMS AS WELL
mTexturePixelFormat[vTextureIndex] := GL_RGBA;
mTexturePixelType[vTextureIndex] := GL_FLOAT;

// FIXES PROBLEMS !:
mTextureTarget[vTextureIndex] := GL_TEXTURE_RECTANGLE_ARB;
mTextureInternalFormat[vTextureIndex] := GL_RGBA; // FIXES PROBLEMS
mTexturePixelFormat[vTextureIndex] := GL_RGBA;
mTexturePixelType[vTextureIndex] := GL_FLOAT;

Conclusion:

ARB stands for: Ass****ing Retards & Bitches
NV stands for: Not Very nice.

Only god knows why they would make two different floating point formats !
LOL.

This code works just fine (NOT see below) as long as the correct floating
point format is used:

glViewport(0,0,OpenGLv2.Width,OpenGLv2.Height); //
Resetuje aktuální nastavení

glMatrixMode(GL_PROJECTION);
glLoadIdentity;
gluOrtho2D(0.0 - 0.5, OpenGLv2.Width-0.5, OpenGLv2.Height-0.5, 0.0-0.5);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity;

Except I cheered a little bit too early... while the colors are corrected...
the weird vert line remains on the left side if I used TEXTCOORD0 as input
and output.

Almost seems like a dirty hack or so by some driver writer to do a texture
copy or so ?!?

Really strange line Can't explain it for now...

It's not much of problem as I wrote before but I WANT PERFECTION !

AND I WANNA KNOW WHAT CAUSES IT because it's ****ing WEIRD !

It annoys the **** out of me ! =D (The not knowing LOL)

Bye,
Skybuck.

**** posted this with the wrong subject line....

Anyway subject line corrected.

Colors are now correct thanks to proper floating point format...

Weird left vertical line remains when using the vertex shader textCoord0 as
in and output...

^ WEIRD.

When using positions it's solved... ? hmm...

Bye,
Skybuck.

HOLYSHIT DUDE !

What a ****ing bug hunt this was ?!

I spent like at least 6 ****ing hours trying to find this mother****ing BUG
!

And finally I found it ! MOther****ers !

I was taking another look at the glQuad technique of the original gpgpu
tutorial which mysteriously first didn't work then I changed a little bit of
code here and there... and then it did work !

And then I noticed how it did something completely opposite:

Here is the code:

glBegin(GL_QUADS);
glTexCoord2f(0.0, 0.0);
glVertex2f(0.0, 0.0);
glTexCoord2f(mTextureWidth[0], 0.0);
glVertex2f(mTextureWidth[0], 0.0);
glTexCoord2f(mTextureWidth[0], mTextureHeight[0]);
glVertex2f(mTextureWidth[0], mTextureHeight[0]);
glTexCoord2f(0.0, mTextureHeight[0]);
glVertex2f(0.0, mTextureHeight[0]);
glEnd();

Now take a look at my (incorrect code):

procedure CreateVertexPoints(ParaWidth: integer; ParaHeight: integer);
var
vX: integer;
vY: integer;
begin
glBegin(GL_POINTS);
for vY := 0 to ParaHeight - 1 do
begin
for vX := 0 to ParaWidth - 1 do
begin
glVertex2f( vX, vY );
glTexCoord2f( vX, vY );
end;
end;
glEnd;
end;

There are two major problems with this code ?!

Not just one, but two ! Can you spot which ones ?!

And now for the correct code !

procedure CreateVertexPoints(ParaWidth: integer; ParaHeight: integer);
var
vX: integer;
vY: integer;
begin
glBegin(GL_POINTS);
for vY := 0 to ParaHeight - 1 do
begin
for vX := 0 to ParaWidth - 1 do
begin
glTexCoord2f( vX, vY );
glVertex2f( vX + 0.5, vY + 0.5 );
end;
end;
glEnd;
end;

TATA ! =D

And the explanation is as follows:

1. First of all the verteces must be in the center of the pixels.

Therefore each vertex must be + 0.5 because that's the center of a pixel !

Therefore the correct matrix setup code is actually very simple:

glViewport(0,0,OpenGLv2.Width,OpenGLv2.Height); //
Resetuje aktuální nastavení
glMatrixMode(GL_PROJECTION);
glLoadIdentity;
gluOrtho2D(0.0, OpenGLv2.Width, OpenGLv2.Height, 0.0);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity;

^ This is the correct code... anything else that is posted on the internet
IS BULLSHIT 100% garantueed !

Now for the second bug ! And oh boy was it hard to find ! HERE IT COMES ?!

ARE YOU READY FOR THE SPLATTER ALL OVER YOUR FACE ?!

2. The second bug is with the order of the api calls. Remember I am noob...
I don't know jack **** open gl and it's ****ing state machine... They
sometimes say it doesn't matter in what order you make the calls ?!

WELL **** THAT I SAY ! THAT'S BULLSHIT ! THAT'S OTHER MOTHER****ING BULLSHIT
! IT DOES MATTER ! LOW AND BEHOLD:

The problem was with this code in create vertices:

glVertex2f( vX, vY );
glTexCoord2f( vX, vY );

It's in the wrong ORDER !

It must be like this:

glTexCoord2f( vX, vY );
glVertex2f( vX, vY );

That takes care of the stupid mother****ing vertical mother****ing LINE !

YESSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS

Then add a little bit of 0.5 and you half yourself a nice decent fix !

Now the QUAD WORKS !
Now the POINTS WORK !
Now the TEXTURE COORDINATES WORK !
Now the COLORS WORK !

HOLY ****ING **** BATMAN ! =D

I, ****ING, SKYBUCK, LOL, AM ****ING AWESOME !

I AM ****ING GREAT !

****ING ADMIT IT YOU ****ING ****ING ****ING PIECES OF NOOOOOBAAAAASSSSSESSS
! =D

YEAH BABY.

FEELS GOOD TO KNOW THAT I OWNED AAAAAAAALLLLLLLLLL OF YOUR ASSES !

YES ME SKYBUCK ULTIMATE BUG HUNTER ! HIHIHIHIHHIH LOL.

NO BUG ESCAPES FROM ME BABY !

There has only been one bug in my entire live that I could not find until
this day and it was in my game called Combat... an animation of an exploded
ship... that was pre-calculated into an animation array of particles and
such... I never found that bug... even after many years porting it to
Delphi... me never found it... it remains a mystery to this day. I shall
call it "THE SKYBUCK/COMBAT MYSTERY BUG" =D

AND NOW IT'S TIME FOR ME TO GO ONTO SOME SERIOUS GPGPU ASS****ING OWNAGE !
LOL.

OK I AM GETTING A LITTLE BIT TOO NASTY WITH THE ASS****ING !

BUT I FEEL A LITTLE BIT ASS****ED MYSELF WITH ALL THIS MISINFORMATION AND
CRAP ON THE ****ING INTERNET !

I, SKYBUCK, CRAP BUSTER ! YEAH ! =D

BUSTING CRAP ! YUP THATS ME HAHAHAHAHAHA LOL.

YES, IN CASE YOU COULDN'T TELL, I AM VERY HAPPY !

I WAS GETTING DOUBTS ABOUT OPENGL...

I WAS ABOUT TO TELL YOU GUYS TO SHOVE OPENGL UP YOUR ****ING ASSES !

GLAD I DIDNT DO THAT CAUSE IT TURNS OUT TO BE GREAT !

AT LEAST SO FAR SO GOOD !

THIS TIME I BELIEVE IT S THE REAL THING BABY ! YEAAAAH !!!!!!!!!!!!!!!

THIS HISTORICAL MOMENT IN THE PROGRAMMING OF OPENGL and DOMINATING SKYBUCK
SKILLS...

NEEDS TO BE CELIBRATED WITH A MUSIC SONG/VIDEO:

HERE IT COMES BABY:

http://www.youtube.com/watch?v=YAAflFyWNPo

"The real thing by 2 unlimited !" <- Dutch people too !

Yeah some of us dutch people simply ****ing OWN HAHAHAHAHAHAHA ! LOL.

Though it's slightly low quality sound so here is a remixed version...

It's not the real thing... but ok

http://www.youtube.com/watch?v=dYfDqpLuExs

It is kinda funky !

REMMMIIIXXXXX YEAH BABY ^

Bye,
Skybuck =D

Also this website helped, which managed to explain it one more time
decently:

http://basic4gl.wikispaces.com/2D+Drawing+in+OpenGL

I QUOTE THIS MOTHER****ER BECAUSE HE IS ****ING AWESOME JUST LIKE ME
HAHAHAHAHA LOL:

"
To achieve exact pixelization (pixel-precise drawing), it's important to
understand that coordinates in OpenGL are technically not tied to the actual
screen pixels, so even if you set up 2D projection as explained above, you
still specify the locations with higher than pixel granularity. That is,
(0,0) corresponds to the top-left corner inside the top-left pixel, while
(0.5, 0.5) corresponds to the center of that pixel. Forgetting about this
can easily lead to quite unpredictable misplacements of primitives and to
unwanted anti-aliasing blur. For example, if you want to lit pixels using
GL_POINTS, you should use coordinates that end with a half (like 10.5
instead of 10), as in principle you want to put that point at the center of
the pixel, not at the corner of it, as in the last case the point will
overlap with the neighbor pixels (because an OpenGL "point" of default size
1 is in fact a 1x1 square), hence possibly painting some of those screen
pixels. But if for example you draw lines (GL_LINES) or polygons (GL_QUADS,
etc.), you want to put the vertices at the edges of the pixels, so you will
often use integer coordinates.
"

However there is still something weird going on between GL_POINTS and
GL_QUADS...

The gl_points need to be in the center...

It would only be logical to assume the quad need to be in the center as
well...

And it would be logical to assume that the coordinates for the quad would be
0 to width-1
Possible all offset by +0.5

However this does not work and would leave the last bottom and last right
line unused ?!

Suppose the quad was 2 pixels by 2 pixels than the following would happen:
(I will ignore the second row just focus on the x):

0.....1......2
0.5 1.5

It would be logic to assume the quad would need to be at 0.5 to 1.5

However this would create a little oddity:

1.5 - 0.5 = 1 ?!?

Didn't I just say the quad was 2 ?!

(Correct formula for size is (x2-x1)+1 )

So solve this weirdness one can view it as follows:

The center of the pixel is at 0.5 and 0.5

However the pixel does have body...

The body of the pixel or let's say radius is 0.5

So pixel dimension is:

0..........1
.. |
.. |
.. X |
.. |
.. |
1..........|

The quad would be:

0..........1..........2
.. | |
.. | |
.. X | X |
.. | |
.. | |
1..........|..........|
.. | |
.. | |
.. X | X |
.. | |
.. | |
2..........|..........|

So if I would say:

Quad range is 0 to Width-1 and 0 to Height-1 then I believe it would more or
less be correct...

Since this would give 0 and 1

Offsetted by 0.5 is exactly the correct coordinates:

0.5 and 1.5

However opengl still expects me to set 0 to 2 which is kinda weird ?!

I wonder what the under lieing reason would be...

Is it an inaccuracy ? Is it an optimization ?

Can it be logically/conceptually explained why that is ?

I doubt it though !

Bye,
Skybuck.

Ok I think I have a logical reason why the quad ranges from 0 to 2

And not from 0.5 to 1.5

For a quad it would not make sense to speak of body or radius...

For pixels that might make sense...

So to make no doubts about what pixels the quad encapsulates it's 0 to 2.

Which means everything between 0.....1......2

Is only two pixels fully lit which is exactly it's with 2

I am sure I will forget this in the future !

However what about triangles and lines ? Could get weird !

However I am not even gonna go there !

Maybe triangles and lines work more like points ? But guy said no ? Hmm..

Bye,
Skybuck.