Custom Blend Mode
BlitzMax Forums/BlitzMax Programming/Custom Blend Mode
| ||
| Hi, I've been toying around with this new app for ages, and I need a blending mode for Max2D which is exactly the same as LIGHTBLEND except that I don't want it to max out at white (255,255,255). For example, say you were blending 2 colours... Color A (192,192,192) and Color B (128,128,128). Using LightBlend, it basically adds up the colours to a maximum of (255,255,255). However, I would like a blend mode that still adds them up, but doesn't max out at 0, instead counting past it. I.e. (67,67,67). Does anybody know of a way I can do this? Many thanks Seb |
| ||
| I know what you're after but don't know the answer. However, for DX, find a copy of MFCTEX or D3DMULTEX and for OGL find OGLMULTEX. These allow you to test the available blend modes. I could try if for you but, frankly, can't underatand the DX7 documentation on blend modes. Normally, I have to go by the result (which means a lot of trial and error) rather than the description. |
| ||
| I'm confused, are you saying you would want the blend to be lighter then light (255,255,255), or do you want it to wrap around back to black (0,0,0) and add up the leftover values from there? If so, you could just do an if statement and check if said add value is above 255, then use mod to see by how many times you should subtract 255 from the answer no? |
| ||
| I'm confused, are you saying you would want the blend to be lighter then light (255,255,255), or do you want it to wrap around back to black (0,0,0) and add up the leftover values from there? I think he means the latter, but if so, his maths is wrong. It would actually wrap to 65,65,65. Or maybe he means it starts counting backwards from 255,255,255 back to zero. I don't know of a blend mode that does either of those though. You could do what Genexi suggests, but that's gonna be slow doing pixel operations for blending. Could you possibly describe the visual effect you're trying to achieve? Perhaps there's another way or a similar but not quite identical blend mode. |
| ||
| Woops - LOL. I meant 65,65,65. Yeah I want to achieve the latter effect. Here's a simplified scenario of what I am doing... I've got 3 virtual torches that shine onto a spot onto the screen, partly overlapping eachother. The user can select which colour light each torch is producing (for example, Red, Green and Blue) and he can then see each colour on the screen and the resulting overlapping colours (which in the middle will obviously be white). Therefore the blend mode has to add up the colours exactly and present them on screen, which lightblend does well. *However*, this only works when I have Cls'd the background black, for obvious reasons. What I would like is to be able to get the same effect but have say a white background to start with. Using a white background with Lightblend, the colours don't change because they are already maxed out at (255,255,255). |
| ||
| There is an easier method to achieve what you are looking for. Search for Fredborgs light example basing on AccumBuffers. This should give you exactly such behavior without any problems. (beside needing a 9500 / GeForce 5 upward which shouldn't be a problem) |
| ||
| Nice example - but what actually is an AccumBuffer. I've Googled it and I can't find anywhere that actually describes what it is/what it does. |
| ||
| The correct name is Accumulation Buffer. It is a buffer, which (from what I understands) mainly accumulates the orgininal color with the buffers color, using a specific operations as specified in the operation. http://www.opengl.org/documentation/specs/version1.1/glspec1.1/node106.html |
| ||
| The thing you're trying to do reminds me of the old demo effect `shadebobs` whereby objects are basically `added` to the existing background and when the value gets to the maximum it wraps around at 0 again. That's basically because it was using unsigned bytes which overflow by themselves. In OpenGL at least, the values are clamped at white 255,255,255 because that is standard OpenGL behavior - there is no overflow, it is discarded. It takes values from the source pixel and adds them to values in the destination pixel and clamps it at 1.0, which is white in floating point. The remainer is lost and I don't think there's anything you can do about it. To implement any kind of overflow you have to basically have a subtract operation which is not present in standard GL but I think there is an extension that adds a subtract blend mode. I presume the accumulation buffer could be used whereby you accumulate the backbuffer as 1/2 value, then draw all the lights, then accumulate that, then do some kind of wrap thing. |
| ||
| Is there a multiply x2 blend in blitzmax? perhaps there should be. |
   |