5 ms·

Could you do this in real-time with a post-process shader on PC? shadertoy.com?

by brador 9y ago

boomlinde 9y ago
I don't think fragment shaders are suitable for this, since the HAM modes are very stateful. In HAM6 for example, a screen is composed of a bunch of 6-bit instructions encoding one of four operations each with four bits of data. You can either set the color directly to any of the colors from a 16-color palette, or you can use the color of the previous pixel, modifying one of its RGB channels. This is similar with HAM8 but in order to be able to use more of the 24-bit color space the instructions are 8-bit wide with six bits of data, and you can only modify the six most significant bits of a color channel and directly use a 64-color palette instead.
- dahart 9y ago
  FWIW, you can do plenty of stateful things on shadertoy, as long as feedback and multiple buffers are allowed. There are complete interactive games on shadertoy. I think it wouldn't be hard to render HAM in a fragment shader. If you're okay with very non-optimized colors, of course, you can use the direct set instructions only, and skip the neighbor modify instructions. But I've done several shaders on shadertoy with neighbor-modify type functionality, including a Floyd-Steinberg like dither, it just takes multiple frames.
  - deleted 9y ago
    [deleted]
  - boomlinde 9y ago
    Sure, you can maintain state in a texture and iteratively re-apply the shader to it. The problem with HAM is that it potentially requires many iterations. Consider the worst case scenario of an input resulting in a single set color operation followed by width x height-1 modify operations. Not too bad for a simple stateful loop on the CPU, always keeping the last color in a register, but with a shader re-applied once per frame to 320x200 pixels you'd be waiting for ~20 minutes for the complete result at 60 fps. Then there's the problem of selecting a useful base palette, if you want consistently decent results regardless of the input. That's maybe the kind of optimization problem that OpenCL can be applied to. So I don't mean to say unsuitable as in impossible, just in the sense that it's exactly the kind of problem that the shader model wasn't designed to solve.
    - dahart 9y ago
      I don't disagree with the idea that ShaderToy wasn't designed for this, or with the idea that it'd be harder to do in a fragment shader than a CPU program. But fragment shaders weren't designed for most of the things you see on ShaderToy. ;) The question is whether it was possible in real-time, and I still think it is. I'm not very interested in the worst case, I think a HAM image with width * height modify ops is very unlikely. I might even be surprised if such a HAM image has even ever existed, outside of perhaps a contrived programmer's example. The average case for a direct HAM implementation would probably be more like hundreds of frames, or a couple of seconds, not tens of thousands. If a modified HAM is on the table, the worst and average cases could be improved considerably. I modified Floyd-Steinberg (which is worst case) so that it runs in more like 10-20 frames, by making it radially symmetric and limiting the propagation distance, which results in negligible differences but vastly improved run times. The palette optimization is also possible in a fragment shader, not quite as easily as OpenCL, but possible. If the question were about transcoding a video stream in real time, that will be harder to do real time. If the optimized palette is fixed, it will be easier. Either way, I wouldn't rule it out. But I would agree it's "hacking" in the sense of abusing things they weren't designed for.
      - boomlinde 9y ago
        > I'm not very interested in the worst case, I think a HAM image with width * height modify ops is very unlikely. Sure, but maybe not as far off in some real world cases. Say, black-but-not-perfectly black letter box bars where the nuances could result in long sequences of small alterations to the base black color. This becomes less likely with an optimized palette, and of course you could set a hard limit to length of modify sequences in conversion, though that would have to compromise the quality of conversion. > The average case for a direct HAM implementation would probably be more like hundreds of frames, or a couple of seconds, not tens of thousands. Then the problem, with respect to the original question, is the definition of real-time. For the purpose of a game like No Man's Sky for example I'd think hundreds or even tens of frames would be unacceptable. Don't get me wrong, I love technology applied to the "wrong problem" and see that as an end in itself sometimes :). I'm just considering the feasibility of accurate HAM in realtime using shaders, and am really enjoying the discussion on what compromises have to be made for it to perform adequately in a shader. But with respect to the original question I can't quite bring myself to say "yes"

