2D Filters in Blitz3D
Blitz3D Forums/Blitz3D Programming/2D Filters in Blitz3D
| ||
| Is there some way of achieving 2D filters like tonemapping, autolevels or greyscale in B3D? |
| ||
| Depends on how fast you want them to occur? Realtime - not really. Post processing an image file non real time - definitely. I think in the code archives a user by the name of 'PJ' (his nickname has changed a few times) has posted a huge range of filters. code archives: Link |
| ||
| thanks Matty. I was just wondering how Fastlib and Ashadow works and it seems like a mystery to create postfx to this day. I don't see any DX7 documentation extending this feature or making it possible. All I know that it is a fixed function pipeline but the opengl counterpart (1 ~ 2) is possible and has lots of documentation. |
| ||
| The problem with trying to understand DirectX 7 is that in the era when it was relevant, most of the advanced features didn't actually work, because graphics cards were rubbish and didn't really conform to specifications properly (now at least they pretend to, and the specs themselves are much better). Ironically it's only since the fixed function hardware was eliminated that these features work reliably because they can be implemented entirely in "software". I'd be genuinely surprised if even FastLibs - which is otherwise very solid, the practical answer to the question is "use that" - actually functioned as-intended on any machine that had a fixed-function pipeline. So my gut says that much of DX7's theoretical capability wasn't fully documented because "why bother, it'll never work properly anyway". One alternative idea (always meant to look into, never got around to it) might be to write "pseudo-shaders" that compile to e.g. AVX instructions working on a graphics buffer. This would be dramatically slower than using the GPU but probably still just about good enough for realtime. This would be completely API-independent. |
| ||
| write "pseudo-shaders" that compile to e.g. AVX instructions Admittedly not Blitz3D related but if you're going to mention AVX then you're already outside of the scope of the current Blitz3D capabilities... compute shaders would then be the thing to can come in to steal the show away from the cpu again. With a compute shader you have the mercy of potentially several thousand processing threads at your fingertips. You can create a gpu side buffer ( more technically - a texture ) load it with image data and run a compute shader over it to do whatever effects to want, then pass the data back into the gpu pipeline to do what ever you want with it. Of course you need access to the later apis to even entertain compute shaders which is, again, outside of current Blitz3D capabilities. |
| ||
| graphics cards were rubbish GPUs were not. Especially  |
| ||
| Thanks for the input guys. I was wondering if given the possibility, would it be faster to do the writepixelfast and buffer routines directly to c++, I mean as a function inside b3d runtime code alongside the api functions and not as interpreted code, if I'm not mistaken. Maybe this is how those extensions and shadows work? I don't know much about AVX and can't find anything related to it on the web, even old directx 7 sites. |
| ||
| This guy somehow managed to make something happen from DX6 to DX9 "I am writing windows32 hooks around DirectX 6.1 library to DirectX 9.0c; Idea is to replace all calls to DX 6.1 3D device with calls to Direct 9.0c and inject some custom code, so old game which I am patching (99' year) will be able to use shaders, post-effects, etc." http://stackoverflow.com/a/4963103/4397269 http://stackoverflow.com/questions/1961386/getting-programmicaly-device-caps-for-directx-6-1-ddraw4 |
| ||
| I don't know much about AVX and can't find anything related to it on the web, even old directx 7 sites. Just to eliminate confusion - 1) don't take this suggestion seriously. I'm having a fun weekend trying to work out how my suggestion could be implemented, but it's not a sensible idea for someone who just wants to use filters, because the solution doesn't exist yet. 2) you won't learn about it on anything to do with DX7 because AVX is a much newer technology that didn't ship until 2011, and it's 100% CPU-side - nothing to do with graphics (let alone any specific version of DirectX or OpenGL), except that a graphics buffer can be treated as just another block of memory to process. That said - I was wondering if given the possibility, would it be faster to do the writepixelfast and buffer routines directly to c++ If you wrote the filters in the right way, translating to AVX/SSE is exactly what the C++ compiler would do. Look up "vector intrinsics" for more. |
| ||
| Ok thanks for clearing that up Yasha. |
| ||
| Here is an approach, however the speed is terrible. A better way to overcome the speed problem is to render to a texture and use ReadPixelFast, WritePixelFast instead. |
| ||
| Thanks const. I also found this in the code archives, which is more like how OpenB3D handles Post Effect shaders, ie camera textures. http://www.blitzbasic.com/codearcs/codearcs.php?code=1351 It provides bloom effect and as a material! :-) Now how do I create my own effects like greyscale etc? |
| ||
| To do a greyscale or black-and-white filter you would need to sample a pixel and output a grey pixel for it (like with the CIE luminance formula, one of a few different ways to measure the brightness of a colour). This is more complex than the additive blending of that glow effect, and you would need to write custom code for how the pixels should be output to the screen. There is no way to do this with Blitz3D since it uses a fixed-fuction renderer. You would need to use an engine with a programmable renderer, like OpenB3D or others. I think these type of effects are called 'fullscreen post-processing shaders'. |
| ||
| Thanks for the info. Yes, already know that in fact I already created some simple fullscreen postfx effects on OpenB3D. There's still this itch than both 3D mods for BMX still can't quite catch on with B3D in terms of compatibility and performance so I am playing around some stuff just to test things out. |
| ||
| I think in the code archives a user by the name of 'PJ' (his nickname has changed a few times) has posted a huge range of filters. Name changed once in 15 years and that change was at least years ago. ________________ I would suggest, if intending to wrap a c++ function (i..e call a library) to perform the shadiong, you may as well be better off implementing the oGL or DX shader through the same method. ---------------- The filters referenced in code archives and possibly the worklog are a little outdated now. They need to be optimised more (for example, distinguishing hue or luminance levels is better down through using Hue, Saturation & Luminance values rather than processing R,G & B components - I fully intend to complete the work, but unfortunately time is never so accomodating. |
| ||
| Thanks PJ. |
   |