[FEATURE REQUEST] Blur option for Walkable Areas (Like Scale)

[Rik_Vargard]

Hey, just thinking for me here:

It would be nice to have a blur effect as option for the walkable areas.
Just like the Scaling effect.
The smaller/further away you are, the more blurred the charater is.
I think it would create some great visuals, like a basic FOV for cameras.

Cheers! 

[Crimson Wizard]

Before assigning any effect to a walkable area, we'd need to define the effect itself.
(And then it also has to be manually assignable too.)

So what is this "blur" effect exactly, can you describe it logically?

[Rik_Vargard]

The blur effect could be connected to the walkable area's MIN and MAX scales.
And then, the smaller the player is on screen, the blurrier he becomes.
Could also be turned on or off in each room.

The end result would be something like this : https://www.mediafire.com/file/l2k2omls6cibedh/BlurEffect.mp4/file

[Crimson Wizard]

First of all, this effect has to be defined as a program (shader, or bitmap distortion code), that has a distortion algorithm and input parameter(s).

Then, there should be a way to apply this effect to a character or object directly, without walkable area.
Since this is a new visual effect, first we apply it to the character, then someone will request this be available in other objects. So ideally it should be available everywhere (characters, room objects, overlays, maybe even guis). *

Then we may consider applying this to walkable areas.


* - The engine has a long time problem of not having a base class for "drawable object". It would be nice to have one implemented first, so that we could move these graphical effect properties there, and have them present only once, instead of copying to each type.


Besides other things, there's a problem of multiplying properties in Character type. Right now there are properties that tell:
* if character has explicit scaling applied
* if character has explicit tint applied
* if character has explicit light level applied
* should character be affected by region tint
* should character be affected by region light

If we add another visual effect, do we also need equivalent properties? In the long run this may overload this class with properties for each requested effect. Perhaps existing property design should be reviewed and simplified somehow first.

[eri0o]

About base class, other approach is to put all of these properties in an object like DrawableProperties or something else - coming up with a good name in this approach is hard - and then deprecate the options and instead use this common object to hold it along.

[Rik_Vargard]

And just like that I'm kicked far above my understanding/experience. 

Just the fact that you guys can see how it maybe could be done and what it would take is beyond my ... *pffft*

What I do understand is that it would take a lot of time and work.
This is not more a "request" than a "suggestion" and I guess there are more important matters for AGS.

But! ( ) if one day this "Field Of View" idea becomes a thing, imagine how AGS could go visually "Next gen"... ? 

Cheers! 

[Crimson Wizard]

In the end, my opinion on this is that the "Blur" is a way too uncommon effect to have a built-in property on Walkable Area.

IMO it should be implemented as a custom shader, which has a "distance" parameter, set from relative character position on a walkable area.

So:
1. Implement custom shader support.
2. Find a way to pass relative position from walkable area to custom shader as parameter.

[eri0o]

I guess one day we will move to SDL3, it has SDL_gpu, which is really new (so probably lots of bugs) but it works with their satellite project SDL_shadercross, which is also very new (probably even more bugs!). The advantage here is that would make one shader language that can then transpile at runtime to other shader languages that then can be compiled by whatever is the graphics driver in use.

The big problem of adding shaders in the engine afaict is that each graphics driver has its own language, which would make harder to run the games later in different platforms. This is why I think making it possible to translate between languages could be an interesting idea. But this is a hard problem that isn't worth to implement in-house, it's better to bring an external library. Then in the case of SDL_gpu it would require also to write a new graphics driver for it, which isn't a small endeavor, since it uses concepts and ideas from newer APIs like vulkan that are much more verbose and complex than the classic ones we currently use.

About SDL_shadercross, it brings dependencies on additional dlls and things that will make AGS bigger and also additional files that needs to be in the folder where the game is, so if there is some other solution it may be interesting to look into them too. Other issue is because it is still experimental it appears to only be compatible with Linux and Windows for now - there is no metal for iOS/macOS yet or anything proper for Android or Web. I think they will get there one day, but just it is not there yet afaict.

Of course there is also an approach to make shaders API give the opportunity for the game dev provide both the D3D and OGL implementation, which would simplify all of this and make it not that hard to get it in the current drivers but it would have to have a careful API that lets the gamedev handle shader compilation failures at runtime in a graceful way. This would in theory not be that much code and the burden would be more in the design of API - I imagine it could start with just attaching a shader to the screen after everything is draw and then add something in the API to let it attach shaders to the game objects (character, room objects, overlays...)

I guess in the end given the current state of everything I would lean to come up with our own solution. Other issue is we don't have either shared graphical property or parent game object class - say with all things that are in an overlay - so if done before this, it would require copy pasting the changes of the shader API across all things.

I think in my head the API would be something with two objects, a ShaderDefinition and a ShaderObject (or just Shader) , and there would be a static ShaderCompiler thing that would take the ShaderDefinition and produce the ShaderObject. Then things like characters, room objects and overlays would be able to get a ShaderObject attached to them. This is all first draft idea.

[Rik_Vargard]

Thanks for sharing ideas. 

My basic idea was that it would just be applied to the characters.

Because blurred backgrounds and overlays and objects etc can be done in an image or animation editor.

[Crimson Wizard]

My basic idea was that it would just be applied to the characters.

Because blurred backgrounds and overlays and objects etc can be done in an image or animation editor.

Both objects and overlays can change position in the room as well.
If this is feature is supported, that will not be proper to force users to make blurred versions of object graphics, there may be cases where same object graphic is used for multiple objects and even in multiple rooms.

Not to mention that it's easier to apply a dynamic effect than do it in art program. If any changes are necessary, they will be done by changing parameters in case of effect, but reapplying them to sprites may be less efficient.