The Dink Network

Made a new thread as the old one was outdated and getting cluttered. YeOldeDink is a fork of Freedink with bugfixes and an expanded feature-set including PNG support, a rewritten audio backend, and Phoenix's DinkLua scripting backend. For a full list of features and differences, please see the guide linked below.

This thread is for complaints, abuse, feature requests, soliciting assistance with DinkLua, and other such similar topics. As mentioned at the end of the previous thread, releases are now being placed on itch.io. The changelog is in the post below this one.

Download YeOldeDink 0.91 on itch.io
Online guide

A minor update for 0.90 and another general release with some important changes for gamepad enjoyers.

Bugfixes:
* The Lua/DinkC consoles would occasionally crash for various reasons.
* Various bugfixes for DinkLua.

New:
* The on-screen joystick should work properly with touch devices and is enabled in the relevant window. Activate it by touching on one part of the screen and then dragging in the direction you'd like to move.
* Along with the touch joystick are touch swipe gestures for some of the other controls, with the amount of fingers able to be set.
* Pressing Start + Select/Back may be used to instantly exit
* A fake keyboard key may be assigned to the left shoulder (L1) to run the corresponding key script.
* A callback viewer.
* DinkC bindings list.
* A fairly minimal special frame viewer.
* AppImages will automatically copy the ancillary data to ~/.config upon first launch if there's nothing there.
* Web builds allow you to export your save files as a zip from the file menu.
* The amount of audio channels may be specified in yedink.ini such as 1 for mono or 8 for a 7.1 system.

Changes:
* The sprite sorting algo is set in the debug menu, existing one used by default. Newer one only recommended if you're having performance problems.
* The floating info window shows the amount of vars and callbacks in use rather than that moveman stuff, and has some conveniences added.
* The ability to display 24-bit graphics while in 8-bit mode so they look like utter crap is back.
* The script window allows you to input the filename of a script for it to be executed while attached to sprite 1000. Will run main().
* The "gamepad and joystick" window has been renamed to "gamepad and touch".
* The gamepad backend has been rewritten some more to improve device autodetection, with controller input ignored for movement etc when debug mode is on.
* Debug mode may be switched on by pressing in the left stick clicker (L3), and switched off with the right (R3).
* Live changes you make to MIDI settings for the next MIDI in the audio window are visibly apparent.
* DinkLua: dink.get_truecolor() returns a bool rather than 1 or 0.
* Phoenix has updated the dinklua environment setup file to work better with Lua 5.4!

Removals:
* The help in the help menu.
* L1 will no longer run the button7 script as nobody seems to have ever used it.
* Compile-time CPU-specific optimisations.
* Some of the bundled typefaces

Notes on touch controls:
* Touch controls require your 2-in-1 tablet or whatever to send touch messages to SDL2 rather than mouse events. Some unfortunately send both.
* You may also need to switch off multi-finger gestures in your desktop environment as usually they will interfere. Even then it probably won't work too great and I don't recommend its use.

Web build:
* If you'd like your d-mod packaged up into an easily-accessible web build to place on itch.io, now's the time to ask!

Known issues:
* System MIDI output will not work for this release unless you recompile with standard SDL Mixer. It may return in a later release. Apologies to CoolSoft or Roland MT-32 users out there, but this is a library limitation meaning you'll have to contend with FluidSynth or TiMIDIty or one of the other 3 backends instead for now.
* AppImages don't bundle Gnome's libGLib meaning you'll have to install it yourself if you somehow don't already have it.

Reserved for future use

By the way, kind of half Martridge related, but I figured I'd post here since it's kind of a YeOldeDink bug report rather:

Since DinkHD added the new "-skip" argument, I added that to Martridge, but it seems that when launching FreeDink and YeOldeDink with the "-skip" argument, they just crash.

YeOldeDink gives a process exit code "-1073741819", I think that's 0xC0000005, which Microsoft says means: "A C0000005 error is memory error. Specifically, a C0000005 error is an access violation error caused by a buffer overrun."

This happens with any unrecognized arguments. So I suppose you should look into whatever's going on with argument processing?

Edit: Should mention I tried this with the v0.91 release too.

First time I discover this. Looks like a gem! Two questions:
- Does the png support include transparency?
- Are the hardcoded limits of the original Dink like those on sequence slots, sprites on screen and active variables still in place? And if not, did it have an effect on the save and map data format?

I'm actually really interested in trying out the Lua language with this. I noticed that the docs on the wiki of the 2014 repository link to a page with a function list, but it's empty. Is there more up to data information anywhere?

I intend to eventually make a "DinkLua Reference" in the same vein as the DinkC reference, but depression is a rough mistress and is keeping me from making progress on anything right now. ?

Best I can do for you at the moment is my WIP translation of the original Dink game from DinkC into DinkLua which you can find at https://github.com/ilyvion/dinklua. While it was meant as notes for me and not really the general public, there's a file called notes.txt in there that at least goes into what I intend to go into once I get around to the documentation part. ? More importantly, though, this repository of script files should let you check out how to accomplish "the same thing" in DinkLua as you would in DinkC for a given script from the original game. (I'm roughly up to Windemere in terms of translation progress through the game.)

In general though, functions that in DinkC are foo(...) will be dink.foo(...) in DinkLua, unless they operate on sprites, in which case sp_foo(sprite_number, ...) becomes sprite_object:foo(...). Most of these differences should be pretty well documented in the Wiki you mentioned. So if you can look something up in the DinkC reference, and read that Wiki entry for any differences, you should be able to figure out how to do something.

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.

@Kyle:

A bit of "shameless self shilling" here, but if you want to develop some DMOD with PNGs, my forked version of WinDinkEditPlus supports PNG sprites: https://www.dinknetwork.com/file/windinkedit_plus_2_drone_edition/

I should also mention that DinkHD supports PNGs just fine too, not only YeOldeDink.

A DMOD that properly uses PNGs would be interesting to see!

*shames anyway for neglecting tiles!*

I've tentatively rigged up a serialisation system using Serpent. In the final release, saving to disk will look something like:

mytable = {"A", "b", "C"}
dink.todisk(mytable, "mytable.dat")

Which will save the table alongside the usual savefiles to mytable.dat. Loading would be similarly accomplished by:

mytable = dink.fromdisk("mytable.dat")
-- Say A
player ay(mytable[1])

Unlike the inbuilt save/load it doesn't assume anything else, which means you could rig up your own savebot and continue scripts to account for both normal and Lua saves, and write a custom packer. Lua allows for nested tables which means in theory you could store almost whatever you wanted in the one file.

sound_set_vol doesn't work properly in YeOldeDink. After you decrease a certain amount, it starts increasing instead, so you can't quieten the sounds to as low of a level as in Dink 1.08 and FreeDink. DinkHD seems to have the same bug, which I've already messaged Seth about.

Thanks, I'll get a patch release for that out soon. DinkC SFX volume control is pretty awful due to it being encumbered by old DirectSound leftovers. Unlike every other audio library which uses volumes from 0 to 100, or 0.0 to 1.0, with values above that used for amplification, DirectSound goes from -10,000 to 0 where 0 is normal volume and -10,000 is silence. I must admit that when I redid those calculations, I was trying to copy Seth!

@Yeoldetoast

Any chance to make dinks sp_speed value able to be reliably retrieved using sp_speed(1, -1)?

DinkHD is the only dink engine it works in. All other engines return the correct value most of the time but can randomly retrieve some other multiple of dinks current sp_speed equivelant.

You can test this on a loop, when dinks speed is normal, which should return 3 when doing sp_speed(1, -1):

loop:
 wait(0);
 int &check = sp_speed(1, -1);
 if (&check != 3)
 { 
  say("&check", 1);
 }
 goto loop;
}

hold tab and run around, he'll randomly say 6, and sometimes 12.

I can't seem to reliably reproduce other than by deliberately inducing an FPS drop such as by changing screens or losing window focus. This might have to be one of those longer-term things on the to-do list that might not be ready for the next release.

Unfortunately I can't set up a hack in which set_dink_speed() may return dinkspeed, as -1 is used as a legitimate value. It is rather dumb it can't be retrieved though.

Yeh supposed to just be able to retrieve the sp_speed equivalent, but for me, it does have the chance to return another value... With that loop above if I hold tab and run around, it shows a different value quite a bit. Try changing dinks speed to fast and changing the loop to check for sp_speed 6 instead of 3. (6 is fast), you might reproduce it easier... It seems the faster dink is the more often it returns random incorrect values, at least in my testing.

Dinkspeed is the internal variable that is altered by set_dink_speed() which is fed into the calculation for final player sprite speed. Incidentally the DinkC reference has a minor error, the calculated minimum sprite speed value for dinkspeed set to 1 is 12 rather than 9.

I've rigged up my own monitoring system, and after considering the output and glancing at the 1.08 source, I can only assume it's supposed to be like this as a compensatory mechanism for occasional FPS stutters such as when loading graphics or audio so as to ensure smooth player movement. Seth rewrote the rendering backend for RTDink which explains the discrepancy, so I probably will not change this, but may add some sort of debug menu option for it along with a way to get dinkspeed.

Incidentally, this is probably the source of the crash that occurred when using Ultimate Cheat with movement speed set to maximum back in the day.

> Incidentally the DinkC reference has a minor error, the calculated minimum sprite speed value for dinkspeed set to 1 is 12 rather than 9.
I'll fix that in the reference now.

> I probably will not change this, but may add some sort of debug menu option for it along with a way to get dinkspeed.
Awesome, a reliable way to get dink speed is what I'm after. If another command is introduced in yeolde that gets speed, at least authors can just do a get_client_fork to check whether player is in HD or Yeolde, and either do sp_speed(1, -1), or <whatever yeoldes new command for getting speed is>. As for the other engines, I won't bother checking, I think people should only be using Yeolde or HD these days. The rest are buggy or outdated.

For something that works in all engines, how does getting the absolute value of mx and my end up? It seems to be a stable non-fluctuating value that only changes when walking diagonally.

> For something that works in all engines, how does getting the absolute value of mx and my end up? It seems to be a stable non-fluctuating value that only changes when walking diagonally.

Works perfectly, nice find, I should have thought of that. Just gotta account for the diagonals.
The below works in every engine, I just made it into an external function for simplicity.

void get_dink_speed(void)
{
 //get dink sp_speed equivelant
 int &get_dink_speed;
 &get_dink_speed = sp_mx(1, -1);
 if (&get_dink_speed == 0)
 {
  &get_dink_speed = sp_my(1, -1);
 }

 &get_dink_speed = math_abs(&get_dink_speed);
 if (&get_dink_speed == 2)
 {
  &get_dink_speed = 3;
 }
 if (&get_dink_speed == 4)
 {
  &get_dink_speed = 6;
 }
 if (&get_dink_speed == 8)
 {
  &get_dink_speed = 12;
 }
 return(&get_dink_speed);
}