Extensions being left out of build?

[CeriJC]

1. Firstly, I have next to no experience of extensions (aside from the Android ones), so please assume I'm an idiot/n00b.

Until now, I've consciously avoided using extensions, because I regularly port my projects to/from Android/Windows and rather than keep track of which are supported on which platform and then hit this type of error when I come to build a project, I leave them out.

For something I'm working on (Windows only), however, I've had to use resort to using Viewport, as there's no other way of doing what I want to achieve. It seems to be working great, but when I build it I get that dreaded message,

"Warning the following extensions are not compatible with this build type:

Viewport.mfx

Do you want to build anyway?"

The Viewport works exactly as expected when running the frame/application within Clickteam, it's only on build that it fails. I've double-checked and the build type is, "Windows EXE".

I don't understand why I'm getting the error, I thought Viewport *was* solely Windows-specific? I'm using R281.1, Clickteam Fusion 2.5 (standard, non-developer version). Is there anything I can try/check?

----

2. One other Viewport related question: Is it possible for me to apply a shader to the Viewport display?

Essentially, what I want to do is use a viewport to "magnify" an area of the frame's field and then apply a shader to *just* the viewport, not the whole frame. The nature of the shader concerned precludes my applying the shader to every object/backdrop within the magnified area as a workaround. Under other objects' "Settings" or "Display Options", there's normally an area where you can edit the 'Effect' and stipulate a shader. Viewpoint seems not to have this. Is there any other way of applying a shader to it?

ViewportShaderQuery.png

Alternatively, is there another extension that does what Viewpoint does that supports shaders in the way I describe?

[schrodinger]

1. I would try upgrading to build R284.10, I can build with viewport without any issue,
so the only thing I can think of is an outdated Fusion version?

2. Only thing I can think is applying the shader to the whole layer (adding an overlaying layer for the border)
but I guess your scanlines (if I remember correctly what you are doing ) would be magnified as well
because the shader would be anyway applied to all objects prior to magnification
or maybe even the effect could not work at all in the viewport
(just tried some quick tests and seems that the viewport behaves in odd ways with layer effects)

Now, please forgive if what follows is absolute rubbish
- I am no scanlines expert, and beside noticing them I've never studied how they are exactly supposed to look/behave -
but maybe you could achieve a decent result by overlapping a "scanlined" active to the viewport,
with alternate stripes of apt size, like if you magnify the graphic x 4
doing 1 pixel thick scanline every 3 magnified pixels
and/or maybe some alpha transparency to fake the eye if needed..?

I guess you would lose 1/4 pixel (overlapped by the scanline) which is something you don't want - don't lose with the shader,
and the overall "consistency" of real scanlines (every pixel always visible and popping throughout scanlines)
because I suspect you are going for a very realistic effect and not just a faking..

[CeriJC]

Hi Schrodinger, you remember correctly!

I'll try '1.' . Please can you confirm what the 'correct' way of getting the Viewport (version that you have, that works) into Fusion and the specific version of Viewport that you have?
EG did you use "right click, insert object, manager, viewport, install", or did you do it the old MMF2 way in windows folder (in which case, where did you get the .mfx files and where exactly did you put them?). Many thanks!

2. The workaround I was doing earlier involved using a large, semi-transparent active (consisting of black horizontal lines), continually brought to the top layer. Previously, it wasn't working well at fullscreen, because, as you suggest, the scanlines themselves scaled up and looked much too wide. Losing 1/4 pixel (IE, one physical pixel at x4 magnification) is fine as your eyes see the other 3 pixels representing that (one) pixel and your brain does a great job of filling it in. The problem is primarily that 'whole frame' shaders apply over the top of the 'border' area (see above diagram) which is fine if the border is solid black, but terrible if you make it look like an arcade machine's bevel lined with 'stickers' as I'm doing for this game.

What it is that I dreamt of, which now seems painfully obvious (as is usually the way with these things), is that you can write shaders to have a 'virtual resolution' and only apply the visual effect to certain areas of the frame. In this instance, I'll just make the shader whole frame, but only apply the effect to the area covered by the "Viewport" bit in the above diagram. It'll mean needing to mod any shaders used to make them compatible with these specific ratios/borders, but 'meh' I was planning on making my own, or at least porting a GLSL one anyway.

Fingers crossed, the outcome will be, I'll have a 1920x1080 application, with a "Faux-CRT" option for use when it's used on a modern screen. That'll be a shader, which can be turned off when run on a real CRT. The ratio of the borders is such that when the 1920x1080 is output to a real CRT (through a hardware scaler I have), the same application, with no other sizing will display fullscreen in 4:3 ratio: It'll just be the border that's left out. The only potential stumbling block I can see (aside from my HLSL skills not being up to the job ) is that according to how the shader pipeline is implemented for "whole frame" shaders, I might end up having the shader applied twice for areas of the screen covered by the viewport. Oh well, easy to test and I'll know soon enough.

Wish me luck!

[schrodinger]

Good luck man!

1. I would confirm that I got it through the extension manager if I was sure I did,
but I took Viewport some time ago so can't be 100% sure... (I'm about 90% sure )
I'd say anyway to get it there, since I guess the extension manager should always point to the most updated/Fusion tested version.
As for my version - can't find it written anywhere, except for this line in the .mfx file:

P r o d u c t V e r s i o n 1 , 0 , 0 , 0 2
S p e c i a l B u i l d 0 0 0 0 0 0 0 1


2. looks like you're up to something! With my little experience in shaders methodics I can't definitely help, but if you're not successful, I've another idea to test... on the paper it should work, but I'm worried about performances. Yours is probably much better so wouldn't test at all if not necessary.

Ehm, one last note on this line:
as I'm quite a noob with shaders, and I've a little issue I would like to hear a "shader expert" opinion on - could I pm you on this?
(feel free to say no if you're busy - but don't be scared by the task either,
I guess one with good shader knowledge would be able to check this in very short time)

[CeriJC]

Schrodinger:

Sorry for delay replying, real life got in the way for a bit and I've hardly started Clickteam up the past month but getting back into it.

1. Thanks for you help, oddly, I upgraded to the latest version of clickteam (didn't update viewport) and it now works great, even not having updated the viewport itself. Just about to go and test the real CRT works perfectly on the viewport/border setup I have, but I'll be amazed if it doesn't now.

2. I'm certainly "up to something". Now I've got all the other bits in place, my main focus will be on the shader. I am certainly a noob with shaders' syntax (and certainly HLSL's), if not the concepts. I did my undergrad thesis on procedural textures, which shares a lot of the same concepts so, I feel I'm picking it up much faster than someone without that background, but I'm a long way off being a guru! That said, I certainly feel I owe you one (several) and if you want to send me a PM I'll try and help, even if it'll take me a few weeks to get to the level where I can be of any use.

[schrodinger]

Glad you've solved your issues with the viewport!

Thank you for getting back on my little request,
luckily looks like it's being worked on meanwhile so you're probably safe
(it was about this bug, was looking for some shader expert available to test a couple things -like the stack overflow link suggestion on post #19-,
but now the issue has been picked by Clickteam and Jesse found some additional insights allowing at least to "circumscribe" it,
..of course, if you have some extra time and will, a couple eyes and a brilliant brain more could make for more chances of solving!)

[CeriJC]

Ouch! That looks a nasty bug. I know from past experience that when they change the pipeline (typically to make it *more* tweakable/programmable) in new graphics card architecture, it can make for big problems that are often non-trivial to patch with regards running functions designed for the old card. :|

[_blob]

Yikes, I'm having problem 1. as well!
Just using the good old joystick 2.mfx and it works all fine in MMF2 but cant make a build with it! I tried exporting an older project that never had issues with it and even this one wont export anymore, so it seems something happened when I updated MMF...
Anyway to avoid that ? That newer project was made under the updated MMF so i guess it might be tricky to run on a non updated version but i cant seem to find any way to get joysticks working otherwise! :S

[DaveC]

Didn't read the thread very well at all - but did you make sure the extension is in both the Extensions folder AND the data/runtime folder?

Clickteam Fusion Developer 2.5\Extensions\Hwa\Viewport.mfx

Clickteam Fusion Developer 2.5\Data\RuntimeViewport.mfx

[_blob]

Uh! That was it, it was missing from the data/runtime folder o_o
Doh, first time I get this. Thanks a lot, phew!

Here's the game by the way (made for ludum dare 35) https://brobbeh.itch.io/dopple-trouble