XOR drawing mode is so 1980's, but I need it!

General JUCE discussion
1

I am trying to draw into an Image using XOR mode. Jules once commented, “yeeuch… xor is so 1980s!”.

Yes. Exactly! I am trying to resurrect an old experimental music language from the 1980’s and it used XOR mode graphics to do rubber-banding. I am trying to keep as true as I can to the original language, warts and all. XOR has a certain nasty look that cannot easily be recreated using other means. In these days when people are slobbering over vintage analog synths and vinyl records, I hope you will understand. :wink:

Quartz has an XOR mode that can be set using:

  CGContextSetBlendMode(self.graphicsContext.graphicsPort, kCGBlendModeExclusion);

I believe that should work for B/W or coloured pixels.

Is there a way to do XOR mode drawing in JUCE, or to access the underlying Mac object and turn on kCGBlendModeExclusion?

1 Like
2

I have happy childhood memories of using XOR to make game sprites move around the screen on my Sinclair QL, but haven’t really thought much about it since!

Because we have so many types of graphics context, and they’re all very different, we’ve never attempted to add a way of letting you pull out the underlying native context handle, so I think doing that would involve a bit of hackery.

The pattern we often use to provide public access to very platform-specific under-the-hood native stuff is like e.g. VST3PluginFormat::setStateFromVSTPresetFile() where we have a static method that takes a base-class pointer and internally dynamic_casts it to see if it’s the right derived type, then does some shenanigans on it to perform whatever operation you need. So I’d have no objection to something like e.g. static void* CoreGraphicsContext::getNativeHandle (LowLevelGraphicsContext&); If you want to hack something like that in there, we’d probably be fine with the idea of adding it to the library :slight_smile: