Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom FlxCamera effects #552

Closed
skrivener opened this issue Jul 30, 2013 · 1 comment
Closed

Custom FlxCamera effects #552

skrivener opened this issue Jul 30, 2013 · 1 comment

Comments

@skrivener
Copy link

What I'm envisioning is a new first step in FlxCamera.drawFX() that will check to see if one or more custom effects have been defined and if so then process those onto the buffer before moving on to the fade, shake, etc. What motivates this for me is that I envision this as the most efficient place to process lighting, which has been a huge part of game design for me since playing Thief: The Dark Project a loooong time ago. Someone mentioned a desire for shader support in OpenFL on the HaxeFlixel forums, and a closed issue in this repo mentioned it too, and I'm sure that's the optimal way to handle lighting support due to GPU use, but would it not be possible to handle it in this way for the time being since shader support does not seem imminent?

For example, say I generate a shadowmap (BitmapData or Array or whatever is the least overhead) with values indicative of how dark I want each pixel to be, and I set the effect function to be "multiply" or define the processing in some way, then before processing the other effects it will run a multiply of some alpha of black based on the shadowmap for each pixel. Ideally I would then be able to run another effect pass with a lightmap to do something like a screen or bloom effect, or combine both into a single lightmap (say with values from -255=>255 with 0 being no change) and run against that. I suppose to take it further it would be awesome to specify colored lighting values, so maybe ARGB could use A for shadow and RGB would be used for lighting exposure/overexposure. Effects like transparency/translucency would be handled in the generation of the *maps, so wouldn't require flixel code.

So the actual concrete implementation I'm not so sure on. I'm thinking we don't want to have to override FlxCamera if possible, since it's hooked into FlxG so much (which personally I'm starting to use more and more) I'm not sure if that might create issues, so my initial thoughts of a stub function in FlxCamera probably doesn't make sense. Perhaps we could pass FlxCamera a string that could be reflected to run a static inline function defined elsewhere?

Or am I overthinking this, and should just think about integrating a lighting effect into the drawFX() repertoire, which is what I really care about? If I continue to have a slow work week I'll probably put some time into hacking drawFX() to add something like this directly and see how it affects performance. Any suggestions on the fastest way to store per-pixel data for processing onto the buffer? A more generalized approach would be more flexible, but perhaps have performance issues, and is probably beyond my expertise atm. Or (even better) does something like this already exist in HaxeFlixel, and I just haven't stumbled on it?

Edit:
I then noticed this open issue ( #440 ) ran the demo, and poked around the net a little more (eg. http://www.youtube.com/watch?v=fsbECSpwtig ) and wondering if shaders are the way to go after all. Also https://github.com/ncannasse/hxsl and http://ncannasse.fr/blog/getting_rid_of_flash .

@Gama11
Copy link
Member

Gama11 commented Jun 20, 2015

Post-process shaders are supported now (though not per-camera).

@Gama11 Gama11 closed this as completed Jun 20, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants