Reply to Re: YeOldeDink 0.91 Gem Alert
If you don't have an account, just leave the password field blank.
Thanks Kyle! Indeed, transparency should be supported, and there's a basic example of it in action in the previous thread if you download the "testmod" and stand under the tree.
So far, the only major change has been the (live) sprite limit which is 999 like 0.90 was. I haven't investigated changing other things like maximum callbacks or concurrent scripts as of yet, and my policy is to never mess with anything that alters either the map data structure or the save files which means no extra vars unfortunately.
In the case of Lua, however, one has basically infinite vars, and I was going to figure out some sort of serialiser to provide a way to dump/load to disk until I got distracted with the web build. It's definitely on my todo list though, as the existing save/load mechanism is fairly awful.
I've uploaded some more files to the itch page including an updated SkeLuaton to get started with, plus the 0.91 demomod to demonstrate it in action, and have updated the top post with a link to the html edition of the guide. In general though, everything in DinkC is available under the dink table so that playmidi() becomes dink.playmidi() etc. Otherwise, it's still Dink, which means that main() runs on screen load, and hit() when you punch something. At this point it's better to ask specific questions when you get stuck on the syntax or for a snippet for how to do whatever it is, as it's still relatively early days. edit: phoenix types faster than I do.
To drone: yeah I was silly and put some stuff at exit that assumes a clean launch that i'll probably move to the renderer teardown now that you've mentioned it. If I were writing a frontend though, I would have a completely different set of params for Freedink/Yeoldedink, as Seth has his own definition of "refdir", among other things.
So far, the only major change has been the (live) sprite limit which is 999 like 0.90 was. I haven't investigated changing other things like maximum callbacks or concurrent scripts as of yet, and my policy is to never mess with anything that alters either the map data structure or the save files which means no extra vars unfortunately.
In the case of Lua, however, one has basically infinite vars, and I was going to figure out some sort of serialiser to provide a way to dump/load to disk until I got distracted with the web build. It's definitely on my todo list though, as the existing save/load mechanism is fairly awful.
I've uploaded some more files to the itch page including an updated SkeLuaton to get started with, plus the 0.91 demomod to demonstrate it in action, and have updated the top post with a link to the html edition of the guide. In general though, everything in DinkC is available under the dink table so that playmidi() becomes dink.playmidi() etc. Otherwise, it's still Dink, which means that main() runs on screen load, and hit() when you punch something. At this point it's better to ask specific questions when you get stuck on the syntax or for a snippet for how to do whatever it is, as it's still relatively early days. edit: phoenix types faster than I do.
To drone: yeah I was silly and put some stuff at exit that assumes a clean launch that i'll probably move to the renderer teardown now that you've mentioned it. If I were writing a frontend though, I would have a completely different set of params for Freedink/Yeoldedink, as Seth has his own definition of "refdir", among other things.
