How to get unnormalized texture coordinates ?
Skybuck Flying
My code tries to upload the texture to the gpu:
glTexImage2D( GL_TEXTURE_RECTANGLE_ARB, 0, GL_RGBA32F_ARB, Width, Height, 0,
GL_RGBA, GL_FLOAT, mTexture );
But it fails with "invalid operation" code 1282 I believe it was.
mTexture is an array of 4 floats so that's ok. width and height: 500x400.
Other code/gpgpu example does seem to work with this... I am not sure why ?
Maybe GL_TEXTURE_RECTANGLE_ARB is only valid for "render to texture" and not
"render to screen" ?
Me <- Confused.
Bye,
Skybuck.
Skybuck Flying
I think I figured it out...
It seems to be one or multiple of the texture parameters which are not valid
for this kind of texture....
I disabled all the parameters to use the default parameters to see if that
would help and it did help !
Now the shader seems to run ! and now I can go modify it to see if it
finally uses unnormalized texture coordinates ! ;)
Here are the parameters which are suspicious, don't know which ones yet:
// disabled:
(*
// after a texture is bound it's settings can be set.
glTexParameteri( mTextureTarget[vTextureIndex], GL_TEXTURE_MIN_FILTER,
GL_NEAREST );
glTexParameteri( mTextureTarget[vTextureIndex], GL_TEXTURE_MAG_FILTER,
GL_NEAREST );
// use only original texture no mipmap levels
glTexParameteri( mTextureTarget[vTextureIndex], GL_TEXTURE_MIN_LOD, 0 );
glTexParameteri( mTextureTarget[vTextureIndex], GL_TEXTURE_MAX_LOD, 0 );
// sets the mipmap levels to just one/original zero
glTexParameteri( mTextureTarget[vTextureIndex], GL_TEXTURE_BASE_LEVEL,
0 );
glTexParameteri( mTextureTarget[vTextureIndex], GL_TEXTURE_MAX_LEVEL, 0 );
// don't use border texels.
// produces strange vertical line to the left
glTexParameteri( mTextureTarget[vTextureIndex], GL_TEXTURE_WRAP_S,
GL_CLAMP_TO_EDGE );
glTexParameteri( mTextureTarget[vTextureIndex], GL_TEXTURE_WRAP_T,
GL_CLAMP_TO_EDGE );
// produces strange vertical line left and horizontal line bottom
// glTexParameteri( mTextureTarget[vTextureIndex], GL_TEXTURE_WRAP_S,
GL_CLAMP_TO_BORDER );
// glTexParameteri( mTextureTarget[vTextureIndex], GL_TEXTURE_WRAP_T,
GL_CLAMP_TO_BORDER );
// produces same strange vertical line as clamp to edge
// glTexParameteri( mTextureTarget[vTextureIndex], GL_TEXTURE_WRAP_S,
GL_CLAMP );
// glTexParameteri( mTextureTarget[vTextureIndex], GL_TEXTURE_WRAP_T,
GL_CLAMP );
// produces strange bottom horizontal line...
// glTexParameteri( mTextureTarget[vTextureIndex], GL_TEXTURE_WRAP_S,
GL_REPEAT );
// glTexParameteri( mTextureTarget[vTextureIndex], GL_TEXTURE_WRAP_T,
GL_REPEAT );
// turn mipmapping off just in case.
glTexParameteri( mTextureTarget[vTextureIndex], GL_GENERATE_MIPMAP,
GL_FALSE);
*)
Bye,
Skybuck ;) :) =D
Skybuck Flying
am trying to turn them off anyway out of "safety reasons" !:
// use only original texture no mipmap levels
// glTexParameteri( mTextureTarget[vTextureIndex], GL_TEXTURE_MIN_LOD, 0 );
// causes problem with GL_TEXTURE_RECTANGLE_ARB
// glTexParameteri( mTextureTarget[vTextureIndex], GL_TEXTURE_MAX_LOD, 0 );
// causes problem with GL_TEXTURE_RECTANGLE_ARB
// sets the mipmap levels to just one/original zero
// glTexParameteri( mTextureTarget[vTextureIndex], GL_TEXTURE_BASE_LEVEL,
0 ); // causes problem with GL_TEXTURE_RECTANGLE_ARB
// glTexParameteri( mTextureTarget[vTextureIndex], GL_TEXTURE_MAX_LEVEL,
0 ); // causes problem with GL_TEXTURE_RECTANGLE_ARB
// turn mipmapping off just in case.
// glTexParameteri( mTextureTarget[vTextureIndex], GL_GENERATE_MIPMAP,
GL_FALSE); // causes problem with GL_TEXTURE_RECTANGLE_ARB
Bunch of dumbasses ! :)
Fix your code you driver-dumbasses ! ;) :)
Bye,
Skybuck =D
Skybuck Flying
Now my shader not working anymore... all I see is the blue which is set in
the shader itself...
The shading/texture is invisible... I already removed the divisions....
Wacky ?!
Bye,
Skybuck.
Skybuck Flying
about "to render texture"
mTextureTarget[vTextureIndex] := GL_TEXTURE_RECTANGLE_ARB;
mTextureInternalFormat[vTextureIndex] := GL_RGBA32F_ARB;
mTexturePixelFormat[vTextureIndex] := GL_RGBA;
mTexturePixelType[vTextureIndex] := GL_FLOAT;
Now I go try some other settings...
Bye,
Skybuck.
Skybuck Flying
"Skybuck Flying" <Blood...@hotmail.com> wrote in message
news:1f16d$4ac1d404$d53372a9$16...@cache4.tilbu1.nb.home.nl...
> My conclusion for now, these settings don't work for "to screen", not sure
> about "to render texture"
>
> mTextureTarget[vTextureIndex] := GL_TEXTURE_RECTANGLE_ARB;
> mTextureInternalFormat[vTextureIndex] := GL_RGBA32F_ARB;
> mTexturePixelFormat[vTextureIndex] := GL_RGBA;
> mTexturePixelType[vTextureIndex] := GL_FLOAT;
^ I gave these settings some more tries... can't get it working... kinda
sux...
Having to normalize the coordinates myself would suck big time ?! Me
thinks..
Bye,
Skybuck.
Skybuck Flying
I decided to do one last test and then I would have given up...
However GL_TEXTURE_2D doesn't work anymore either ?!?
I think it might be because setting one of the parameters might turn out to
be crucial ?
Bye,
Skybuck.
Skybuck Flying
cgGLSetTextureParameter(mCGTexture, mTextureID[0] );
I tried the rectangle thing one more time... it really doesn't work for the
screen which totally sux...
Unless it maybe works for render to texture and then back to screen or so...
But why can't it do that in one time ?
Kinda weird.
For now I declare the rectangle thing DEAD.
^ Fucking piece of shit.
I wonder if there are any more "texture targets"
So far I only seen TEXTURE_2D and the rectangle shit.
Bye,
Skybuck.
Skybuck Flying
"glew" isn't used ?
But what do I know ;) Me cluessless about all of that stuffffff.
Bye,
Skybuck.
Skybuck Flying
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 MyFuckingValue/MyFuckingMaximum ;)
All the fucking time ?! ;)
Bye,
Skybuck.
Skybuck Flying
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 fuck 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/tutorials/jit-tut/jitterchapter43.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 shit load of nssty bullshit work ?! ;) :)
I hope it gonna be good and worth it... because I spent a shit load of time
trying to figure this shit out !
GJEZUS FUCKING CHRIST ?!
Pretty stupid that tex2D and texRECT is not the same ?
Same can be said for sampler2D and samplerRECT
^ Gjezus fucking christ ?!
Bye,
Skybuck =D
"Skybuck Flying" <Blood...@hotmail.com> wrote in message
news:f1d6a$4ac1e331$d53372a9$10...@cache2.tilbu1.nb.home.nl...
Skybuck Flying
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.
Skybuck Flying
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.
Skybuck Flying
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.
Skybuck Flying
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.
Skybuck Flying
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-fucked ! LOL.
Example of ass-fucking 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: Assfucking 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 fucking WEIRD !
It annoys the shit out of me ! =D (The not knowing LOL)
Bye,
Skybuck.
Skybuck Flying
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.
Skybuck Flying
What a fucking bug hunt this was ?!
I spent like at least 6 fucking hours trying to find this motherfucking BUG
!
And finally I found it ! MOtherfuckers !
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 shit open gl and it's fucking state machine... They
sometimes say it doesn't matter in what order you make the calls ?!
WELL FUCK THAT I SAY ! THAT'S BULLSHIT ! THAT'S OTHER MOTHERFUCKING 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 motherfucking vertical motherfucking 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 FUCKING SHIT BATMAN ! ;) =D
I, FUCKING, SKYBUCK, LOL, AM FUCKING AWESOME !
I AM FUCKING GREAT !
FUCKING ADMIT IT YOU FUCKING FUCKING FUCKING 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 ASSFUCKING OWNAGE !
LOL.
OK I AM GETTING A LITTLE BIT TOO NASTY WITH THE ASSFUCKING ! ;) :)
BUT I FEEL A LITTLE BIT ASSFUCKED MYSELF WITH ALL THIS MISINFORMATION AND
CRAP ON THE FUCKING 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 FUCKING 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 fucking 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
Skybuck Flying
decently:
http://basic4gl.wikispaces.com/2D+Drawing+in+OpenGL
I QUOTE THIS MOTHERFUCKER BECAUSE HE IS FUCKING 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.
Skybuck Flying
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.
Skybuck Flying
Usually coordinate systems are like:
-1 to 1
To give a simple example
-0.49 would still be considered 0.
+0.49 would still be considered 0.
So 0 has a range from -0.49 to 0.49.
And so forth...
So if you wanted to draw pixel 0 in such a coordinate system you would need
to draw the following quad:
(-0.49, -0.49) to (0.49, 0.49).
However since the coordinate system is positive only... it's therefore
shifted to the right by 0.5
So 0 ranges from 0.00 to 0.99
So 1 ranges from 1.00 to 1.99
I am not sure if this information could help anybody...
Maybe ceil would be best... ;)
For now I will let it be ! ;)
Bye,
Skybuck.
Skybuck Flying
In screen space 0 is considered to range from 0 to 0.99
So truncating it is ! ;)
Bye,
Skybuck.
Ralf Kaiser
>
> Bye,
> Skybuck.
>
PLEASE STOP TALKING TO YOURSELF ON THE NET!!!
Nobody wants to read this! If you need help, please vistit a mental hospital,
they sure can help you with your problems. But newsgroups are definitively the
wrong place.
fungus
>
> PLEASE STOP TALKING TO YOURSELF ON THE NET!!!
>
> Nobody wants to read this! If you need help, please vistit a mental hospital,
You beat me to it. I was going to mention the exact same thing
- posting 22 replies to yourself on Usenet (in a single thread)
is surely a sign of mental problems.
--
<\___/>
/ O O \
\_____/ FTB.
Skybuck Flying
My fingers type well.
My brain works well cause I find solutions.
Waiting for a bunch of slowass turds to answer my questions and solve my
problems would be a sign of mental problems ! ;)
HAHA
Gadfly
people. That way you could have a permanent record of what you did and
everyone would be happy.
hanukas
So you admit that you have problems? Understanding what you are doing
will lessen your problems a lot, take a look at OGL specification some
time.
Skybuck Flying
Frame Buffer Object has been implemented.
I just did a little testing... and something interesting popped up.
By using these floating point formats suddenly everything is compatible
again:
mTextureTarget[vTextureIndex] := GL_TEXTURE_RECTANGLE_ARB;
mTextureInternalFormat[vTextureIndex] := GL_RGBA32F_ARB;
// mTextureInternalFormat[vTextureIndex] := GL_FLOAT_RGBA32_NV;
mTexturePixelFormat[vTextureIndex] := GL_RGBA;
mTexturePixelType[vTextureIndex] := GL_FLOAT;
Which is kinda odd... but I have a theory.
Somehow there is a difference between rendering to screen and rendering to
texture.
When the texture is rendered to the screen then the opengl engine or the
driver or the hardware will convert the floating point texture to
colors/rgba's/bytes.
It's during that process that something odd most be happening... somehow the
opengl engine/driver/hardware must be using a different rounding
technique... maybe it's using truncations or ceils I don't know...
Could/would be interesting to find out...
If I now use this than there will be differences between input and output
texture.. which stay the same... no processing is done yet they become
different:
mTextureTarget[vTextureIndex] := GL_TEXTURE_RECTANGLE_ARB;
mTextureInternalFormat[vTextureIndex] := GL_RGBA;
mTexturePixelFormat[vTextureIndex] := GL_RGBA;
mTexturePixelType[vTextureIndex] := GL_FLOAT;
^ Kinda odd...
I am welcome to any other explanations and theories ! ;)
But I think I already covered it with the "converting to colors theorie..."
I could try switching back to the above one... and try ceiling and
flooring... to see if that makes a difference ! ;)
Bye,
Skybuck.
Skybuck Flying
Bye,
Skybuck.
Skybuck Flying
Bye,
Skybuck.
Wolfgang Draxinger
> Sharing is caring ;) :)
No. In this case it's vandalism, just like bad graffiti.
--
OpenGL tip #42:
How to exactly map texture texels to screen pixels:
<http://preview.tinyurl.com/cgndc8>
fungus
> It's a sign of being healthy...
> My fingers type well.
> My brain works well cause I find solutions.
These days there's things called "blogs" where you
can type to your heart's content.
> Waiting for a bunch of slowass turds to answer my questions and solve my
> problems would be a sign of mental problems ! ;)
You honestly think anybody here is interested in
answering your "questions"?
--
<\___/>
/ O O \
\_____/ FTB.
http://www.topaz3d.com/ - New 3D editor for real time simulation
Skybuck Flying
This is your first and at the same time last warning.
Any further pollution from you will be dealt with swiftly ! ;)
In other words go nag somewhere else.
Bye,
Skybuck.
Ralf Kaiser
> Ok dude if you have nothing about opengl to say then stay out of my threads.
>
Hey, that is a newsgroup. It ist _NOT YOUR_ thread! Stay out of OUR newsgroup
with your nonsense!
Charles E Hardwidge
news:ha0bh6$ad9$1...@online.de...
>
> Hey, that is a newsgroup. It ist _NOT YOUR_ thread! Stay out of OUR
> newsgroup with your nonsense!
I don't read SF's posts or reply to them. They're best ignored as any
response just feeds the monster.
The OpenGL newsgroup is organising a standard cut and paste warning and a
moderated OpenGL newsgroup server.
Other newsgroups and new visitors may like to consider this strategy.
--
Charles E Hardwidge
Skybuck Flying
in FX Composer 2.5...
Today I tried to change some code from tex2D to texRECT in FX Composer 2.5
but I could not get it working...
Possible explanantions for failure of working in fx composer 2.5:
1. I don't get it.
2. FX Composer 2.5 has a problem.
3. Maybe FX Composer 2.5 needs something enabled... I did see some #comments
in other assembly source which enabled some ARB thingy... I haven't tried
that yet. These would be called "extensions" which would look like:
#extension_bla enable or something like that.
For now I will keep using tex2D and use multiplications to go from
normalized coordinates to unnormalized coordinates... I am not completely
happy about it because it might cost some performance ?!?
Or maybe the compiler is smart enough to detect that it should use
unnormalized instructions ? Me not sure about that ;)
Writing code with normalized coordinates is easy though since everything is
normalized... so it's nice and consistent once "you" = me =D get the hang of
it ;) :)
Bye,
Skybuck.