haxepunk / post-process

[Deprecated] Post processing using GLSL in HaxePunk

HaxePunk is a powerful cross-platform 2D game engine, based on the FlashPunk AS3 library.

• Builds for HTML5 (WebGL), Windows, Mac, Linux, iOS, and Android
• Hardware acceleration and texture atlas support
• Gamepad and multi-touch input

Release build

First, make sure you have Haxe 3.0 or higher, we recommend you to update to Haxe 3.2 if you haven't already. Then execute the following commands below to get started with your first HaxePunk project. If you are using Haxe 2 the last version supporting it was v2.3.0 haxelib install HaxePunk 2.3.0.

haxelib install HaxePunk
haxelib run HaxePunk setup
haxelib run HaxePunk new MyProject # creates a new project

Development build

You will need a C++ compiler for native builds (Xcode, Visual Studio, g++).

git clone https://github.com/HaxePunk/HaxePunk.git
make

This will build documentation, run unit tests, and run the example project. If you fix an issue, feel free to create a pull request.

If you've cloned locally, you can set your local repo as a development directory accessible through Haxelib:

git clone https://github.com/HaxePunk/HaxePunk.git
haxelib dev HaxePunk HaxePunk/

To disable the dev directory for HaxePunk simply run the command haxelib dev HaxePunk. Notice there is no third argument passed.

If you just want to install the latest dev version from Git, you can also do this with haxelib:

haxelib git HaxePunk https://github.com/HaxePunk/HaxePunk.git dev

Have questions or looking to get involved?

There are a few ways you can get involved with HaxePunk.

• The development roadmap is available on Trello.
• Come chat with us on Discord or Gitter.
• Drop by the HaxePunk forum to ask a question or show off what you've created.
• Create an issue or pull request or take part in the discussion.
• Follow us on Twitter: @HaxePunk

Credits

• Chevy Ray Johnston for creating the original FlashPunk.
• OpenFL makes native targets possible and simplifies asset management. Thanks guys!
• All the awesome people who have contributed to HaxePunk and joined in the discussions on the forum.

MIT License

Copyright (C) 2012-2017 HaxePunk contributors

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

post-process's Issues

Can't get it to work on windows 7

I cannot get it to work on Windows (neko || cpp). It opens a blank window and then crashes.

I've tested the example project with current dev versions of HaxePunk and OpenFL, and 2.5.2 and 1.2.3 respectively. Still no luck!

Any ideas?

Magenta screen on mobile

I've been playing around with this. It works great on the standalone target, but on mobile (iOS Simulator to be exact - didn't try devices), the entire screen gets painted in magenta, no matter what shader is used - is that expected?

Game gets squished in full screen when aspect ratios don't match.

Suppose that I'm building a standalone desktop game that runs in full screen. The game is built at a specific resolution and is scaled up to fit the screen as best as it can without altering the game's aspect ratio. When I apply a shader and the aspect ratio of the game vs. the screen don't match, the game mysteriously gets squished, so it's horizontally narrower than it ought to be.

For example, if I have a 2560 x 1600 screen and my game was built at 320 x 320 (for discussion's sake), the aspect ratios don't match, so the game ends up getting squished. If I set the game's native resolution to 512 x 320, no squishing happens because the aspect ratios match up perfectly.

To be clearer about my own situation, I'm not using HaxePunk but am still using this with OpenFL. Display Tree-wise, the setup goes like this:

root

• Sprite
• Sprite
• [...]
• PostProcess

root itself is added to the OpenFL stage, has higher-than-1 values for scaleX/scaleY and has an x/y position that's non-zero, so it's centered on the screen. For the 2560 x 1600, 320 x 320 example, scaleX/Y are 5.

I've tried fiddling around with the width/height values inside PostProcess.rebuild(), PostProcess.render() and PostProcess.capture() but haven't had much luck. For example, If I try to drop the width to 1600 (320 x 5), the squishing stops, but part of the game gets chopped off.

Shaders on drawTiles (or individual DisplayObjects)

In a rough sense, what would be involved in supporting shaders on drawTiles()?

Would it require a totally different approach (modifying OpenFL/Lime) or could it somehow be worked into this hands-off approach?

Draw functions are being rendered after shaders

While entities and such are correctly rendered and affected by shaders, the latter will have no effect whatsoever on graphics produced by calling functions from the Draw class. It looks as if the shaders were rendered before the Draw buffer, although tracing shows that it's not (at least if I understood correctly).

Question - Drawing stuff after shaders are applied?

Is there a way to "draw" stuff after the post-processing phase is over?

For example, if my game has an HUD layer (for a health bar, score, etc.), I'd like the shaders to do their work but not apply to those elements.

From what I understand, it's not as simple as adding something to the display tree after the PostProcess view - that would pick up what's drawn in the next frame, I imagine.