Post by Internet Janitor in A Couple Suggestions

Viewing post in A Couple Suggestions

Glad to hear you're enjoying Decker! I'm sure everyone here would love to see anything you create and feel like sharing.

Native Exports

Allowing Decker itself to produce standalone native executables for OSX and Windows would be a daunting task; I think this is out of scope for the forseeable future. At present, if you want to ship a deck as a native executable, a web export should work fine in a browser container like Electron. Alternatively, you could build Decker from source and replace the guided tour deck that is normally embedded in the executable with your own.

Lightweight Exports

Web-Decker with an empty deck currently weighs in at about 300kb, of which less than 50kb comprises the "editor" features like drawing tools, menus, and property dialogs. Most of Web-Decker's size comes from the Lil interpreter, its standard library, built in resources like fonts and transitions, the DOM APIs, and the rendering primitives and UI toolkit that are used by every deck, even if you never leave Interact mode. I don't think a 1/6th reduction in size for a "Decker Player" fork justifies the additional maintenance effort it would require.

It is currently possible to "lock" a deck to hide the main menu and editor features, if you wish to present a deck as a sealed, finished product. When space is at an absolute premium, you could consider providing a web build as a compressed .ZIP (which should easily achieve a 50% or more ratio) or offering users the plain ".deck" files, which completely exclude that 300kb runtime.

Lil Function Reference

All of the functions available to Lil in Decker are described in the reference manual:

https://beyondloom.com/decker/decker.html

It's fairly short, and has a lot of ground to cover; I don't think it could be condensed very much without losing important information. There is a quick reference card for Lil and its primitives available here:

https://github.com/JohnEarnest/Decker/blob/main/docs/lilquickref.md

If anyone wishes to have a go at making their own reference cards or tutorial materials, they're more than welcome to do so- there's only so much I can write myself!

I'm unable to reproduce the issue you describe with buttons on the first card of a deck; please provide a more detailed description of what you're doing and what's going wrong.

SourdoughGames2 years ago(+1)

Hey! Thanks for the reply! I understand the scope of a lot of these suggestions and how, honestly, miniscule they are, so don't feel rushed in any way. I won't be offended if nothing comes of them, because my foolish self couldn't dream of making anything like this, so who am I to say what's possible or not.

As for the bug, I downloaded the file onto another computer and it ended up working fine, so it's likely just an issue on my side. Thanks for the help, and sorry for bothering you.

SourdoughGames1 year ago(+1)

Oh yeah, possibly GIF support/onion skinning between cards, but I'm not sure how many people besides me would use that. Thank you though.

Internet Janitor1 year ago (1 edit)

Onion skinning is worth thinking about, but I agree it's rather specialized. The recently-added "grid-step" features in FatBits (press shift+arrows to move the FatBits viewport in increments of a configurable grid size) could be used to quickly flip between sprite frames. This isn't specifically intended for animation, but it might be useful for small stuff:

Right now, Decker can export GIFs in two ways:

If you use "File -> Export Image..." you can save an image of a card or selection as a GIF. If you use animated patterns on the card, the exported GIF will reflect them.
You can write Lil scripts which programmatically generate frames of an animated GIF and save them. For example, this script can be executed directly in the Listener:

canvas:card.add["canvas"]
canvas.size:160,160
frames: each f in range 32
  canvas.clear[]
  each color name i in colors
    a:pi*(i/8)+(f/16)
    canvas.brush:4
    canvas.pattern:color
    canvas.line[80+60*unit a]
  end
  canvas.copy[]
end
card.remove[canvas]
write[frames]

Try it!

Right now you can also programmatically import static images in a variety of formats with `read[]`. Adding support for importing GIFs as a series of individual frames programmatically isn't too hard, and it's on my todo list, albeit pretty far down. If you mean importing a GIF and having it become a widget that just plays on a card, that'll be a bit trickier, but it may fit into some other functionality down the line.

artfluids1 year ago (1 edit) (+2)

Would it be possible for the Decker executable to look for a default .deck file on startup? So that way all you would have to do is throw the Decker .exe and the .dll files and a "main.deck" file into a folder, rename the executable and voila, it's basically the same as a native export. And if there's no "main.deck" in the same directory, it will just boot as normal.

One other issue along these lines I'd like to mention: If you open a protected deck and then try to close the application, it warns you about unsaved changes. I think for a protected deck it shouldn't warn you about that.

Internet Janitor1 year ago(+1)

In v1.12, native-decker will no longer complain about unsaved changes to a protected deck.

Internet Janitor1 year ago(+1)

in v1.15, you can place a deck named "start.deck" in the same directory as the executable of native-decker and it will take precedence over the built-in "guided tour" deck. For details: https://beyondloom.com/decker/decker.html#startup

Xkeeper1 year ago

One thing that love2d (the Lua game framework) does might be useful here; if you append a zip file to the end of the executable, it will run that instead of the built-in default (details: https://love2d.org/wiki/Game_Distribution#Creating_a_Windows_Executable ). Might be similar to the idea of the built-in sample deck.

itch.io

Viewing post in A Couple Suggestions

Native Exports

Lightweight Exports

Lil Function Reference