making AGS render 255 rather than 0 into alpha component of a pixel in 32bit

[Nickenstien]

Hi 

Does anybody know if there is a way to tell AGS to to set the alpha bit in a pixel to 255 when that pixel was rendered, rather than leaving the alpha byte empty when in 32bit colour mode ?

I am attempting to copy each layer of the AGS display out onto separate textures so that I can do post-render effects on each of the layers individualy.

So, for instance I let AGS render the background, I then memcpy the scanlines from AGS frame buffer into my textures, and then memset the whole AGS framebuffer area to 0's. This is to make AGS then render the Sprites onto a clean surface. I can then repeat this procedure once the sprites are rendered, then the GUI and finaly the mouse cursor, leaving me with a seperate texture for each layer, that I can do my effects with and finaly render them myself.

However, when AGS goes on to render the sprites, it will write the RGB values into its frame-buffer, but it will leave the 4th byte of every pixel as 0 (the alpha value). This means when I memcpy the scanlines for the sprites they have 0 alpha. I need my spritelayer to have alpha of 0 where nothing was drawn (the memset after the background does this), however I also need the pixels that were drawn by the sprites to have an alpha value of 255.

I can check myself if RGB exist and then set the alpha-byte myselfe, otherwise leave it as 0, however doing this means i have to check for RGB in every pixel and copy it accordingly, meaning that I cant memcopy entire scanlines which makes the whole thing too slow to be of any use.

But if the Alpha bit was filled by AGS, then I could memcpy every scanline in an acceptable time.

Any ideas would be greatly appreciated.

Cheers,
             Nick.

[Pumaman]

I presume you're talking from the context of a plugin?

I can check myself if RGB exist and then set the alpha-byte myselfe, otherwise leave it as 0, however doing this means i have to check for RGB in every pixel and copy it accordingly, meaning that I cant memcopy entire scanlines which makes the whole thing too slow to be of any use.

The same thing would probably apply if AGS did this itself, though.

AGS just ignores the alpha byte, except when it is explicitly rendering an image imported "with alpha channel". To be honest it's a bit of a specialized change to make to the engine, I'm not sure what benefit it would give you?

If sprites had an A of 255 for transparent pixels, you'd still get a rectangle of alpha pixels around the edge of the sprite; and this technique won't work at all in any other colour depth, since there is no alpha byte.

Are you sure there's no other way to do what you're trying to accomplish?

[Nickenstien]

Thanks for your time Pumaman

I presume you're talking from the context of a plugin?

Oops sorry i forgot to mention that part.

The same thing would probably apply if AGS did this itself, though.

Depending on how AGS actually renders its Sprites/GUI & mouse-cursor pixels. If AGS is using some form of memcpy/blit to apply entire portions of the pixels then my suggestion would slow this down.
However, if AGS is already using a pixel-by-pixel method then the 'unsigned long' representing RGBA of each pixel (in 32bit colour mode) could be OR'ed with 0xff000000 as it is written to the frame buffer and only having a miniscule impact on AGS' render time. Of course this is pure speculation as I don't know how AGS works 'under-the-hood'. However I would have to assume that AGS does do it
pixel-by-pixel in order for it to mask sprites against the WALK_BEHIND pixel masks.

If sprites had an A of 255 for transparent pixels, you'd still get a rectangle of alpha pixels around
the edge of the sprite

It is only the non-transparent pixels that require the alpha to be masked in. Of the sprites source rectangle, any pixels which are not to be rendered would leave the Alpha-byte set to 0. And only pixels from the sprites rectangle that actually get rendered to the frame-buffer would have the Alpha set to 255.

I have this working fabulously using the per-pixel implementation that I outlined in my initial query . My concern is that the performance _may_ be unacceptable on lower spec pc's. Additionally after our game is done, we intend to release the plug-ins and users of them will want to use it at higher resolutions than I currently am (meaning much more pixels to manipulate one by one).

Pumaman, if you are interested I can send you my plug-in test-app with hardware eccelarated effects being displayed in between my extrated layers so that you can see where I am going with this.

Cheers,
       Nick.

Edit by strazer: Fixed quotes. Please use the [ quote ] tag next time.

Edit 2: Do not double-post, please. Use the "Modifiy" button to edit your previous post.

Additionaly: I should mention that my initial query was to find out if there was some existing facility to enable the setting of the alpha component. I understand that modifying the AGS rendering system isn't something to be done flippantly on the basis of my request   

I will attemp to profile my system on some lower-spec pc's to determine if a pixel-per-pixel system is usable for my purposes.

Keep up the good work chaps 

[Pumaman]

Perhaps the solution would be to add some sort of plugin event hook AGSE_ONSPRITELOAD which would be called whenever a sprite was loaded into the sprite cache, and therefore you could jibble it there and then and make your changes to the sprite at that point?

Edit by strazer:

AGS v2.72 Beta 7:
* Added plugin API AGSE_SPRITELOAD function to allow plugins to modify sprites as they are loaded into memory.

[Nickenstien]

hmm not realy.

As my plug-in would still need to do per-pixel operations on the entire sprite rectangle to determine which sprite-pixels required the alpha to be set. This would be a bit faster as I would only be concerned with querying the pixels within the sprite rectangles as opposed to the entire frame buffer. However it wouldnt help with the GUI layer or the mouse-cursor layer.

So I shall just stick with the method I have in place now. Possibly I can find a way to make Direct3D ignore pixels with no RGB in them and render the pixels that contain some RGB value regardless of what the pixels/texels alpha value is. If I can get that to happen I can remove all per-pixel operations from my plug-in code and have fast blits instead.

Thankyou for your time and thoughts, its much appreciated   

[Pumaman]

Surely Direct3D supports Color Keys, it doesn't force you to use alpha transparency?