i have a strange bug regarding glTexImage2D,
when i call it this way:

glTexImage2D( GL_TEXTURE_2D, 0, 4, sx, sy, 0, GL_RGBA, GL_UNSIGNED_BYTE, data );

it’s an access violation error. data is a pointer to an array of sxsy4 bytes.

on the call, data is 0x00190958. the call crashes on this instruction,

0x04F54FEB mov eax,dword ptr [esi]

as ESI=0x00191000. this is the thing i find strange.

the context of the call is a bit special too. i use win32. data was allocated with my own malloc. I compiled using /nodefaultlibs, which was made in order to save a few kilobytes on the executable size as i’m working on a project like this one:

i use a nVidia geForce3 ti 500 under winxp with detonator 29.42.

anyone could help?
thank you in advance,

Make sure your OpenGL context is initialized when you call glTexImage2D.

Also, I don’t what kind of allocation you do, but to be honest I wouldn’t allocate memory manually for the sake of stability. Anyway I agree it’s probably a necessity to save those kilobytes for a 64k demo.

If I were you I would use an assembler which will save even more bytes, but obviously is even more harder to develop with.


the rendering contexts are correctly initialized. i initialized a pbuffer and a main window rendering context. the main rendering context is active when initialisation is performed.

it’s true that using assembler would probably help saving even more space, but the amount of work to make with assembler is so huge that i’d probably never accomplish anything with it.

btw, i implemented the math routines and basic C functions in asm already (sin/cos/sqrt/tan/sinf/cosf/sqrtf/memcpy/memset/strlen/rand/srand…).


ok, what are your sx and sy values when it crashes ?

Im pretty sure that data isnt allocated as large as you think it is. You say it is, but lots of times I think something is working a certain way but it isnt. The fact that you say you are using your own version of malloc makes this 1000 times more suspicous. Perhaps a bug in your alloc routine is allocating a few bytes short?

Try using the standard malloc. If that works, you know where the problem is.

ok, the bug was exterminated

in fact, the funniest was that it had nothing to do (in appearance) with memory allocation or opengl. the crash came from the fact i used a return (*this); in my class operator implementation. the operators were used during the texture generation process just before sending the texture to the video board memory via glTexImage2D.

i wonder another thing. can i assume that the pointer to the pixel data won’t be used after the call to glTexImage2D by the opengl thread? (in order to free system memory just after uploading textures). currently it seems to work.

anyway, you’re right to be suspicisous about my memory allocation routines . Now the program still crashes in the end during a call to free() … but it’s another story.

thank you all for replying and helping me.

Once the texture is uploaded, you can safely delete your own copy.

Right. BUT you have to be ABSOLUTELY SURE that the texture is uploaded. That is, when you call glTexImage2D, you have no guarantee that the operation is executed and terminated at the end of the function. Performance may force some implementations to treat the pointer a few microseconds later (an eternity for todays processors). I wouldn’t free the pointer before calling glFlush or glFinish.

I dont think you are correct on that. I believe that after the function returns, the pointer is gauranteed to not be used again.

You’re probably right. In fact, I haven’t read anything that clearly explains that point in OpenGL specifications. And because it’s doubtful, I prefer calling glFlush or glFinish before deleting the image data. Since we’re not likely to call glTexImage2D every frame, then calling glFlush is not such a hard extra work.

Anyway if someone knows the exact answer I would surely appreciate it !

How much of a difference you see with your implementations in ASSembly?

i win up to 15 kilobytes on the final compressed EXE size. it’s huge for a program that must fit in 64kbytes.


Originally posted by nystep:
[b]i win up to 15 kilobytes on the final compressed EXE size. it’s huge for a program that must fit in 64kbytes.


Is there is good difference in performance?


The specification for glTex{Sub}Image2D() would be broken if what you said was true.

I am absolutely sure that it’s perfectly safe to call memset(data, 0, dataSize) right after the call to glTex{Sub}Image2D(). I am also absolutely sure that it’s perfectly safe to free() or delete[] the memory.

The driver will probably need to swizzle the data anyway, or copy it to AGP memory for fast upload, so I’d expect most implementations of glTex{Sub}Image2D() to be akin to memcpy(). If the driver wants to upload the data in-place, it can easily clone the virtual pages containing the texture data, and map them copy-on-write, which will make it more efficient if you don’t actually delete it, but still be correct if you delete it.

jwatte : I think you’re right. After all, if the pointer needed to be preserved in the client side, the function would have been something like glClientTexImage2D.
Thanks !

can you post your asm code for the math functions for us?