WritePixelFast,LockBuffer,SetBuffer for BlitzMax?
BlitzMax Forums/BlitzMax Programming/WritePixelFast,LockBuffer,SetBuffer for BlitzMax?
| ||
I found some blitzplus snippets that I need to convert to max. Apparently it looks like I do have to replace these important functionalities to get it to work. Appreciate any samples or old archives that I might have missed out. LockBuffer BackBuffer() SetBuffer() ImageBuffer() WritePixelFast() Some old topics http://www.blitzmax.com/Community/posts.php?topic=53056 If it's not possible without any helpers or extended modules, how can this be replaced? Thanks. |
| ||
The technic of manipulating images has changed on BlitzMax. Instead of "deforming" the adress of the screen towards an images, you have to paint directly on the screen, then grab this content into an image. Additional there is an "editable image format": TPixmap The corresponding commands are used in this example: This code adds a black line to an grabbed image Graphics 600,400 SetClsColor 255,255,255 Cls SetColor 255,0,0 DrawRect 100,100,150,80 Global Screenshot:TImage=CreateImage(150,80) GrabImage ScreenShot, 100,100 Global Editable:TPixmap= LockImage(ScreenShot) For Local i%=0 To 149 WritePixel Editable,i, 40, $FF000000 Next UnlockImage Screenshot DrawImage ScreenShot,100,200 Repeat Flip 1 Until KeyHit(KEY_ESCAPE) |
| ||
Thanks MidiMaster I'm trying to fill-in the exact commands in B3D or BPlus. Do you think it will work? Something like: Function UnlockBuffer(buffer:TImage) UnlockImage buffer EndFunction I would like to complete those so I can try the full conversion from BP/BB code |
| ||
Hiya, the nitty gritty of images... Each TImage ( and each frame of an image ) has a TPixmap associated with it. The TPixmap is a cpu side array of the pixel data. You can manipulate the underlying TPixmap pixel data as you see fit from your own code. When you draw the image for the first time the underlying pixmap is 'uploaded' to the gpu as a texture thats rendered to a quad. Any further draws of that exact same image then re-use the texture without uploading. Altering the TPixmap then requires the data to be uploaded again, which involves creating a new texture on the gpu. Grabbing an image 'capture' of the backbuffer is the worst thing you can do as far as efficiency of the cpu and gpu pipelines are concerned, although things have got slightly better with more modern gpu apis. The problem comes with gpus being a kind of one way street for information. It's very fast in getting data from the cpu and working on the data with its own circuitry but very slow when it comes to sending data back to the cpu ( Again modern apis do have provisions for this but Max2D doesn't use them ). To grab the backbuffer the way Max2D does it requires that the gpu to complete all gpu commands in the driver and gpu command buffers up to the point that you want to grab it. Because the gpu is more than likely working on more than one command set at a time ( possibly more than one frame too ) then the driver waits until all commands are complete which then leaves empty driver buffers ( this is effectively a 'flush' ). Next time you render anything at all it takes time to fill those buffers ( possibly more than 1 frame ) and hence you introduce a stall. Its not the best way to handle things but that's the way Max2D does it :p ps UnlockImage does absolutely nothing at all. ( brl.mod/max2d.mod/max2d.bmx ) |
| ||
Great treatment from col of a subject that has puzzled me extensively. Seems to me that if you need this to be fast and use it a lot you should roll your own gfx routines to do at least part of your rendering in software. This will probably leave such things as blend modes unavailable unless you want to write that is software too but you can't have everything. It would be much slower but there is nothing slower than doing a nontrivial grabimage every frame. |
| ||
Yes, I'm getting it now. obviously modern api approaches solves this problem. It's not the same on all setup. Thanks Dave. |