Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(2 edits)

Thanks for the fast and thorough response.
Never heard of Q lang (will look into it), but I've spent some time with Lua and that's pretty OK.
While 'Lil' may not be intended to be xTalk-like lang it comes close to reading like one... maybe that's an unavoidable consequence of implementing an HC-like event driven environment?  Its close enough for me and  has the Deck(Stack)/Card metaphor. I like it.  It seem\ to have at least a subset of xTalk, but it also has list and dictionary data types,  custom control widgets / contraptions, and more modern features, so that's super useful!

xTalk has the transient 'It' variable and 'The' (which is largely ignored by interpreter) which can go a long way towards making scripts read more like a natural language sentence. Being English like helps English speaking people, even very young people, learn the language fast,  I know some ECL educators that will swear that xTalk is the best thing for teaching basic concepts. It is certainly what got me hooked as a kid. I also have a theory that straight readability reduces the need for as many code comments. HyperCard 2.0 had some JIT precompiling that helped speed things up, but these days it seems CPUs are fast enough to handle any extra bit of interpretation without much slowdown. 

" C library might be helpful in some situation it would invariably need to be ported to and maintained as JS as well (or vice versa)"
There is the possibility of there being already ported / WASM compiled, small versions of various libraries (ImageMagick for example), but I do understand that you want/need to keep its engine small and as self-contained as possible. But then it also seems a bit pointless to maintain a Desktop app/exe versions at all, since it is still subjected to the same limitations as running sandboxed in a browser.

I think you should at least consider using 'native' file APIs for file stuff. It seems like more work to implement a System 6 file dialog from scratch then to just call out to the OS or HTML5 api. Bug report: in the built in file dialog there's no obvious way to go back up to a parent directory, Command+ArrowUp didn't work, and there's also no way to access my computers other disk partitions.

IMO one of the main things that made HC so  insanely great was its extensibility with XCMDs/XFCNs. While HC couldn't play tracker formats like .s3m, .mod etc. there was an External that could enabled it. I even built MIDI librarian 'app' with HyperMIDI Xternals that could talk to my ancient Yamaha external synth modules back in to day. Lots of stuff most never would have thought you could do with HC. And HC had early polyglot coding, you could mix in AppleScript ( or any other OSA script language), via 'do feild "AppleSciptContainer"as AppleScript' syntax (which later would mean Shell commands too). If your main target is web/html5 then I think it would be great to be able to tap into JS/ HTML5 APIs (and maybe Node for the  desktop version) when the need arises.

Anyway is great fun to play around with,  really nice work so far!

I'll have to spend some time checking out your source later.

I also checked out your web comic. Nice, the art reminded me a bit of Cerebus the Aardvark.

(1 edit)

I'm just reading through those 'responses to responses', which helped me understand the parameters you've set for Decker targeting embedded or extremely limited  and older devices, a noble goal IMO! It then makes more sense to then limit to 16 color palette and 8bit sound samples, but it's still rather harsh constraints by todays standards, maybe even by 1990s standards. I think that limits the possibilities for creativity and may turn off some potential users.

However, THIS is exciting:
"If you know C, it’s fairly straightforward to glue custom functionality into Decker that calls native libraries. Likewise, if you know JavaScript, you could choose to hack up web-decker to expose browser APIs that aren’t normally available to Lil, like the Gamepad API or the ability to perform an XMLHttpRequest. There are lots of inherently “non-portable” features I don’t intend to add to mainline Decker which a given user might still want for a project, and letting them easily add things themselves is what open source is all about. The current version of web-decker is intentionally built without “minification” and doesn’t require anything more than a text editor to make this kind of modification. If it was shipped as an opaque wad of WASM bytecode a whole range of casual tinkering would be off the table and gated behind a complex build process and mandatory tooling."
I may just try my hand at hacking around with a non-mainline Decker, HTML5 APIs access could be a game changer, then one can call whatever WASM compiled modules.  And we can still pack that all up in an Electron app wrapper if we want to. Now I'm wondering if Decker 'Canvas' could be web canvas element, then it could be passed to external (JS) code to draw whatever into it.

And If we could just getting that interpreter to ignore a 'the' token I think that would add just a tad more xTalkishness.

One thing that might be helpful with macOS app version would be to have certain keys in it's info.plist so that it asks permission to use the microphone on newer, more locked down versions of macOS.
Also, when I map .deck files to Decker and then double-click a .deck file in the Finder, Decker opens it in its resource (Font/Res) mover dialog, instead of just opening the clicked Deck file normally. 

For anyone that IS still looking to convert ancient  HyperCard stacks to Decker decks (or any other format), there exists tools like StackImport (CLI) or HyperCardPreview.app, that can convert HC Stacks to JSON and PNG Images representation of a .stack/parts props/backgrounds/Text/Scripts, which should be very helpful compared to straight parsing a .stack (I believe stack used a RIFF like structure).  Also, believe it or not, there are still tools that can read a resource fork (or maybe it's actually the contents of the ._AppleDouble version of a ResFork?) that work on the very latest iterations of macOS (I've tested them myself on 11 BigSur).