Could you do this in real-time with a post-process shader on PC? shadertoy.com?

by brador 9y ago

Could you do this in real-time with a post-process shader on PC? shadertoy.com?

I don't think fragment shaders are suitable for this, since the HAM modes are very stateful. In HAM6 for example, a screen is composed of a bunch of 6-bit instructions encoding one of four operations each with four bits of data. You can either set the color directly to any of the colors from a 16-color palette, or you can use the color of the previous pixel, modifying one of its RGB channels. This is similar with HAM8 but in order to be able to use more of the 24-bit color space the instructions are 8-bit wide with six bits of data, and you can only modify the six most significant bits of a color channel and directly use a 64-color palette instead.

dahart 9y ago
FWIW, you can do plenty of stateful things on shadertoy, as long as feedback and multiple buffers are allowed. There are complete interactive games on shadertoy. I think it wouldn't be hard to render HAM in a fragment shader. If you're okay with very non-optimized colors, of course, you can use the direct set instructions only, and skip the neighbor modify instructions. But I've done several shaders on shadertoy with neighbor-modify type functionality, including a Floyd-Steinberg like dither, it just takes multiple frames.
- deleted 9y ago
  [deleted]
- boomlinde 9y ago
  Sure, you can maintain state in a texture and iteratively re-apply the shader to it. The problem with HAM is that it potentially requires many iterations. Consider the worst case scenario of an input resulting in a single set color operation followed by width x height-1 modify operations. Not too bad for a simple stateful loop on the CPU, always keeping the last color in a register, but with a shader re-applied once per frame to 320x200 pixels you'd be waiting for ~20 minutes for the complete result at 60 fps. Then there's the problem of selecting a useful base palette, if you want consistently decent results regardless of the input. That's maybe the kind of optimization problem that OpenCL can be applied to. So I don't mean to say unsuitable as in impossible, just in the sense that it's exactly the kind of problem that the shader model wasn't designed to solve.
  - dahart 9y ago
    I don't disagree with the idea that ShaderToy wasn't designed for this, or with the idea that it'd be harder to do in a fragment shader than a CPU program. But fragment shaders weren't designed for most of the things you see on ShaderToy. ;) The question is whether it was possible in real-time, and I still think it is. I'm not very interested in the worst case, I think a HAM image with width * height modify ops is very unlikely. I might even be surprised if such a HAM image has even ever existed, outside of perhaps a contrived programmer's example. The average case for a direct HAM implementation would probably be more like hundreds of frames, or a couple of seconds, not tens of thousands. If a modified HAM is on the table, the worst and average cases could be improved considerably. I modified Floyd-Steinberg (which is worst case) so that it runs in more like 10-20 frames, by making it radially symmetric and limiting the propagation distance, which results in negligible differences but vastly improved run times. The palette optimization is also possible in a fragment shader, not quite as easily as OpenCL, but possible. If the question were about transcoding a video stream in real time, that will be harder to do real time. If the optimized palette is fixed, it will be easier. Either way, I wouldn't rule it out. But I would agree it's "hacking" in the sense of abusing things they weren't designed for.
    - boomlinde 9y ago
      > I'm not very interested in the worst case, I think a HAM image with width * height modify ops is very unlikely. Sure, but maybe not as far off in some real world cases. Say, black-but-not-perfectly black letter box bars where the nuances could result in long sequences of small alterations to the base black color. This becomes less likely with an optimized palette, and of course you could set a hard limit to length of modify sequences in conversion, though that would have to compromise the quality of conversion. > The average case for a direct HAM implementation would probably be more like hundreds of frames, or a couple of seconds, not tens of thousands. Then the problem, with respect to the original question, is the definition of real-time. For the purpose of a game like No Man's Sky for example I'd think hundreds or even tens of frames would be unacceptable. Don't get me wrong, I love technology applied to the "wrong problem" and see that as an end in itself sometimes :). I'm just considering the feasibility of accurate HAM in realtime using shaders, and am really enjoying the discussion on what compromises have to be made for it to perform adequately in a shader. But with respect to the original question I can't quite bring myself to say "yes"