Please ask about Fusion 3 in the Fusion 3 thread only @Dobermann
Will it be possible to set the rendering mode via an event? I would love for users to be able to choose between DX9/11 instead of having to save out two separate EXE's.
not through events, but you can do this now using command line arguments, it has not changed in the plus version as far as I know.. make a separate simple launcher app that launches the main exe in two modes..
the problem is that shaders work differently in DX9 and DX11 so if you use a lot shaders, some of them might not look or work correctly in the other mode
I was planning on building a launcher anyway as the game is very reliant on both Read & Write functionality and we've had some trouble with users on heavily locked-down systems even writing to the AppData folder. Meanwhile, many distro platforms do not support Fusion's setup file format, so creating a separate app that can place the game files where they need to be is going to have to happen. I'll just make sure it also includes runtime modes.
Luckily the only shader the game is using is Invert so it should be A-OK, just hopefully faster and potentially even more stable in gigantic levels on DX11.
Yup, I've had my eye on that one!
Excited to learn more tomorrow!
I just read the blog about child events, and it's very exciting. It's clearly a must-have feature. I can't wait.
But, the interface designer in me sees problems with how it seems to work at the moment, by potentially muddying up the clarity that Clickteam Fusion is famous for. There would be a few ways you could tweak the UI to prevent this, so please consider taking the time to do so.
Here's an example of what I mean. The next 2 screenshots show some regular (non-child) events.
The 2 above sections are similar, but have different conditions. Now, if we move those conditions into a parent event, the above screenshots look like this:
The global value = .... conditions have moved off-screen, into a parent event, which introduces some obfuscation into the user experience. When we glance at this section of our events in list mode, we have three problems now, all tightly related:
Problem 1: it is impossible to know by looking at them whether these are child events or not. Sure, they are indented 12px to the right, but that could just be because they're inside a group - we don't know. Besides, our events are already indented several times from being in groups and subgroups, so it's hard to even tell just how many levels of indentations there are.
Problem 2: We can no longer see the whole events, which could lead us to misunderstand how they work. What was once a neat, self-contained event with conditions and actions shown side by side in readable format is now splintered, with 1 condition somewhere off-screen. This wouldn't be a big deal if we knew instantly and unambiguously that we're looking at a child event, but we don't (problem 1)
Problem 3: The two sections of code (ie. the two screenshots) look virtually identical. We could easily mistake one section for another, leading us to erroneously work on the wrong events, creating bugs in our code.
You might say, 'but wait, groups already work just the same way, and no one complains about them. Groups get indented and if a group header goes off the page you don't know whether an event is nested or not'. But the important difference here is that groups can be closed! In fact, you can currently use groups as a kind of 'poor man's child events', as shown below. Here we have a scenario very similar to the above scenario, but using groups. Because groups can be closed, the result is much less ambiguous:
For all of these problems, the only solution is to be on alert for them, and keep scrolling up and down to check whether the events you are looking at are parented or not. This might sound trivial, but it's not. I want to stress this point, because I really believe it's important. This creates busywork, and also requires you to use more of your working memory while browsing your events:
-you need to keep an event in your memory, while you scroll up to see if it has a parent.
-if it has a parent, you need to commit the parent condition(s) into your working memory, while you scroll down back to the event
-You need to keep that parent condition(s) in working memory the entire time you work on the event, or else scroll back up manually to check for it.
All this extra load on your working memory adds up eventually, and is a tax on the pre-prontal cortex, which is the most neurologically expensive part of our brain, and so is preciously limited. The more stuff we need to keep in our working memory, the less bandwidth our pre-frontal cortex has for problem-solving and focusing, which we obviously need for our eventing.
I don't want to sound overblown with all this pre-frontal cortex stuff, but I think it's really important to point out that one of the reasons Clickteam Fusion is so fantastic and has been so loved for so long is precisely because of how efficiently it lets us manage our pre-frontal cortex resources. We might not think of it in those terms, but that's absolutely what's going on.
People who do syntax-based so-called 'real programming' need to keep masses of information in their working memory: a vocabulary of functions and methods, how to spell them, how to punctuate them, and so on. By giving us a syntax-free programming environment where our available options are shown in neat drop-down menus instead of stored in our working memory, Clickteam Fusion is dramatically cutting down on how much our pre-frontal cortex has to do, which leaves us with more bandwidth to devote to the logic side of it. That's why Fusion is so easy to use for people who feel otherwise intimidated by programming. It requires us to juggle with far fewer balls.
There would be a number of ways you could tweak child events to avoid the problems I'm talking about. A few ideas off the top of my head:
A. color or otherwise mark child events differently (make it skinnable please!)
B. reproduce a reference of the parent conditions (somehow formatted differently than real conditions), either at the top of each child event, or else appearing at the top row whenever the parent disappears off-screen
C. make child events closeable, just like groups are.
My preference would probably be for a combination of A and C
This is a set of child events to a parent... it is completely obvious that it's nested, even when you don't have a return to previous indentation afterwards:
Frankly, if you start colouring things differently rather than just using nesting as Fusion always has, you're breaking with the UI rules we've set out and giving people a whole extra set of rules to learn, which is actually much more of a no-no in HUI/GUI realms. I really don't see the issue here, at all.