pouët.net

Vim bindings, anyone ? No ?

...why?

Because I don't know how to type without them anymore. And (hopefully :p) I'm not the only one out there...

Okay so this has been a recurring thing both on Github and at other places, so it's probably worth making clear (and prolly eventually adding a CONTRIBUTING file to the repo as well)

The sole purpose of this tool is to provide an equally fair (in opportunity, not in outcome) platform upon which parties can organize competitions with. That is the entirety of the scope and the mission objective.

Many people are using this tool to learn shaders, and that's fantastic and I'm happy about that, but I'm going to push back on any modifications to this tool to accommodate things specific to that (like includes, etc), unless they enhance the competition experience for the competitors (in a fair way) and the audience. As the tool is opensource, nothing is stopping you from adding your own features, hell if you band together with others feel free to make a central "best shader editor" tool, and if other parties opt to use that one, more power to you and finally I'll have one less thing to care about.

But up until then, my job is to make sure there's always a version of the tool that's 1. bulletproof 2. standardized and 3. publicly available and agreed on by the majority is available come party time. By that logic any modification tailored to your specific taste I will push back on.

There's a lot of "best shader editors" out there, and I do not need nor want this one to become my every day editor.

This is not my point, though, which is more : I know a lot of coders out there that uses vim (or vim modes enabled editor), and especially in a time limited coding challenge, quick & efficient text editing is real plus, not a fantasy.

The thing I don't know is if scene coders are used to vim as much as others may, (provided they're not the same guys).

I did not intend my previous post as a feature request, but as an interest check.

Giving an advantage to coders used to vim is basically the opposite, I for example am not super used to vim bindings and if there'll be vim bindings I'm the first one to request sublime text bindings ...

Again: equal in opportunity, not in outcome.

Re: Bonzomatic

I had to change to hack around with Scintilla's KeyMap.cxx a little bit to get the option+left/right keys to work. I think the keymap was originally made for X11 or XQuartz or something where you can map something to the "meta" key, but at least my lowly old MBP only sends the "alt" modifier code for the "alt/option" key, and I couldn't figure out how to send a "meta" to Bonzomatic. So I changed the keymap to use "alt" instead so that I can now jump words with option+left/right, and shift+option+left/right.

So:



And remove or comment out all the "...RECTEXTEND" rows, which are weird commands anyway.

I'm sure there are any number of explanations why this was the wrong thing to do.

...and that was about getting Bonzomatic's editor to work properly on a MacBook Pro and OSX Yosemite.

Can confirm, but I'm using inotify to live-reload modifications coming from nvim.

Do you think adding support for a secondary monitor would be good for competitions?

As in, it can display the shader (without editor) on a second monitor so that the audience can get a full view of the shader the entire time.

It's called a "live coding" competition because you see people coding. Being able to see exactly what they see is the whole point.

Besides the complicating factor (it adds two streams two the already existing 4 streams (=2 webcams+ 2 screens)) it seems a good idea from a visual standpoint right? Instead of waiting for the competitor to enable fullscreen mode, the director has the option to put either one of the two shaders fullscreen without code at will.

I'm struggling to think of situations in which you'd rather see a fullscreen version of the "old" version of the shader over the changes being applied by the coder live. It would only make sense for a handful of seconds after the coder presses F5, after that it would be annoying not to see what the coder is doing, imho.

*without the coder
Obviously I wasn't too awake when I wrote that

The 2nd screen would be exactly the same as the first screen minus the GUI. Sometimes it's a bit hard to see what changes the coder has made to the shader since its a bit hidden by the GUI. Having an extra screen that renders the current shader on its own would be a nice thing for the audience to appreciate the tiny adjustments the coder makes throughout the match IMHO

This is an additional stream. The audience would still be able to see the code whenever the first screen is switched to by whoever is controlling the streams for the audience

Couple of issues:
- First off, as I said, seeing the code is part of the principle. You don't just broadcast a basketball match with the camera fixed on the hoop since that's all what counts.
- You only ever have one bigscreen, and there's already 2x2 images to direct; adding one more screen that is essentially the same as the other ones is just extra work for no discernible reason.
- The effect doesn't change THAT often; I don't claim to have made stats but there are long stretches where there's a lot of boilerplate being written so a code-less screen would be even less exciting, and removes the fun little speculation bit of what to expect.
- Like it or not, livecoding is a presentation sport - whether the coder is showing the effect or not is part of their presentation strategy; either they hide the code to take a closer look, or to signal to the audience that they're happy with this stage and the audience should take that into consideration. If you remove that, you're removing showmanship.

Basically what Gargaj said! ;)

But i see the demand and i think a solution would be to just stream the normal picture to the beamteam, as is right now, and additionally just the renderTexture with the graphics and without the Text ontop...
...this way the beamTeam could make decisions, when to hide the code and show the shader in its current stage in all its glory, on their own!

I think the scene generally likes this new compo a lot (i for myself love it, but i am a coder, and even competing in them compos), so we should be open for suggestions to make it even better for sure!
But i also see there´s a lot of additional work to be put in first codewise, and also ongoing for the beamTeam and also the Moderators...
...so waging if it´s worth it is not that easy! ;)

Maybe just put a poll inside the voting-system @Revision for most-wanted-change in any Compo! Winner gets delivered until next years Edition! ;)
If above feature would win f.e. Gargaj would have a lot of fun implementing it in the next 12 months...more atleast than doing it fast and half-heartedly, so we have it until this years Edition already! :/

My only wish for ShaderShowdown is:
If PS moderates it again at any point of time....please someone teach him there´s no PostProcessing in ShaderShowdown, as Bonzomatic is SinglePass! ;)
--> PS: There can´t be HypnoGlow without post-processing! ;)
My only second wish for ShaderShowdown is:
Add MultiPassing! :D
(i got that 3-liner doing HypnoGlow in my 4ks! ;) )

So not what I said at all?

Oh, so you do that already! Oops, misread this i guess! ;)
I thought it´s a direct grab of the complete screen right now! (via 3rd-Party software)
If the BeamTeam has both Textures already, it´s just up to them to make the best out of it then! ;)
I´d like to see that maybe, but could get quite chaotic with 2 Moderators trying to interact with the BeamTeam while moderating and while the BeamTeam is doing their regular routine already!

alt idea would be remote code overlay toggling (by beamteam or whoever mediates the stream) but still... would be watching paint dry...

Read again.


lol

having the effect from time to time w/o code (like it is done during the compo) is a nice instrument for crowd control i guess :D might not work that well if everyone could see the effect all the time.