Processing textures in Blitz
Blitz3D Forums/Blitz3D Programming/Processing textures in Blitz
| ||
| IS there any way to process texture data in Blitz? Say I load in a bitmap with LoadTexture, can I go through each pixel and halve its value to decrease brightness? Is there a pointer system to the memory that I can fiddle about with? |
| ||
Sure.myTexture = LoadTexture("texfile.tga")
SetBuffer TextureBuffer(myTexture)Then just use readpixel, writepixel, text, lines, whatever you like. Two things though -- One, it's often more efficient to CopyRect the texture to an image, perform pixel level operations on that copied image and then re-copyrect the image back to the texture, as I've seen it perform a lot faster, and Two, if you insist on directly manipulating the texture in this way, load the texture via flag 256, forcing it to vram -- direct access will be faster this way. Do note, however, that flag 256 has the occasional compatibility problem. Copyrect does not. |
| ||
| Do note, however, that flag 256 has the occasional compatibility problem. Yep. For example, my old GF2 used to work considerably *slower* with flag 256 textures on certain driver versions. I don't think it happens in any recent drivers, but there's always a chance your users will be using out of date drivers and not want to update. |
| ||
| answer: Distribute the latest drivers with your program :P About the copyrect- im using it to stop from having to constantly redraw the map. At work, this is dead slow, where redrawing the map, for some, very very odd reason, is fast. Anyone know whats up with THAT? |
| ||
| im working on somthing like that, want to make an demo effect where the brightest places on a 3D object is boosted in whitness and some kind of flare/white alpha will be overlayed... looks kewl hehe.... take a look at this DLL image manipulation, it's nice, but i found it a "bit" slow thou... don't know why... http://www.blitzcoder.com/cgi-bin/showcase/showcase_showentry.pl?id=zjp05242004195911&comments=no |
| ||
| ahh forgot, would you be so kind to post an example on how to do the texture manipulation, just for newbies and others to learn from... i will too if i get that far.. :) |
| ||
| Brilliant. Thanks for that. I'm not looking to work on textures in real-time - rather process a texture on loading to create HDRI style specular highlights. A question on textures and VRAM though. Are textures not loaded to VRAM by default? I would have thought this the sensible place to put textures for speed reasons. If not, I take it large VRAM isn't needed for Blitz3D with lots of textures? At the mo' I'm a bit cautious how many textures I use as I'm aiming for very low-spec machines. Also I remeber reading a long time ago that video cards process 256x256 pixel textures the most efficiently. Are there any obvious disadvantages for larger or small textures? Cheers! |
| ||
| I would suggest loading them in as images, monkeying around with them then copyrect them onto textures if you're not dealing in real time, it'll be a lot more compatible and stable. |
| ||
| hmmm i just did some monkey stuff like SetBuffer ImageBuffer(scr_dumb) For x=1 To 800 For y= 1 To 600 GetColor(x,y) Tr = ColorRed() Tg = ColorGreen() Tb = ColorBlue() Color 0, Tg, Tb Plot x,y Next Next SetBuffer BackBuffer() on a 800*600 image.. and this is sooooo slow you won't belive it, have tried readpixel and writepixel but this ain't better in anyway..... even with an 100*100 square we have a extream reduce in speed.... for throuing it back on the entity i use copy rect, this works fine thou... but how do we manipulate in realtime images with high speed, i mean the only thing i did here was not to draw the red color.... and have even tried not doing enything than getColor.. and wow slow ass.... do we really have to compile some shit in ASM or C.. ???? anyone knows how to manipulate images grace and speed in blitz. ????... hmm :) |
| ||
| do we really have to compile some shit in ASM or C.. ???? No. The major speed bottleneck is the bandwidth between system memory and the video cards memory...even if you write the fastest routines possable it will be super slow. It doesn't matter what pixel drawing functions you use...writepixelfast, readpixelfast, poke, peek...you arn't maximizeing the from/to transfer abilities between video/system memory....its slow already, so doubleing, or even tripleing the amount of data transfered across makes it much, much slower. What you can do is to load the texture into an image stored on SYSTEM memory (yes system, NOT video)...do what you want to it from there and transfer it to the video memory stored texture useing the drawimage function... Put it this way...when you writepixelfast, poke, etc...you are sending not just the pixel color value across to the video card, but also a video memory address to place the pixel...as well as a byte count, telling the card how many bytes to place there. Now lets say you have a 128 by 128 32-bit color texture that you want to mess around with...you do this one pixel at a time (writepixelfast, poke, assembler, it doesn't matter as you end up doing the same thing) in this manner you will be sending a 32-bit memory adress, a 32-bit byte count, and a 32-bit color value across for EACH pixel (a 128 by 128 32-bit color texture is 64k...but doing it one pixel at a time you end up sending 192k across the system/video pipeway)...but by useing the drawimage function you only need to send the address and byte count once...8-bytes + 64k worth of pixel colors...a third as much data across, makeing it faster as you are maximizeing the system/video transfer bottleneck...which is why simply loading textures is so much faster then individualy coloring them with writepixelfast and poke routines |
   |