DrawImage blending function.

[Calin Leafshade]

Since some work has recently been done on the blending functions for GUIs can this blending function also be put into DrawImage? DrawImage currently doesnt allow one to blend two alpha channels together which is a bit of a pain.

[Calin Leafshade]

Also, it would be awesome if scripts were given direct access to the bmp surface.

We already have GetPixel but it only gives 16bit values and doesnt allow access to the alpha channel.
If this were done then we could write our own blending mode. Sure they wouldnt be very fast but it probably wouldnt matter in most games.

[Ryan Timothy B]

Another related request (has something to do with the drawing process of AGS): having access to the dynamicsprite before it adds the GUIs and Cursor to screen. It would be hugely useful for many effects and such.

Edit: Like: DynamicSprite.CreateFromScreenShot
But instead CreateFromInitialScreenShot or underlying screen, or screen background, or whatever anyone can think of that sounds more fitting.

[Calin Leafshade]

That's quite problematic in a hardware accelerated environment because the bitmap will already be in video memory by that time and getting it back into system ram requires a buffer flush which is very expensive.

Not to mention the fact that scripts have already finished running by the time drawing starts.

It would be perfectly possible in Direct Draw mode though but that should probably be deprecated soon.

[Crimson Wizard]

Edit: Like: DynamicSprite.CreateFromScreenShot
But instead CreateFromInitialScreenShot or underlying screen, or screen background, or whatever anyone can think of that sounds more fitting.

What about CreateFromScreenLayer(eLayerRoom + eLayerObjects + ...).

@Calin, that would be theoretically possible by redrawing same sprites (room, characters etc) over created dynamic sprite.

[Ryan Timothy B]

I know AGS sandwiches everything together layer by layer, I just meant having it store the dynamicsprite before it sandwiches the GUI and cursor to it - of course it would mean you're always storing a x by x sized screenshot (or just an option in the settings menu when you want to use this function - otherwise it gives you a warning upon compile or run-time, whatever is easier).

[Calin Leafshade]

I don't see how this is possible.

You'd need to render the scene twice, once in hardware and once in software in order to keep the texture in system ram.
But if you do this then hardware accelerated features like bilinear filtering become impossible unless you do those in software too which would be *very* slow as high resolutions.

The only way you could do it is to flush and reverse the bus to get the texture back into system ram but that takes literally half a second to do.

[Crimson Wizard]

Okay, let's try different approach: why would you need such a "screenshot"? Maybe there is other way to accomplish what you have in mind.

[Ryan Timothy B]

Currently I don't actually have any use for this function. In the past there have been several instances where one would need such a function. Take for instance, Steve's underwater module. Having the rippling effect of everything that is drawn to the screen. Then there's tons of modules that Monkey wrote that "fake" this requested function by drawing everything to the screen layer by layer sorting through by drawing order (where the caveat to his method was the obvious walkbehind issue).

Anyway, I just assumed it was something terribly easy to accomplish since AGS is already doing this - if not, then don't worry about it.

Of course, with this function, you would always be one frame behind the current frame.