Moved from F3 thread: Colour replacing in F25 / F3

[MENTION=8318]N64Mario[/MENTION] Colour replacement is a pretty inefficient process, best done with shaders where possible. If it gets to the point where you are replacing colours in an entire graphics set I would suggest you should rethink how you're using and preparing your graphics and look for a more efficient approach. I am not sure F3 will support this outside of shader based solutions.

No there isn't an alternative which in F25 will work in all exporters, but the fact remains this is an expensive operation and its use is quite niche and I would not expect it to definitely continue through to F3.

N64Mario, what you are trying to do is fake a feature that was built into old hardware but has not been a native feature of most computer systems for more than a decade. Shaders are the most efficient way to fake it on modern hardware. As far as making separate assets per palette, if you are sticking to NES era specs, you should have almost no overhead for art assets to begin with so having a half dozen duplicates won’t matter at all in terms of HDD space or ram usage.

It seems CF2.5 will never give you your wish. And it sounds like CF3 will allow you to do what you want with shaders. But Flash support is probably gone in CF3 because it is a dead platform (Adobe cut support for it so why would anyone else support it). So you will have cross platform solutions for color replace but you’ll need to do it with shaders (which is pretty easy to do).

Clickteam doesn't "hate" colour replace, it is simply that it is a very outdated bit of processing as Mobichan said. It dates back to a day when hardware supported this sort of feature as a bodge to overcome other limitations. This dates back to the first popular home computers. It is an ancient trick, one which these days has to be performed in CPU hardware (or GPU if you use a shaders solution).

When this action is triggered, Fusion has to cycle through every single pixel of every image involved (frames of animations for example) an create a clone/map change the colour from. This is slow and laborious, that is why it takes a long time and lots of memory. Not every platform allows this remapping of colours, so it cannot be universal amongst our runtimes.

In short this feature is incredibly out of date, a throwback to 1970s/80s computing and it is not used by many users at all. When we come to F3 we have to choose whether to waste tonnes of dev time on outdated issues which virtually noone will use, or provide better development of modern alternative features such as universal shader support which provide more flexibility to the vast majority of our users.

So again, this is not about CT hating a certain feature, just about moving forward with modern techniques and features whilst dropping redundant ones.

Fusion 2.5 will not cease to work when F3 is launched so you can still continue to use this if you feel lack of colour replace is a must have for you.

[MENTION=8318]N64Mario[/MENTION] HTML5 can use WebGL which does support shaders. I've not looked too deeply into it, though. Also I think a key point you're missing is that all these modern games that do color swaps are also "faking" it too, because it's more efficient than the original way.

[MENTION=8318]N64Mario[/MENTION] I've just explained why it has to be faked, it's because VERY old graphics hardware supported it. It's because pallettes were limited and you could perform literal redefining of palette indexes so if everything on palette index 2 was blue, you can deefin or swap index 2 to orange and change things instantly. Modern computers run with millions of colours and don't operate in this way.

Again, what you are doing is very niche and used by only a small handful of users, using expensive techniques which are not possible on all platforms, so set your expectations accordingly for F3.

We are not currently planning to make shaders work on all platforms because of the differences between platforms and the shader languages they use.

Again, it is almost 100% "faked" if it was in a game released in the last 20 years. The only exception I can think of would be the Gameboy Advance. The only reason the last gen of 2D fighting games in arcades could palette swap was because they were made on older, specialty hardware. When we are talking about modern consoles (PS2 era to the present) or PC's, any sprite coloring was done either through vertex coloring or shaders. What you refer to as "usually standard in video games" has not been a standard since the early 90's.

If you have another example you want to discuss, I'm sure we can examine it and help you figure out what fakery was used. And to clarify, I am a pixel artist and work almost exclusively with 2D games in CF2.5. Unless you are working in non-era specific resolutions, it will not affect your RAM or filesize much if you save out pre-colored variants of your art. As a matter of fact, that is the only truly cross-platform compatible solution right now.

[MENTION=5109]Simon[/MENTION]: was that statement about not supporting shaders in reference to F2.5 or F3?

@Please login to see this link. only F25 - Fusion 3 has been built from the ground up to use OpenGL technology so it is cross compatible on virtually every platform.

The reason we probably can't address this in F25 is that it uses DirectX and HLSL for shaderss (compared with GLSL for OpenGL). Converting a HLSL shader program to GLSL automatically is problematic and so it means that we cannot provide a seamless experience where you build on PC and it works identically on target platforms. Whilst there are other cases where we have allowed this, for example Flash/Android extensions not functioning on PC, they are less core activities... altering the display in a reliable repeatable way is fundamental to understanding how your program will function.

You're missing the point - it IS possible, it's just very slow and expensive. You're also missing the point that it is virtually unused, so it's not a likely candidate. Your application is niche and CT needs to focus on features which provide maximum benefit to most users - colour replace is not one of those functions.

[MENTION=8318]N64Mario[/MENTION]: As a pixel artist I understand your points, I’d love to work with indexed sprites too. But not everyone likes to limit a sprite’s color count to just 256 colors. Using indexes beyond that count get really expensive compared to displaying RGB-based images, so performance for most engine users would suffer to please the hardcore pixel artists. Shaders can do the job really well, but there is of course the issue that shaders have to be adapted for each target platform which can be a ****load of work. The ideal thing for me would be to have the option of an indexed sprite mode but that is nothing I would demand from CT, even Unity does not have such a thing AFAIK.

This dead horse appears to not be quite beaten enough yet, so...

MUGEN s a very niche example and not at all a standard in the game industry at large. It is also a VERY old engine now. It was built on the concepts of older arcade hardware. That is why it gives you the functionality of old hardware. But it would be pretty inefficient if it didn’t handle palettes on the GPU side. MM9 is a case of fakery. IntiCreates made it on Wii and Xbox 360 as lead platforms. I would say with 99% certainty that it is shader or vertex coloring if it is using some sort of real-time coloring. But it is more likely they just ran a Photoshop script that exported assets in different colors.

[MENTION=5109]Simon[/MENTION] thanks for clarifying. For a moment I thought the original promise for F3 had changed.