Create OpenGL Texture from TBitmap

[User137]

But still, the texture is not being displayed in the screen.

You didn't say that in first post I assumed it is working code just in need of optimizations.

self.FTexture:=CreateTexture(width,height,@canvas.pixels);

You won't be able to do that. Pixels is a property with GetPixel(X, Y: Integer): TColor function internally. But you are able to read the pixels without converting to TLazIntFImage. You can also send the TBitmap as parameter, and then read from its canvas pixels[] or colors[] property.
(Canvas.Colors[] is record structure divided in R,G,B, but works for freepascal only)

[deathshadow]

You won't be able to do that. Pixels is a property with GetPixel(X, Y: Integer): TColor function internally. But you are able to read the pixels without converting to TLazIntFImage. You can also send the TBitmap as parameter, and then read from its canvas pixels[] or colors[] property.
(Canvas.Colors[] is record structure divided in R,G,B, but works for freepascal only)

Is that a recent change or something? I thought that was the pointer to the buffer just like scanlines[0] would be...

Or did they go the retard route and stop providing you an actual pointer to the pixel buffer?

I stopped using delphi because of idiocy like that and went to FPC. Several times I've ended up screaming at the display "lands sake just let me access the data I just loaded!" -- SDL_image or using your own loader has far, far less headaches.

Actually, I use a bit harsher language than that. If you have to make a second copy of it using some idiotic array like scanlines or via pixel[x,y], then IMHO tBitmap is useless bull... that ends up being THREE copies just to load one image into openGL; if that's not idiotic nonsensical BS, I don't know what is.

would scanline[0] then work? Or do they not even guarantee that scanlines are contiguous in memory?

If I was forced to use code like that because tBitmap won't even provide a proper pointer to the buffer the bitmap is stored in, I'd say {expletive omitted} that {even nastier expletive omitted}, kick tBitmap to the curb, forget that resources BS, and just make my own loader... because if that's how it works, it's not worth even TRYING to use.

But then I've never liked resource files to begin with. Royal PITA... and if I was writing for OpenGL, Delphi would be pretty far down my list of choices -- but that's probably because FPC+SDL+OPENGL is so bloody brilliant from a functionality and ease of use standpoint.

[deathshadow]

That new code looks much, much more promising, though it's not really all that versatile in terms of BMP formats... gimme a bit to play with that. I'll compare it to my PHP code for loading BMP files (which shockingly PHP/gd has no support for -- WBMP != BMP).


I suspect the unsized palette array is the contributing factor to it's failure... though using all the stock data types could also be it since there's no guarantee they match the physical header info across compilation targets.

Have you tried outputting the values from the header read to make sure it actually is getting valid header data from reading 'self'? I didn't think a handle to tBitmap would be file readable?

If you put it in an external file, does it work? If you can load it from an external file, then the problem lies with how you're trying to use a resource and/or tBitmap. Start going through and eliminating possible causes.