Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

small questions on canvases (hidden default behavior)

A topic by june-tree created 21 days ago Views: 115 Replies: 2
Viewing posts 1 to 2
(1 edit) (+1)

hi!! i have a few questions about canvases:

feels like the only way i can see using them is either:

1. creating a new one from a current selected bit of art i drew on the background, or
2. doing weird stuff with scripts (this is delightful and fun)

I would love to be able to draw on canvases, and I see that when you delete the "default" template for the script of a canvas, when in Interact mode, clicking and dragging becomes drawing!  But only with a 1-pixel black line.  And without erasing.  So I have two questions:

1. Why is there this "hidden default" for canvas behavior?  (And what even is it!)  Also, if the default script featured whatever this hidden default is, then people could rather organically discover drawing on canvases and easily delete it for a "no-drawing" behavior.  [A lot of my confusion comes from the Draggable deck which says that scribbling on is normal behavior for canvases... but having trouble replicating that in my own deck until the script was wiped]

2. Why can't we draw with all the lovely drawing tools we have on canvases?  (Or will we be able to someday maybe?)  I like having patterns and ovals and all sorts of great things, and I know "write on the background then create a new canvas from it" does technically work but... it feels weird and clunky to have a canvas unpaintable.  Is there any way to make this possible?  Or are canvases designed primarily for lil script-interactions?

Thanks!
June

(1 edit) (+3)

Yeah, I'd say you have the right idea of what Canvases usually do... they store images and interact more easily with scripts. But there's a little bit more to say.

This is the default event handler for a new canvas:

on drag pos do
 if !me.locked|me.draggable
  me.line[(pointer.prev-me.pos+me.container.pos)/me.scale pos]
 end
end

(this one, and the other 'defaults' can be found in this section of the documentation if anyone wants to check them out!)

Opening a new canvas's script creates a couple of blank events ("on click pos do" "on drag pos do" and "on release pos do") for people who want to fill that in with their own code.

The blank "on drag pos do" event overrides the default behavior with... literally nothing. Absolutely nothing happens, until you script something else.  (Or you may have noticed that you can make a canvas to go back to the default behavior of drawing a 1px black line by deleting the blank "on drag pos do" section, which removes the override.)

You might also notice that the section of code above checks to make sure the canvas is not locked or draggable  before letting you draw on it. Being draggable removes the default ability to draw on a canvas in the same way that being locked does, and the draggables deck does make a note of that at some point but I understand it might not have been clear why it said that since it wasn't really the focus of the example deck.

This is, as far as I know, what's going on with that stuff.

---

But let's open the door to other things.

Drawing directly on the card has a range of tools coded in and ready to go, right? And Canvases... don't. But they could have some of them.

That script up there using me.line[] is the thing that makes a line when you drag your cursor across a new canvas. And if you poke around in the Canvas Interfacesection a little bit, you can find some other bits and pieces for scripting your own drawing tools for canvases:

.line[] makes lines
.brush[] lets you change which brush it is
.pattern[] lets you choose a color or 1-bit pattern to draw with
and there's stuff like  .fill[pos] to flood-fill, and so on

So you could, in fact, make a custom user interface that targets a specific canvas that provides most of the tools that are available when you're drawing on the card. I don't think it would exactly replace the card-drawing experience, as it is. I'm not sure about 'erasing' on a canvas and moving stuff around would be a lot harder without the selection box and lasso tool. So I'm afraid the small awkwardness of having to "Paste as new Canvas" might need to continue, honestly, if having the whole range of drawing tools as they exist on the card is your preference.

But, being able to create your own custom drawing UI where you draw in a special scripted way on a canvas is pretty fun if you have a cool idea for it. For example, Wigglypaint. (highly recommended,  and you can poke around at how unlocked decks were made)

(-1)

Ooh, thanks for finding the default event handler for new canvases (and everything else)! That's neat!  (Still find it weird that the default on-creation is distinct from the default absent-script!  Confusing design choice, imo!)

Yeah the default do-nothing script does nothing.  I was talking about a truly blank script (with no event handlers at all, but maybe a comment present).

Just to be clear, my primary question with the above stuff was not so much "how does it work" but "i think this design choice is a tad hostile to discovery... is there a good reason for it, or could it be different?".

---

Again, I appreciate the pointers towards aspects in the code already, and I think it is quite cute that it's possible to make your own drawing UI.  But, like before I was more pointing out "isn't it weird that the already lovely drawing UI that already exists is not by default available for canvases?"

Like, my question/critique was not as a user of decker wondering how best to interface with an already existent piece of software, it was as a person commenting on an in-constant-development project wondering about the design decisions and thinking some of them are rather confusing / a tad user-hostile and wondering if there was some really good reason they are that way.  I do appreciate you finding the section of the documentation with the defaults though, thanks!