At 17:31 26.03.2002 -0500, you wrote:
Demos aren’t where you are going to find the money. 
But programming
for companies is a great way to make money. Even game programming, even
though you tend to make less doing that.
Well, as I said, it’s not the money that makes me code …
Sounds pretty complex. I don’t really like math and physics enough to get
into all that really. I remember learning some of that, though. And ya,
intregrals, integration, etc. That’s the right word for it.
Once I had the Idea (I really like good racing-games like ColinMcRae
Rally2.0) to code a driving-simulation, but I put this idea into a corner
in my head … it’s just too much physics to think about, I might do that
for my diploma, though…
C gets you close enough I think. You can optimize a lot in C, since a lot
of it’s operators translate directly to opcodes really, like shifts,
bitwise operators, etc.
Hmm, except if you do floating-point-stuff … It just doesn’t seem
neccessary any more to use fixed-point-math…
Heh, well, I’m doing a lot better now. Working on an SDL_Surface to
texture conversion class right now, so I can try and texture map something.
Why bother, I thought this glSDL-guy already did this?
Yes, that’s become pretty clear lately.
Well, I don’t put sheets over my mouth …
SDL_surface *my_texture; // there you have an image which
shall be uploaded
// MAKE SURE, the size of this texture is a power of two (ogl needs that,
it just is this way!)
// f.e. width = 128, height = 64; Surface is 24bit (8red,8green,8blue)
GLuint texindex; // it’s what the name says …
glGenTextures(1, &texindex); //
Generate OpenGL texture IDs
glBindTexture(GL_TEXTURE_2D, texindex); // Bind Our Texture
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR); //
Linear Filtered
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR); //
Linear Filtered
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP); // texture
won’t be repeated in x-dir
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP); // texture
won’t be repeated in y-dir
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, my_texture->width, my_texture->height,
0, GL_RGB, GL_UNSIGNED_BYTE, my_texture->pixels);
// now you can delete my_texture, because the data is inside the gcard-memory
// also a good thing to do:
if(glGetError()!=GL_NO_ERROR) … // texture incorrectly
transmitted
Thanks, useful to get another perspective on things at the very
least. Didn’t even know about the glGetError() yet, though. It’s
probably not wise to assume the next row of pixels in the surface are
going to start immediately after the previous row. I guess it’s working
for you fine, but if ported or something it might not work right. This
certainly makes for a simpler example, though. My version so far is
already more complex than this is. I’m trying to support all 4 byte
depths though.
This code will always be pretty much the same. It will happen, that the
TexParameters change, though.
One very important thing: the TP’s are bound to the texture (you might
wanna have different textures filtered differently - makes sense, huh?)
Well, I don’t understand what all the filtering modes do yet. I don’t
even know what kinds there are besides linear and nearest. I’ll have to
look that up soon.
AFAIK there are just those two for single textures … when you use
mipmapping these parameters will extend … linear means if your far away
from the texture, it is smoothly interpolated and looks pretty washed out,
nearest is faster, 'cause ogl just calculates which point in the texture is
"nearest" to the point to be displayed and then uses this texture-point’s
color.
I guess there’s no way to tell OpenGL that you are finished defining the
texture, kind of like the glEnd()? I guess it implicitly ends when it
sees a new glBindTexture() or something.
It somewhat like an asyncronous job (the glTexImage), so the glGetError
should wait until it’s finished. And with finishing it there’s nothing
more to do about initializing this texture. You may then proceed drawing
… not to forget the glEnable(GL_TEXTURE_2D) …
Bis bald (just to have some variation in here …),
St0fF.
