I have this OpenGltexture of 6432 pixels but I only want to show 5432 pixels…
So I did this:
glBegin(GL_QUADS);
glTexCoord2f(0, 0); glVertex2i(x, y);
glTexCoord2f((54.00/64.00), 0); glVertex2i(x+w, y);
glTexCoord2f((54.00/64.00), 1); glVertex2i(x+w, y+h);
glTexCoord2f(0, 1); glVertex2i(x, y+h);
glEnd();
Isn’t there a nicer way to do this?? some kind of clipping in the texture or
something… somthing that doesn’t slow my program down ofcourse 
Thx.
Mein Mein wrote:
I have this OpenGltexture of 6432 pixels but I only want to show
5432 pixels… So I did this:glBegin(GL_QUADS); glTexCoord2f(0, 0); glVertex2i(x, y);
glTexCoord2f((54.00/64.00), 0); glVertex2i(x+w, y);
glTexCoord2f((54.00/64.00), 1); glVertex2i(x+w, y+h);
glTexCoord2f(0, 1); glVertex2i(x, y+h); glEnd();Isn’t there a nicer way to do this?? some kind of clipping in the
texture or something… somthing that doesn’t slow my program down
ofcourse
No, this is the proper way to do it.
Regards,
\Mikkel Gjoel
Mein Mein wrote:
Isn’t there a nicer way to do this?? some kind of clipping in the texture or
something… somthing that doesn’t slow my program down ofcourse
Division is always slow on computers. They can add and multiply all you
could possibly want – but subtraction and division are gonna be slow.
Try pre-setting the amount you want:
float shownSize = 54f / 64f;
…
glBegin(GL_QUADS);
glTexCoord2f(0, 0); glVertex2i(x, y);
glTexCoord2f(shownSize, 0); glVertex2i(x+w, y);
glTexCoord2f(shownSize, 1); glVertex2i(x+w, y+h);
glTexCoord2f(0, 1); glVertex2i(x, y+h);
glEnd();
Goes back to the old days of programming when answers to hard
mathematical computations were stored in lookup tables rather than
calculated on the fly. (Okay, not exactly the same thing.) It’s a
great tool to use! I mean, REALLY great!
–Scott
PS: In looking back, I realize that you didn’t mention having slowdowns
already… But still this technique can help make things easier to look
at and immediately understand what’s going on in the code.
Also, why not make a texture struct (or object or something – I use
Java, so I’m not familiar with what’s best in C++) and inside you can
store the texture id, and the left, top, right, and bottom sides of your
texture in floats. This would help for a tile-based solution where you
load ONE texture which is broken into smaller parts.
Anyway, my $.02.
Mein Mein wrote:
Isn’t there a nicer way to do this?? some kind of clipping in the texture or
something… somthing that doesn’t slow my program down ofcourseDivision is always slow on computers. They can add and multiply all you
could possibly want – but subtraction and division are gonna be slow.
Try pre-setting the amount you want:float shownSize = 54f / 64f;
In this modern world you might find that:
a) floating point division is not slow enough to worry about.
b) any good compiler will do this optimization for you.
c) any good compiler will not only do this for you, but will do when it
matters and do something else when it doesn’t.
d) you should only ever spend time worrying about this kind of
optimization when your code is running to slow and only then when a
profiler has shown that changing it will actually make a difference.
e) you get much more performance improvement by worrying about high
level algorithms.
f) if you are going to worry about little details worry about how
readable the code is, not whether or not you reduced the number of
operators in your source code. See b and c for why.
Seriously, you only have so long to live, why waste any of the time you
have worrying about things that don’t make any difference?
Bob PendletonOn Wed, 2004-11-17 at 16:16, Scott Harper wrote:
…
glBegin(GL_QUADS);
glTexCoord2f(0, 0); glVertex2i(x, y);
glTexCoord2f(shownSize, 0); glVertex2i(x+w, y);
glTexCoord2f(shownSize, 1); glVertex2i(x+w, y+h);
glTexCoord2f(0, 1); glVertex2i(x, y+h);
glEnd();Goes back to the old days of programming when answers to hard
mathematical computations were stored in lookup tables rather than
calculated on the fly. (Okay, not exactly the same thing.) It’s a
great tool to use! I mean, REALLY great!–Scott
PS: In looking back, I realize that you didn’t mention having slowdowns
already… But still this technique can help make things easier to look
at and immediately understand what’s going on in the code.Also, why not make a texture struct (or object or something – I use
Java, so I’m not familiar with what’s best in C++) and inside you can
store the texture id, and the left, top, right, and bottom sides of your
texture in floats. This would help for a tile-based solution where you
load ONE texture which is broken into smaller parts.Anyway, my $.02.
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±-------------------------------------+
Mein Mein wrote:
Isn’t there a nicer way to do this?? some kind of clipping in the texture
or something… somthing that doesn’t slow my program down ofcourseDivision is always slow on computers. They can add and multiply all you
could possibly want – but subtraction and division are gonna be slow.
Try pre-setting the amount you want:
Most (all?) C compilers in use today are going to do the 54.f/64.f calculation
at compile time and hard-code the result into the two orginal glTexCoord2f
calls.
In fact, the following code is going to hurt performance more than the
original, because it requires assembly instructions to push the float
shownSize onto the stack. If, however, you were to throw a “const” in there,
the result should be the same as the original code.
The only way I can think of to make this more efficient, is to change the
first and last glTexCoord2f calls that use only 0 or 1 into glTexCoord2s(),
but the speed difference there is negligible, unless you’re using this code
fairly often, or if you need the time to do alot of other things.
float shownSize = 54f / 64f;
…
glBegin(GL_QUADS);
glTexCoord2f(0, 0); glVertex2i(x, y);
glTexCoord2f(shownSize, 0); glVertex2i(x+w, y);
glTexCoord2f(shownSize, 1); glVertex2i(x+w, y+h);
glTexCoord2f(0, 1); glVertex2i(x, y+h);
glEnd();Goes back to the old days of programming when answers to hard
mathematical computations were stored in lookup tables rather than
calculated on the fly. (Okay, not exactly the same thing.) It’s a
great tool to use! I mean, REALLY great!
Lookup tables are used in cases where it will be more efficient (in preportion
to the loss in precision) to compute an integer offset, and load from that
offset, than to compute a precise result.On Wednesday 17 November 2004 03:16 pm, Scott Harper wrote:
–Scott
PS: In looking back, I realize that you didn’t mention having slowdowns
already… But still this technique can help make things easier to look
at and immediately understand what’s going on in the code.Also, why not make a texture struct (or object or something – I use
Java, so I’m not familiar with what’s best in C++) and inside you can
store the texture id, and the left, top, right, and bottom sides of your
texture in floats. This would help for a tile-based solution where you
load ONE texture which is broken into smaller parts.Anyway, my $.02.
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
sigh And here I thought I’d picked up some useful information and
could pass it along. Ah, well. Thanks for the corrections.
–Scott
John Silicon wrote:
…stuff…
Mein Mein wrote:
Isn’t there a nicer way to do this?? some kind of clipping in the texture
or something… somthing that doesn’t slow my program down ofcourseDivision is always slow on computers. They can add and multiply all you
could possibly want – but subtraction and division are gonna be slow.
Try pre-setting the amount you want:Most (all?) C compilers in use today are going to do the 54.f/64.f calculation
at compile time and hard-code the result into the two orginal glTexCoord2f
calls.In fact, the following code is going to hurt performance more than the
original, because it requires assembly instructions to push the float
shownSize onto the stack. If, however, you were to throw a “const” in there,
the result should be the same as the original code.
Compilers that do reasonable constant folding will actually treat
shownSize as a constant no matter how it is declared and only
materialize it as a variable if it occurs on the left hand side of the
assignment operator.
I wonder how much time we could all save if every person who programs
actually took the time to read a book on compilers?
Bob PendletonOn Wed, 2004-11-17 at 21:42, John Silicon wrote:
On Wednesday 17 November 2004 03:16 pm, Scott Harper wrote:
The only way I can think of to make this more efficient, is to change the
first and last glTexCoord2f calls that use only 0 or 1 into glTexCoord2s(),
but the speed difference there is negligible, unless you’re using this code
fairly often, or if you need the time to do alot of other things.float shownSize = 54f / 64f;
…
glBegin(GL_QUADS);
glTexCoord2f(0, 0); glVertex2i(x, y);
glTexCoord2f(shownSize, 0); glVertex2i(x+w, y);
glTexCoord2f(shownSize, 1); glVertex2i(x+w, y+h);
glTexCoord2f(0, 1); glVertex2i(x, y+h);
glEnd();Goes back to the old days of programming when answers to hard
mathematical computations were stored in lookup tables rather than
calculated on the fly. (Okay, not exactly the same thing.) It’s a
great tool to use! I mean, REALLY great!Lookup tables are used in cases where it will be more efficient (in preportion
to the loss in precision) to compute an integer offset, and load from that
offset, than to compute a precise result.–Scott
PS: In looking back, I realize that you didn’t mention having slowdowns
already… But still this technique can help make things easier to look
at and immediately understand what’s going on in the code.Also, why not make a texture struct (or object or something – I use
Java, so I’m not familiar with what’s best in C++) and inside you can
store the texture id, and the left, top, right, and bottom sides of your
texture in floats. This would help for a tile-based solution where you
load ONE texture which is broken into smaller parts.Anyway, my $.02.
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±-------------------------------------+
Bob Pendleton wrote:> On Wed, 2004-11-17 at 21:42, John Silicon wrote:
On Wednesday 17 November 2004 03:16 pm, Scott Harper wrote:
I wonder how much time we could all save if every person who programs
actually took the time to read a book on compilers?
Probably quite a lot - could you recommend any, while we’re completely
off topic? 
Regards,
\Mikkel Gjoel
Bob Pendleton wrote:
I wonder how much time we could all save if every person who programs
actually took the time to read a book on compilers?Probably quite a lot - could you recommend any, while we’re completely
off topic?
If you can find a copy get “An Introduction to Compiler Construction” by
William M. Waite and Lynn R. Carter. I learned from his earlier work and
papers. William Waite knows compilers. Sadly, the book seems to be out
of print.
The “standard” text is “Compilers, Principles, Techniques, and Tools”
(the dragon book) by Aho, Sethi, and Ullman which seems to still be in
print. It will probably give you a good idea of what compilers can do,
but I wouldn’t try to write a compiler based only on that book. They
have a very distinct Bell Labs bias. I.e, if it isn’t yacc and lex it
isn’t worth talking about. My personal opinion is that about 90% of what
is wrong with most modern compilers can be traced back to yacc and lex.
Bob Pendleton
I used to write compilers for a living.On Thu, 2004-11-18 at 19:17, Mikkel Gj?l wrote:
On Wed, 2004-11-17 at 21:42, John Silicon wrote:
On Wednesday 17 November 2004 03:16 pm, Scott Harper wrote:
Regards,
\Mikkel Gjoel
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±-------------------------------------+
I wonder how much time we could all save if every person who programs
actually took the time to read a book on compilers?Probably quite a lot - could you recommend any, while we’re completely
off topic?The “standard” text is “Compilers, Principles, Techniques, and Tools”
(the dragon book) by Aho, Sethi, and Ullman
Excellent book, but basically theory. One that does both theory and real
honest-to-goodness, hands-on, make-a-real-compiler is "Compiler Design in C"
by Allen Holub. Still in print AFAIK.
My personal opinion is that about 90% of what
is wrong with most modern compilers can be traced back to yacc and lex.
Take a look at “Compiler Construction–Principles and Practice” by Kenneth
Louden. Good newbie book. Covers both the yacc/lex method and the build your
own scanner/parser by hand method.
Also take a look at treecc, an aspect-oriented way of making compilers that
avoids the hassles of yacc & lex. It’s used in DotGnu’s pnet C# compiler.
Google for pnet and Southern Storm.
Bob PendletonI used to write compilers for a living.
Having done some toy compilers, I’m impressed by anyone who did it for a
living
JeffOn Thursday 18 November 2004 08:19 pm, Bob Pendleton wrote: