YeOldeDink 0.94: bugfix edition
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, bug reports, 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 most recent release is 0.94 released 7/24 with the changelog two posts below this one.
Download YeOldeDink 0.94 for Windows, GNU/Linux, or macOS on itch.io
Online guide
DinkLua Object Reference
Dink table/namespace reference (WIP)
Learn Lua in 15 minutes
This thread is for complaints, bug reports, 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 most recent release is 0.94 released 7/24 with the changelog two posts below this one.
Download YeOldeDink 0.94 for Windows, GNU/Linux, or macOS on itch.io
Online guide
DinkLua Object Reference
Dink table/namespace reference (WIP)
Learn Lua in 15 minutes
0.93 released 6/24
Some more additions to DinkLua, plus some new debug mode options for more easily seeing things, along with the usual slew of minor changes. Most importantly for standard users, the "M" key works again.
You will need to overwrite yedink.ini or perhaps delete ~/.config/yeoldedink on GNU/Linux due to the addition of a text editor setting.
New:
* In the debug menu is the Auto-pause submenu so you can see expanded hardboxes and whatever else more easily as they occur.
* Talk and push boxes may be viewed.
* Blood, carcasses, and damage indicator text may also be switched off.
* Under the "hacks" submenu is an option for proper hitbox expansion for direction 8, on by default.
* 20 extra tilesheets, up to ts61 should be okay.
* Making more than one global function should behave as per intended spec rather than overwriting the previous one.
* Damage/experience text is set to nohit by default, as is the sequence 164 explosion for pigs and ducks, plus duck heads.
Changes and/or bugfixes:
* The variables window shows all local vars in use, rather than just globals.
* The M, 6-0 keys work again. button7 has been sacrificed for controller binding for now.
* "Lock player speed variability" has been renamed slightly and includes locking the movement speed of other sprites such as missiles to an assumed 60fps rate or thereabouts.
* The various debug mode polygon types are able to be switched on and off individually and have different colours so as to more easily distinguish between them. Hitboxes are a sort of mushy grey, missile boxes are orange, talkboxes are green, pushboxes yellow, while touchboxes remain the traditional pink.
* The comprehensive sprite viewer shows the calculated distance for a sprite set to follow or target another.
* Pausing will more properly pause the internal timers as well, meaning fewer dragon attacks and other weird stuff compared to using the inventory for the same purpose.
* The "Editor overrides" window has been renamed to "Save data" and includes tile screens and global functions.
* Using playsound with a frequency of zero with a random variance value will adjust the speed as a percentage instead. For example dink.playsound(1, 0, 5) will apply a 1-5% variance to the duck quack.
DinkLua:
* All hard-coded sound effect slots and playback rates may be altered. Please see the object reference in the top post for more info.
Technical changes:
* Updated Dear ImGui
Known issues:
* The map warper may cause a crash on occasion.
* Save durations may be wrong.
Some more additions to DinkLua, plus some new debug mode options for more easily seeing things, along with the usual slew of minor changes. Most importantly for standard users, the "M" key works again.
You will need to overwrite yedink.ini or perhaps delete ~/.config/yeoldedink on GNU/Linux due to the addition of a text editor setting.
New:
* In the debug menu is the Auto-pause submenu so you can see expanded hardboxes and whatever else more easily as they occur.
* Talk and push boxes may be viewed.
* Blood, carcasses, and damage indicator text may also be switched off.
* Under the "hacks" submenu is an option for proper hitbox expansion for direction 8, on by default.
* 20 extra tilesheets, up to ts61 should be okay.
* Making more than one global function should behave as per intended spec rather than overwriting the previous one.
* Damage/experience text is set to nohit by default, as is the sequence 164 explosion for pigs and ducks, plus duck heads.
Changes and/or bugfixes:
* The variables window shows all local vars in use, rather than just globals.
* The M, 6-0 keys work again. button7 has been sacrificed for controller binding for now.
* "Lock player speed variability" has been renamed slightly and includes locking the movement speed of other sprites such as missiles to an assumed 60fps rate or thereabouts.
* The various debug mode polygon types are able to be switched on and off individually and have different colours so as to more easily distinguish between them. Hitboxes are a sort of mushy grey, missile boxes are orange, talkboxes are green, pushboxes yellow, while touchboxes remain the traditional pink.
* The comprehensive sprite viewer shows the calculated distance for a sprite set to follow or target another.
* Pausing will more properly pause the internal timers as well, meaning fewer dragon attacks and other weird stuff compared to using the inventory for the same purpose.
* The "Editor overrides" window has been renamed to "Save data" and includes tile screens and global functions.
* Using playsound with a frequency of zero with a random variance value will adjust the speed as a percentage instead. For example dink.playsound(1, 0, 5) will apply a 1-5% variance to the duck quack.
DinkLua:
* All hard-coded sound effect slots and playback rates may be altered. Please see the object reference in the top post for more info.
Technical changes:
* Updated Dear ImGui
Known issues:
* The map warper may cause a crash on occasion.
* Save durations may be wrong.
Released 7/24. A minor patch release with some bugfixes and various additions for jam entries. Big thanks to SimonK for alerting me to some of these.
New:
* Expanded sprite script fields (~50 characters) for easier script sorting (thanks drone1400).
Changes/bugfixes:
* Count_magic/item counts properly (thanks seseler)
* The map warper should no longer cause a crash on occasion.
* The main window will automatically rise to the front upon launch so you can see the loading screen more easily on some operating systems.
* Upped sequences to allow for 99 frames.
* The alternate text display will no longer cause a crash upon encountering empty text.
* Damage and experience will display with alttext on.
* Ducks no longer change to direction 10 on occasion.
Technical changes:
* Updated Dear ImGui and some audio libraries.
New:
* Expanded sprite script fields (~50 characters) for easier script sorting (thanks drone1400).
Changes/bugfixes:
* Count_magic/item counts properly (thanks seseler)
* The map warper should no longer cause a crash on occasion.
* The main window will automatically rise to the front upon launch so you can see the loading screen more easily on some operating systems.
* Upped sequences to allow for 99 frames.
* The alternate text display will no longer cause a crash upon encountering empty text.
* Damage and experience will display with alttext on.
* Ducks no longer change to direction 10 on occasion.
Technical changes:
* Updated Dear ImGui and some audio libraries.
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.
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?
- 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.
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.
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!
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:
Which will save the table alongside the usual savefiles to mytable.dat. Loading would be similarly accomplished by:
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.
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):
hold tab and run around, he'll randomly say 6, and sometimes 12.
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.
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.
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.
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.
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);
}
Just started to use this version 0.92 of the engine, and it is pretty spectacular, especially the debug stuff!
What it lets you see on screen, with log files, scripts in use, sprite slots available/not used, frame rates running, hard.dat overlay. I couldn't get it to do what DinkHD does with the hardboxes of sprites being displayed, but maybe that's an option in a menu I haven't activated yet.
Nice one!
What it lets you see on screen, with log files, scripts in use, sprite slots available/not used, frame rates running, hard.dat overlay. I couldn't get it to do what DinkHD does with the hardboxes of sprites being displayed, but maybe that's an option in a menu I haven't activated yet.
Nice one!
Thanks! It's under the debug menu, called something vague like "show pink squares". It's also possible to view individual sprite sequence properties in the live sprite editor under the "dink.ini" tab, although this doesn't display the expansion that occurs when stuff gets hit. I've been avoiding a lot of graphical stuff in general but will attempt to overhaul some of it for the next release.
Released 4/24. 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.
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.
Is there a page with a list of all the functions for DinkLua, like the DinkC functions list?
Hmmm, button7 - I tried getting buttons 7 to 9 work via iPad on DinkHD with no joy just renaming scripts button7.c etc. Would these work with YeOldeDink as is if I paired my steelseries nimbus to my PC?
7.1 sound.... nice. Going to have to play with that. Is it just if you have sound files in a surround format, or can you assign any mono sound to a discrete channel(s) via lua?
7.1 sound.... nice. Going to have to play with that. Is it just if you have sound files in a surround format, or can you assign any mono sound to a discrete channel(s) via lua?
To RobJ: There isn't one as of yet, just a few paragraphs in the guide, as it's mostly redundant due to pretty much everything having the same name and purpose as in in DinkC, e.g. get_time_real() is dink.get_time_real(). The main differences are documented in the object reference (just updated), and as usual if there's something i've missed or that's confusing, don't hesitate to ask for an example of use.
Most lacking in real documentation are Phoenix's helper libraries (the things loaded with "include") although there are some notes in the comments. If one is starting out, I would not recommend trying to use them, as they're not required for use, and have a fairly steep learning curve if you're not accustomed to them.
To SimonK: None of the button* scripts will work with the controller for the time being, but will work with the keyboard (except for 7). I was going to bind them to the right stick directions, but removed the feature at the last minute for 0.93.
Instead, L1 binding works similarly to what you were suggesting in the other thread. i.e. the player can bind L1 to any keyboard script key from the gamepad settings window, which makes it equivalent to pressing that key. Unfortunately I don't plan on delving into Android/iOS any time soon.
I haven't actually tested anything greater than stereo audio as I got rid of my Logitech surround setup a few years ago due to it often picking up 2GB and 702 because of terrible shielding. In theory, it should mean that sprites that have a positional sound effect playing will have proper panning per number of speakers and player position, which is scripting-language independent. There are no proper surround audio mixing features unfortunately, and all manual SFX panning settings are just stereo for now. I may look at the possibility of expanding it in the future.
The amount of channels the audio backends were initialised with will be near the top of debug.txt if you start with debug mode on, and could be tested by placing a sprite in a lower corner of the screen with some looping audio attached and then listening to the rear speakers. Surround audio files in FLAC (such as these) should also work with playmidi() but are similarly untested.
Most lacking in real documentation are Phoenix's helper libraries (the things loaded with "include") although there are some notes in the comments. If one is starting out, I would not recommend trying to use them, as they're not required for use, and have a fairly steep learning curve if you're not accustomed to them.
To SimonK: None of the button* scripts will work with the controller for the time being, but will work with the keyboard (except for 7). I was going to bind them to the right stick directions, but removed the feature at the last minute for 0.93.
Instead, L1 binding works similarly to what you were suggesting in the other thread. i.e. the player can bind L1 to any keyboard script key from the gamepad settings window, which makes it equivalent to pressing that key. Unfortunately I don't plan on delving into Android/iOS any time soon.
I haven't actually tested anything greater than stereo audio as I got rid of my Logitech surround setup a few years ago due to it often picking up 2GB and 702 because of terrible shielding. In theory, it should mean that sprites that have a positional sound effect playing will have proper panning per number of speakers and player position, which is scripting-language independent. There are no proper surround audio mixing features unfortunately, and all manual SFX panning settings are just stereo for now. I may look at the possibility of expanding it in the future.
The amount of channels the audio backends were initialised with will be near the top of debug.txt if you start with debug mode on, and could be tested by placing a sprite in a lower corner of the screen with some looping audio attached and then listening to the rear speakers. Surround audio files in FLAC (such as these) should also work with playmidi() but are similarly untested.
I think DinkLua is broken in 0.93?
Tried loading the bare skeleton, it doesn't get past the splash screen, but if I roll back to previous YeOldeDink version it works fine.
Tried loading the bare skeleton, it doesn't get past the splash screen, but if I roll back to previous YeOldeDink version it works fine.
It seems I forgot a necessary file. I've updated the Windows releases on the itch page, and i'll get around to the appimage eventually. Alternately, it's feasible to copy the "libraries" folder from the previous release's ancillary data and place it next to the new one.
Okay then. I look forward to the AppImage.
0.92 released 5/24
A patch release has turned into a full release with some minor bugfixes and user conveniences once again recommended for all.
Bugfixes:
* Command line segfault (thanks drone1400)
* Made enable/disable_all_sprites() affect all living sprites (thanks Robj)
* Improved bounds-checking for SFX playback slots
* Cursor would get stuck on title screens with debug mode on
* There were some leftover sprite limits in brains that assumed a maximum of 300.
New:
* A comprehensive live sprite info viewer which lists almost every sprite attribute including hidden ones
* A font and text window for testing initfont and altering text colours.
* Screenshots may be made from the "display" menu or by pressing Alt+S which are saved to "screenshot.png" in dmodpath.
* Alt+P will pause and resume, and may be automated upon focus loss under the "display" menu. Pausing will also properly affect BGM and SFX.
* An SFX viewer. This differs to the audio window and shows you which sound slots are in use and offers a preview at native freq.
* The tile window has a painter that will fill the screen's tiles with the entirety of a 600x400 tilesheet.
* The inbuilt cheat contains an instant map warp along with a few other things.
* A "Dink" colour scheme may be applied to the UI from the display menu.
* Atk/def/magic stats above 999 have the thousandths column visible
* "Lock player speed variability" under the speed menu will switch off player sprite speed compensation that occurs due to FPS fluctuations. (thanks robj)
* Incredibly slow speed option will run at 1/10th of normal speed
* get_dinkspeed() will return internal "dinkspeed" value.
* Using fast/slow modes will affect music tempo and SFX.
* There is a tab for viewing engine vars in the "variables" window.
* Tooltips are available under the help menu. Not everything has tooltips yet.
New in DinkLua:
* Serialisation is available with dink.todisk(mytable, filename) and back again with local mytable = dink.fromdisk("filename") in which filename is in the root of dmodpath.
* dink.get_cheat() returns a bool to check for the use of the cheat window.
* dink.copy_to_clipboard(string) will copy the specified string to the clipboard.
* player.get_speed will provide the internal "dinkspeed" value used for calculating the player sprite's walk speed.
* dink.playmidi() accepts an optional fade-in value. dink.playmidi("1.mid", 9000) will fade in Ave Maria over 9 seconds.
* dink.fade_out_music(int time) does something similar.
Changes:
* Messed with sound_set_vol calculations again so they hopefully match olde Dink.
* Alt+H toggles properly now
* Alternate text boxes option has been fleshed out a bit more and moved to the "display" menu. Please see notes below.
* Doubled loadable sound slots to 200
* Bumped up maximum sequences to 1500, sprite info entries to 2000, max sprites (in dink.ini) to 6000, concurrent scripts to 400 and callbacks to 200. This may break something, but so far I haven't noticed anything.
* The system information window contains a list of these limits.
* The console is also visible outside of debug mode, mostly to warn the user, and may be tabbed to if not in focus.
* User settings will only be autosaved if one ventures beyond the title screen before exiting.
* The default log level is saved to user settings when altered.
* The sprite editor and list feature punch-selection.
* Timing is 64-bit throughout just in case.
Technical changes
* Improved (maybe) static/shared library linking rules for various operating systems when compiling.
Removals:
* Smooth shadows
Notes:
* Setting sound vol to -1000 is equivalent 50% attenuation which more or less matches the statement in the DinkC reference of "-1000 is about half-volume". It can also be amplified, and setting it to 1000 is equivalent to 200%.
* Alternate text display is for when the author has used Seth's fancy "multiple colours in text" feature such as in "Evolving Magic" which might be the first to do so. It will not work with initfont, or in full-screen/maximised window mode very well, and won't display while debug mode is on.
* Big thanks to gokussj6 (I think) for editing the PCGamingWiki. Apologies in advance if I should change the URL
* There will be no more arm64 appimages
A patch release has turned into a full release with some minor bugfixes and user conveniences once again recommended for all.
Bugfixes:
* Command line segfault (thanks drone1400)
* Made enable/disable_all_sprites() affect all living sprites (thanks Robj)
* Improved bounds-checking for SFX playback slots
* Cursor would get stuck on title screens with debug mode on
* There were some leftover sprite limits in brains that assumed a maximum of 300.
New:
* A comprehensive live sprite info viewer which lists almost every sprite attribute including hidden ones
* A font and text window for testing initfont and altering text colours.
* Screenshots may be made from the "display" menu or by pressing Alt+S which are saved to "screenshot.png" in dmodpath.
* Alt+P will pause and resume, and may be automated upon focus loss under the "display" menu. Pausing will also properly affect BGM and SFX.
* An SFX viewer. This differs to the audio window and shows you which sound slots are in use and offers a preview at native freq.
* The tile window has a painter that will fill the screen's tiles with the entirety of a 600x400 tilesheet.
* The inbuilt cheat contains an instant map warp along with a few other things.
* A "Dink" colour scheme may be applied to the UI from the display menu.
* Atk/def/magic stats above 999 have the thousandths column visible
* "Lock player speed variability" under the speed menu will switch off player sprite speed compensation that occurs due to FPS fluctuations. (thanks robj)
* Incredibly slow speed option will run at 1/10th of normal speed
* get_dinkspeed() will return internal "dinkspeed" value.
* Using fast/slow modes will affect music tempo and SFX.
* There is a tab for viewing engine vars in the "variables" window.
* Tooltips are available under the help menu. Not everything has tooltips yet.
New in DinkLua:
* Serialisation is available with dink.todisk(mytable, filename) and back again with local mytable = dink.fromdisk("filename") in which filename is in the root of dmodpath.
* dink.get_cheat() returns a bool to check for the use of the cheat window.
* dink.copy_to_clipboard(string) will copy the specified string to the clipboard.
* player.get_speed will provide the internal "dinkspeed" value used for calculating the player sprite's walk speed.
* dink.playmidi() accepts an optional fade-in value. dink.playmidi("1.mid", 9000) will fade in Ave Maria over 9 seconds.
* dink.fade_out_music(int time) does something similar.
Changes:
* Messed with sound_set_vol calculations again so they hopefully match olde Dink.
* Alt+H toggles properly now
* Alternate text boxes option has been fleshed out a bit more and moved to the "display" menu. Please see notes below.
* Doubled loadable sound slots to 200
* Bumped up maximum sequences to 1500, sprite info entries to 2000, max sprites (in dink.ini) to 6000, concurrent scripts to 400 and callbacks to 200. This may break something, but so far I haven't noticed anything.
* The system information window contains a list of these limits.
* The console is also visible outside of debug mode, mostly to warn the user, and may be tabbed to if not in focus.
* User settings will only be autosaved if one ventures beyond the title screen before exiting.
* The default log level is saved to user settings when altered.
* The sprite editor and list feature punch-selection.
* Timing is 64-bit throughout just in case.
Technical changes
* Improved (maybe) static/shared library linking rules for various operating systems when compiling.
Removals:
* Smooth shadows
Notes:
* Setting sound vol to -1000 is equivalent 50% attenuation which more or less matches the statement in the DinkC reference of "-1000 is about half-volume". It can also be amplified, and setting it to 1000 is equivalent to 200%.
* Alternate text display is for when the author has used Seth's fancy "multiple colours in text" feature such as in "Evolving Magic" which might be the first to do so. It will not work with initfont, or in full-screen/maximised window mode very well, and won't display while debug mode is on.
* Big thanks to gokussj6 (I think) for editing the PCGamingWiki. Apologies in advance if I should change the URL
* There will be no more arm64 appimages
YeoldeDink is surpassing DinkHD.
Unless Seth is planning to also fix/add some of the stuff YeDink has already to keep it on even playing field, I'll have to use get_fork() to force YeDink in my Dmods from now on since they won't be compatible with HD!
Unless Seth is planning to also fix/add some of the stuff YeDink has already to keep it on even playing field, I'll have to use get_fork() to force YeDink in my Dmods from now on since they won't be compatible with HD!
Just you wait. 0.95 is going to have a very special feature courtesy of drone1400. There's a plan in the works to jump to a completely new map data format.
testing some YOD 0.94 stuff with hack n' slash
The alternate text boxes do show multiple text colours but not the same colours as DinkHD, and seems to add either a line feed or return character (or equivalent) before each new colour change. Just tested this line
say_stop_xy("`%YEOLDEDINK may not show `0text `9in correct colours.", -200, 260);
The alternate text boxes do show multiple text colours but not the same colours as DinkHD, and seems to add either a line feed or return character (or equivalent) before each new colour change. Just tested this line
say_stop_xy("`%YEOLDEDINK may not show `0text `9in correct colours.", -200, 260);
I'm having a look at the colours and they seem to coincide with the DinkC reference. Percentage is white, 0 is bright green, and 9 is sky blue which is what i'm seeing.
The string tokeniser sucks, and overall the feature was never intended to be used by anyone, but i've been meaning to rewrite some of it anyway.
The string tokeniser sucks, and overall the feature was never intended to be used by anyone, but i've been meaning to rewrite some of it anyway.
Yes, you're right, but what DinkHD does, and I don't know if it is just an accident, but it changes the colours from that reference listing when you use multiple colours in one piece of text. They are a lot darker and richer.
For example using
say("`1 `4Your time will come soon enough.", ¤t_sprite);
Turns the text into a deep red
and this turns Mony's dialogue a nice deep pink/purple
I discovered this by accident on SOB Redux when doing the matrons reacting to the Immaculatus Conceptus magic, not sure if anyone else had made use of it before. It saves having to define a new colour for any of the standard `1 thru `0, `# etc.
For example using
say("`1 `4Your time will come soon enough.", ¤t_sprite);
Turns the text into a deep red
and this turns Mony's dialogue a nice deep pink/purple
I discovered this by accident on SOB Redux when doing the matrons reacting to the Immaculatus Conceptus magic, not sure if anyone else had made use of it before. It saves having to define a new colour for any of the standard `1 thru `0, `# etc.
Thanks for those examples. After digging through the RTDink source, as well as a bit of Proton, I can't seem to figure out what sort of algorithm is applied for text colour blending.
I initially tested the feature using Evolving Magic, which uses it a fair bit on the starting screen.
For any sort of consistent cross-engine colour, it's going to have to be done the old-fasioned way with set_font_color for the time being.
I initially tested the feature using Evolving Magic, which uses it a fair bit on the starting screen.
For any sort of consistent cross-engine colour, it's going to have to be done the old-fasioned way with set_font_color for the time being.
There's been some discussion on Discord about why is YeOldeDink not on Github or uploaded directly on Dink Nwtwork.
Do you want to comment on it, Toast?
Do you want to comment on it, Toast?
github is awful, just put it on the dn.
The main reason why I have settled on itch for the time being is because it allows for hosting multiple builds, including web builds, on a single page with a blog feature and a text description meaning people can check it out immediately and see if it's for them or not. I don't need any of the features that GitHub etc provides, and very rarely do I receive questions/feedback regarding the source tarballs.
I do not like the prospect of uploading to this site either, as yedink is still under development and considered unfinished. The small iterative changes I make would take potentially up to a week or more to get approved, rather than going live almost immediately when necessary.
I do not like the prospect of uploading to this site either, as yedink is still under development and considered unfinished. The small iterative changes I make would take potentially up to a week or more to get approved, rather than going live almost immediately when necessary.
"The main reason why I have settled on itch for the time being is because it allows for hosting multiple builds, including web builds, on a single page with a blog feature and a text description meaning people can check it out immediately and see if it's for them or not. I don't need any of the features that GitHub etc provides, and very rarely do I receive questions/feedback regarding the source tarballs."
Yeah so funny thing about that, GitHub allows you to make a page dedicated to this project, as well as uploading multiple builds which can bee seen in this example right in Assets section.
Majority of projects such as source ports will always use GitHub because its features are far more convenient when it comes to maintaining the project compared to itch.io as people can follow the progress by looking at the commits that have been pushed into it and if an issue pops up GH allows you to keep things much more clean and if someone wants to contribute to the project people can send a merge request into it.
and finally people can test out the recent main branch before the release by cloning it and compiling or just set up an action where the github itself will compile it and give out the nightly build in runnable form for those who do not know how to compile.
Alternatively GitLab also lets you do the same thing in case ya want to avoid Microsoft.
Yeah so funny thing about that, GitHub allows you to make a page dedicated to this project, as well as uploading multiple builds which can bee seen in this example right in Assets section.
Majority of projects such as source ports will always use GitHub because its features are far more convenient when it comes to maintaining the project compared to itch.io as people can follow the progress by looking at the commits that have been pushed into it and if an issue pops up GH allows you to keep things much more clean and if someone wants to contribute to the project people can send a merge request into it.
and finally people can test out the recent main branch before the release by cloning it and compiling or just set up an action where the github itself will compile it and give out the nightly build in runnable form for those who do not know how to compile.
Alternatively GitLab also lets you do the same thing in case ya want to avoid Microsoft.
I'm well aware of that, but all of that is irrelevant. Despite Martridge and WDED being hosted on conventional source tree sites neither have received a single pull request or issue in the issue tracker despite both being far more popular than Yedink is, assuming the download count on here is accurate. Generally I only bother with commits at release time anyway meaning the master branch would be identical to the current tarballs.
Using GitHub for Martridge is convenient because of the CI/CD stuff. (Also GitHub is the place for .NET open source projects). I can just push a version tag and it makes the release binaries automagically! And by automagically I mean after I fiddled with the damned config file for days... But hey it works! Until I want to update something in the CI/CD configuration... And it takes me half a day to fix it again.
As for GitLab, I'm using it since RW published there and I forked it. Although I don't have the WIP stuff of WDE24 uploaded there yet...
As for GitLab, I'm using it since RW published there and I forked it. Although I don't have the WIP stuff of WDE24 uploaded there yet...
