The Dink Network

Starting a new thread for this topic in order to not pollute the other thread(s) with this issue.

I have uploaded a simple build script for Debian based distributions to my
repository.

It successfully builds and installs freedink-109.6 on Devuan. Instructions are in the README file.

I would be interested if it also works for other Linux users with Debian based distros.

PS: Be sure to download the *.tar.gz bundle.

The current FreeDink maintainer started a thread and we kind of started posting bug reports there already

https://www.dinknetwork.com/forum.cgi?MID=207892#207892

EDIT: Huh, I had never heard of codeberg... Interesting, although I only started using github recently too.

The current FreeDink maintainer started a thread and we kind of started posting bug reports there already

Well, yes, but when a new freedink release gets out then the Linux users will have to wait until their distribution picks it up, which may not even happen until the next version of the distro is released. The build script is meant as a temporary "quickfix", it installs the fixed version in /opt, without interfering with the version provided by their distro.
I think discussing possible issues of a temporary solution in other threads may take too much focus.

PS: Just saw your list in the other thread about additional possible long/int issues. Will check it out and see if additional patches may be required.

Check out the "----------- Timing variables, need to be Uint32, possible issues? ----" section especially. It has some stuff about variables used for timekeeping. Some of those are long, but they interact with some variables which are declared Uint32. Basically, this shouldn't cause any issues on x64 compilation, but it might cause issues on x86, since then you are using 32 bit integers, and comparing/storing values of variables defined as uint32, so you might get some weird things happening. Although that would probably only happen if you ran the game long enough for the system timer to go beyond 2^31...

Alright, I went through and had a look at that soundbank number bug in the assumption it was related to that pole problem, and I found that by changing

int soundbank = channel + 1;

to

int soundbank = channel;

in sfx.cpp on line 984 (or just returning channel) that I was able to punch the pole with no ill effect. It also cleared up a long-standing problem with Mystery Island with the sound effect not looping during the camera sequence. I haven't tested this much further so it may have broken something else further along. Also, be aware that it also breaks Robj's version checker which works by looking for this bug so you'll have to edit his vcheck.c after recompiling.

Edit: This is all wrong and the problem is still occurring, but at least it fixed something.
Edit2: It seems to be the MIDI! Can someone else confirm that removing MIDI 38 (Lovin') from the screen in Freedinkedit rectifies this?

"Also, be aware that it also breaks Robj's version checker which works by looking for this bug so you'll have to edit his vcheck.c after recompiling."

If someone fixes the FreeDink soundbank number bug, I can edit version checker to prompt the player for their version anyway. Better to have all the bugs fixed, tbh.

Alas, now my inventory is full of pineapples!

Alright, I downloaded General User GS, renamed it to "gugs.sf2" and stuck it in my home dir. I then added the line

Mix_SetSoundFonts("~/gugs.sf2");

to sfx.cpp near where all the commented-out stuff pertaining to SDL_setenv is. After recompiling and going back to through the warp screen, I found that it worked fine. Setting the SoundFont manually like this makes SDL2_Mixer use FluidSynth as a rendering backend for MIDIs rather than Timidity. Supposedly you can set the SDL_SOUNDFONTS environment variable to have the same effect as this change, but it didn't do anything for me.

"Alas, now my inventory is full of pineapples!"
That'll teach you!

The patches got unmanagable, so the latest bugfixes are now available from my repository. It is best build with the latest version of the build script.

Bugs that have been squashed so far:

- Bug in input.cpp for SDL2 version 2.0.10 and later

- Fixed overlapping memory when using strcpy()

- Incompatible type long for array that stores function arguments

- Fixed configure.ac so that freedink can be build with latest autotools (Linux only)

- Spamming of unrelated 'Surface doesn't have a colorkey' is now a thing of the past.

There have been some further improvements to the logging mechanism. This - at least for now - is only interesting for developers of the freedink source.

Here is an excerpt of the related git commit message:

    The logging mechanism now supports three log levels that control the
    verbosity. However, those levels are only available in the DEBUG version.
    The DEBUG version can be built by defining CXXFLAGS=-DDEBUGB.
    The log levels can only be set if freedink is started on the CLI. The
    -d flag can be passed multiple times, where every time the log level is
    incremented by 1.
    The log levels are range from 0 (default, -d flag not passed) to 3 (-d
    flag passed three times on CLI).
    
    Log level 0: Only errors will be logged.
    Log level 1: Debug messages will be logged.
    Log level 2: Execution paths are traced, verbose messages from SDL are
                 omitted.
    Log level 3: All verbose messages are included, SDL included.
    
    Log levels > 1 are intended for debugging the freedink engine,
    they are not useful for dinkc coders. Those log levels inflate logfiles
    quite quickly within a few seconds, so they should be used carefully.

I have also added a new Bash script in contrib/log-format.sh, it indents the logfile that makes it easier to trace the execution paths of the new log functions.

@yeoldetoast I, too, came to the conclusion that the freeze issue is probably related to the midi interpreter used. I will try to use different midi players and see if this sorts out the issue.

As for the soundbank problem, I saw that, too, in the code. The problem is that freedink stores it in a 0-based array and dinkc uses a 1 one based array (?). The source tries to compensate for that TWICE in file sfx.cpp. The first time is in function
SoundPlayEffectChannel()

    return channel + 1;

The returned value is then incremented a second time in playsound(). I am currently in the process of determining the best way to handle this, since the error condition (return value of '0') seems to get ignored.

@robj I am cautiously optimistic that the days of this bug are numbered. However, I do not know how comfortable you are building freedink on windows and I do not have a windows system. So I will not be able to provide any help on how to build freedink on windows.

- Spamming of unrelated 'Surface doesn't have a colorkey' is now a thing of the past.

Holy DDC that's amazing!

Although there is one thing I'm confused about. What's the default log level if you don't build with CXXFLAGS=-DDEBUGB ? I assume you can pass the -debug argument and have it work as intended for dmod debugging (aka, at level 1)?

Supposedly you can set the SDL_SOUNDFONTS environment variable to have the same effect as this change, but it didn't do anything for me.

SDL_FORCE_SOUNDFONTS=1 is also required to enforce the soundfont. When using

SDL_FORCE_SOUNDFONTS=1 SDL_SOUNDFONTS=~/gugs.sf2 /opt/freedink -w -t ...

fluidsynth does not complain about failing to load soundfont 'FluidR3Mono_GM.sf3'. This suggests that fluidsynth is used to play the midis. The game still crashes, though. I do not know why setting

Mix_SetSoundFonts("~/gugs.sf2");

in sfx.cpp prevents the crash. Maybe it configures it differently?

Although there is one thing I'm confused about. What's the default log level if you don't build with CXXFLAGS=-DDEBUG

A release version only has log level 0 (default, only ERROR messages are logged, I may change that to log INFO messages) and level 1 (normal debug for dinkc coders, without the spam) available.

There are some serious monkeyshines going on in SDL_mixer. I compiled with

Mix_SetSoundFonts("~/gugs.sf2");

as suggested by yeoldetoast and it worked. Then I rebuild with

Mix_SetSoundFonts("/usr/share/sounds/sf2/FluidR3_GM.sf2");

That is the path to the soundfonts installed by my distro. It did not work. More curious is the fact, that I then recompiled with

Mix_SetSoundFonts("~/void");

That soundfont does not exist, as the name suggests, and it still worked.

I also find that setting SDL_FORCE_SOUNDFONTS and SDL_SOUNDFONTS to something results in a segfault when any MIDI is attempted to be played back! In the log, it complains that one must Mix_SetMusicCMD() first to specify an external playback command. Unfortunately, SDL_Mixer is so poorly documented that one must trawl through the source to figure out what's going on. I wouldn't have expected it to need an external command at all, and that it would instead use Fluidsynth internally...

It appears that SDL_Mixer will automatically opt for FluidR3 when attempting to use SoundFonts and it can't find the user-specified path which may explain why it worked anyway in your case, but at this point, I don't really know what's going on and can only assume that SoundFont playback is broken. I attempted to use an acapella soundfont for testing, as it's very evident when it's in use but couldn't get anything out of it other than a crash. I now understand why Seth uses FMOD

Ideally we'd link against SDL Mixer X instead, as it features several very configurable MIDI playback engines, and is much better documented overall. I tested SDL_Mixer's playmus.c test program "./playmus "38.mid|s4" with those two envs and it sounded as expected, and allowed me to change soundfont at will.

For Windows builds, back in the good old days, Beuc would use mingw32 to compile them, and there is some outdated documentation pertaining to this in docs/cross.txt. I do have MSYS2 working on my Win7 PC though so I'll attempt to compile a Windows exe on there at some point.

>A release version only has log level 0 (default, only ERROR messages are logged, I may change that to log INFO messages) and level 1 (normal debug for dinkc coders, without the spam) available.

Makes sense, thanks!

Also I have a most dumbass question. Since I'm not familiar with GPL, I was wondering if it is even allowed to compile something under GPL using MSVC. I couldn't find much info except this https://opensource.stackexchange.com/questions/7182/redistributing-msvc-runtime-components-with-gpl-application

Which makes it seem like technically you can, you just can't redistribute the MSVC itself since it's not open source, which makes it useless as far as an end user would be concerned. So I suppose your only option on Windows would be using MinGW?... Sounds like quite a hassle.

Your compiler has no bearing upon the license of your program, and the inverse also applies. The implications would be horrendous if that weren't the case. I'm using MSYS2/Mingw64 because autotools is capable of generating Windows builds with it fairly straightforwardly and is already set up. I wouldn't even attempt otherwise.

Unfortunately my progress so far hasn't been without a few hiccups... I don't think it's happening any time soon.

>Your compiler has no bearing upon the license of your program, and the inverse also applies.
I'm not so sure about that... The GNU GPL FAQ seems to think otherwise in certain circumstances. https://www.gnu.org/licenses/gpl-faq.html#WindowsRuntimeAndGPL

You may not distribute these libraries in compiled DLL form with the program. (It refers to the MSVC libraries)

So from what I can gather, that would include the MSVC redist installers too?...

So as far as I can understand, you'd be free to compile a GPL program with MSVC, and distribute the software, but not the MSVC redist itself. You would have to tell the users to go get that themselves. Which is a major pain in the butt so you'd be better off just using MinGW in the first place to avoid such issues.

PS: What the heck is even going on in that pic, how the heck is it mirrored and flipped?!

Libraries and compilers are two different things and I don't know why you're conflating them. Even Mingw has to link to Windows system libraries to produce a working exe. It's also fairly common to nag the user to install various runtimes, including for non-free software.

Speaking of which, I have no idea why my MSYS2 builds on Windows didn't work properly, but it turns out that Beuc was using MXE to compile them anyway. There's some leftover shell scripts along with a few Dockerfiles in "autobuild" that demonstrate the process, but the MXE tutorial explains more than enough. I couldn't get ghostknight's repo to compile this way so I had to copy the source files into the existing 109.6 snapshot before running make. I suspect we're dealing with some sort of autotools deprecation between versions which I hope somebody else can figure out. I should also let you know, ghostknight, your repo worked fine on macOS with Clang and also Ubuntu Mate Jammy Jellyfish as a normal build without having to move files around.

If any Windows users are interested, here it is for testing. It should be able to be dropped alongside your existing freedink.exe and launched the usual way. This build also fixes the soundbank number bug which ghostknight erred against due to the risk of unforeseen consequences, but I am of the belief it should be fine.

"If any Windows users are interested, here it is for testing. It should be able to be dropped alongside your existing freedink.exe and launched the usual way. This build also fixes the soundbank number bug which ghostknight erred against due to the risk of unforeseen consequences, but I am of the belief it should be fine."

This should be fine to test with Charlie too without breaking sounds. Every script that kills sounds in Charlie uses a check to see if freedink 109.6 is in use before it subtracts 1 from the soundbank. Since this fix removes the sound bug, the 109.6 check will fail (since it uses that discrepency to check that version), and the -1 will never happen. Also, with a fixed version of FreeDink, I don't think there will be a way for me to differntiate between vanilla 1.08 and FreeDink 109.6. But the reason I created vcheck in the first place was so people could check for this and isolate certain sections in scripting to counteract the bugs. If it's fixed, it probably doesn't even need updating.. or if an official fixed version gets released I might update it one more time to block out the broken version.

Older versions of FreeDink were easy to check, their default sp_custom value when not set would be -1, rather than "0" like other versions, so I just checked a null key on a created sprite for that.

Although with a completely fixed version of FreeDink available, the ability to differentiate between it and 1.08 would be lost, you can force crash Dink 1.08 and FreeDink 108.4 by doing: sp_custom("null", 1, -1); (null can be anything). Trying to retrieve a sp_custom key on Dink in anything earlier than FreeDink 109.6 or the latest official build of DinkHD, will crash the game. So you can force players out of vanilla 1.08, but it won't be a prompt, it'll be a crash.

>Libraries and compilers are two different things and I don't know why you're conflating them. Even Mingw has to link to Windows system libraries to produce a working exe. It's also fairly common to nag the user to install various runtimes, including for non-free software.

MSVC may be a compiler, but it uses Microsoft's proprietary MSVC libraries when compiling. Now depending on what version you are using, you might need to install the redistributables. According to the GNU GPL website's FAQ (which I linked in the previous post), you can't redistribute the MSVC DLLs with a GPL project. I *ASSUME* that this refers to MSVC redist installer exe too.

MinGW may link Windows system libraries too, but from what I've read and understood, it uses some generic version of the libraries rather than a specific one that a user would have to install separately. So it wouldn't cause any issues with GPL since you wouldn't have to redistribute the windows libraries to the user.

Of course, this would be the case for MSVC as well if you get it to compile with the same generic libraries instead of some specific version, but I have no idea if you can do that, since this was never something I even considered before.

But anyway, I'm going way offtopic here, sorry ghostknight!

"Also, with a fixed version of FreeDink, I don't think there will be a way for me to differntiate between vanilla 1.08 and FreeDink 109.6"

Scrap that. I just scripted a way, and tested it, confirmed working. It's now differentiating between vanilla 1.08, freedink 108.4, freedink 109.6 on windows(whether sound is enabled or not), freedink 109.6 on linux, DinkHD old versions, and DinkHD new version.
I used an internal timer discrepency, detecting a 31 millisecond difference in the time it takes an invisible sprite to move from one side of the screen to the other when sp_speed is set to 100.
In order of priority (so it detects without crashing)
1. Check get_version. "If > 110" it's dinkhd, "if < 111" its old dinkhd, else its new dinkhd.

2. "if == 108", check value on a null key, "if nullkey < 0" its old Freedink version(108.4 or lower). Else, it's 1.08 or FreeDink 109.6.

3. Get the player to press F2 (F2 is key-113.c on vaniall 1.08, and key-59.c on FreeDink 109.6).

4. Use discrpency with &args to detect linux freedink 109.6 (&arg4-&arg8 DO NOT clear, they act as globals.. &arg1-&arg3 work properly, however).
external("null", "null", 0, 0, 0, 99);, then another external to check if &arg4 cleared or not.
"if &arg4 > 0" its linux freedink 109.6. Else it's Windows FreeDink 109.6.

FIN. I will update vcheck one last time, soonish, with this stuff. That means a when a new version comes out, I can do a step 5 with the soundbank test, to also check between 109.6, and new fixed version as well.

Back on topic now. I too apologise for these off topics.

EDIT: I changed step 3 to keystroke of pressing 'F2'. It's more reliable.

I have made some further updates to the
freedink buildscript

and the
freedink (branch versioninfo) source

itself. The build script currently only works with the version in branch 'versioninfo'. I will get back to that later.

Along some minor bugfixes, there are two important changes. The first involves the soundbank bug. As written earlier, the problem is that the function 'SoundPlayEffectChannel()' already returns the value for the soundbank but 'playsound()' erroneously increments it again. After studying the source only found two locations where the return value of 'SoundPlayEffectChannel()' is used. First, in 'playsound()' and then in the file 'brain_pig.cpp', function 'pig_brain()':

if (!playing(spr[h].last_sound)) spr[h].last_sound = 0;

if (spr[h].last_sound == 0)
{
  if (hold == 1) 
    spr[h].last_sound = SoundPlayEffect( 2,junk, 800 ,h,0);
  if (hold == 2) 
    spr[h].last_sound = SoundPlayEffect( 3,junk, 800,h ,0);
  if (hold == 3) 
    spr[h].last_sound = SoundPlayEffect( 4,junk, 800 ,h,0);
  if (hold == 4) 
    spr[h].last_sound = SoundPlayEffect( 5,junk, 800,h,0 );

This clearly indicates that 'spr[h].last_sound' is supposed to hold a soundbank and not the channel, since 0 indicates the absence of a sound.

In conclusion, I agree with yeoldetoast's initial assessment, that not incrementing the value in 'playsound()' fixes the problem without any adverse side effects.

The second major change involves version checking. I was a bit surprised through how many hoops robj had to jump in order to identify the dink version. Therefore, I am proposing two new DinkC functions that shall make version identification a lot easier in the future:

- get_version_minor()
- get_fork()

Suppose you have freedink version 109.6. Your only chance to "identify" it is to call 'get_version()'. This, however, will return 108.
In the future, a call to get_version() shall return the correct major version number, e.g., the latest (development) version in my repository is 110.1. A call to 'get_version()' will return 110. An additional call to 'get_version_minor()' will return 1.

As I read in robj's earlier post, he indentifies dinkhd by the major version number, i.e., if the value from 'get_version()' is greater or equal than 110 then it is dinkhd. If freedink advances to major version 110 and beyond this would cause problems. This is where the fork number comes into play. By calling 'get_fork()' the exact fork/platform version would be identified, e.g., freedink will return 100.

Here is an excerpt of the corresponding commit message.

The following numbering convention for forks is proposed:

- fork numbers from 1 to 99 are reserved forks/sequels by the original
  creator(s), i.e., RTSoft, Seth Robinson
- fork numbers from 100 and higher can be chosen for forks by a
  3rd party, starting with 100 for freedink.

That is, *IF* Seth agrees that those additions are worthwhile. But even if not, at least the freedink versions should be easier to identify in the future.

PS:

I also find that setting SDL_FORCE_SOUNDFONTS and SDL_SOUNDFONTS to something results in a segfault when any MIDI is attempted to be played back!


I have never experienced this when setting those variables in Bash. I am using SDL2 2.0.9 and SDL2_mixer 2.0.4. Which are your version?

One thing I would note, is that it seems from this thread https://www.dinknetwork.com/forum.cgi?MID=207925#207973
...that Seth is using get_version to refer to the DinkC version, rather than a game version. I'm not sure if you mean the same thing by it?

Also, I don't know how useful a get_version_minor would be to DMOD developers. What would be the use cases for this? How many DMOD developers would work around specific game subversions? Ideally, those minor versions should be identical to the major versions in terms of command availability...

I do think get_fork sounds useful though, to distinguish future FreeDink and other possible ports that might appear. Although I would've named it something like get_engine_id

I don't think this would really solve any of the existing problems of distinguishing the original 1.08 from FreeDink 109.6 (Original Beuc Edition) though... This whole version business just seems to get more and more complicated doesn't it?

I proposed something like this to Beuc some years ago, but he was always reluctant to implement it for reasons that are more obvious to me now. His goal with Freedink was always to emulate v1.08 perfectly to the point where D-mod developers wouldn't need a "get_freedink()" command to work around extant bugs or differences in behaviour, and that those would be slowly ironed out with each new release.

At this point, I would wager that the average amount of people still using 1.08 in complete ignorance is nil, and that nobody who still downloads and plays d-mods is in a position where they're still regularly using it with Windows XP as they have for the last 15 years with the expectation that new d-mod releases will work on it as they have in the past (except for Skorn being contrarian). Therefore at present and into the future, a call to get_version() with a return value of 108 is much more of an indication that the player is using Freedink than 1.08.

The main reason I am strongly against incrementing get_version() in Freedink or a fork, however, is because there are numerous d-mods that completely refuse to run if it returns >=109 due to the reputation of Dink "HD" having appalling compatibility with various DinkC techniques that the author didn't want to have to bother working around. Changing this would break a huge amount of them released in the last ten years without good reason, unless you were to implement it in a command line switch like 1.07 mode is.

If you're determined to implement something like this, I would suggest bringing across the two existing (documented) DinkC functions that are present in 1.09 and later that have never been used by anyone. Making get_platform() return 7 would be a way to determine that the user is definitely using Freedink, and for get_client_version() return the same sort of thing you would have used for get_fork().

In terms of SDL2, i'm using 2.0.10 and for Mixer also 2.0.4. My assumption is that if it's still crashing on that specific screen for you, and the MIDIs sound no different, then those environment variables aren't changing anything. In my case I set them with "export" in a standard Bash session.

Did many authors actually do a check for DinkHD using get_version and lock the dmod out? I didn't think many did.. Also if they did, wouldn't be hard to patch those dmods no that DinkHD has been brought up to speed and remove those DinkHD lockouts.. I doubt there's be many.

DinkHD already has a command to get the client version "get_client_version()", so yes "get_version" gets the DinkC version (which in the latest build is "111"), but get_client_version gets the build number ("197" in the latest DinkHD release).

As for Version Checker, I'm going back to barebones, and retiring any future updates. It will use get_version to get 108, 110(with an additional check of get_client_version >= 197), and I will include sections for authors to automatically run it with custom prompts. It's still useful this way all in one script.

I will then include sections that, rather than checking for versions, check if the &arg bug and soundbank bug is currently present. So you will simply use external to call the procedure, and &return will give you the result of which bugs are currently present in whatever engine the player is using.. An author can then check for these at anytime and adjust scripts to work around these issues (they are both easy to create alternate scripts to make them work). Only time I will do updates (after this next one I will be releasing soon), is if any other game altering bugs come up in any future releases, which I will also add a procedure for(same as &arg and soundbank bugs).

I agree that a generic way to get the fork and version would be good for future builds. In all new versions I'll make:

get_client_fork() return 1 (dink HD, freedink could be 2?)

and as mentioned, Dink HD already has

get_client_version() for the client version.

maybe freedink could add both those?

Dink HD also has get_platform() which might be useful if two builds have the same version but a bug is only found on iPhone or something.

just for reference, the values it returns are:

PLATFORM_ID_UNKNOWN = -1,
PLATFORM_ID_WINDOWS, // 0
PLATFORM_ID_IOS, //iPhone/iPad etc // 1
PLATFORM_ID_OSX, //2
PLATFORM_ID_LINUX, //3, and so on
PLATFORM_ID_ANDROID,
PLATFORM_ID_WINDOWS_MOBILE,
PLATFORM_ID_WEBOS,
PLATFORM_ID_BBX, //RIM Playbook
PLATFORM_ID_FLASH,
PLATFORM_ID_HTML5, //javascript output via emscripten for web
PLATFORM_ID_PSVITA

>Did many authors actually do a check for DinkHD using get_version and lock the dmod out?

I'm aware that iplaydink's Bloop the Fish remake does so, along with all of its derivatives released as part of that contest. This brings the known total so far to 4, but my assumption is that there are at least a few others. There may also be d-mods released much further back (since 2006) that explicitly check for get_version() being 108 which would refuse to run for no good reason if get_version() is incremented in Freedink or a fork like ghostknight is proposing. In my view, it would cause great inconvenience without any apparent benefit.

Wouldn't be hard to download the dmods, search and replace get_version to change it to >= 108.

And slowly patch those dmods. Shouldn't be too many. Only thing is, you can't upload a new version for someone elses dmod, I found that out a few months back when I actually started fixing known problems in a few dmods, and I had to pester Dan and send him the dmod files everytime I wanted one updated(cause they aren't mine). Which I get, you don't want other ppl to have free access to change someone else's dmod. Makes fixing them more difficult to do.

In my latest Vcheck is a external function that can be called.
external("vcheck", "soundbug");
if (&return == 1)
{
//soundbank needs subtracting by 1
&soundbank -= 1;
}

I added that everywhere to Charlie, where it's needed. So it'll only take effect on the version that has the soundbank error.
Yeoldetoast, an easy solution to certain midi's crashing (I found 77.mid crashes as well on Linux FreeDink) is to just convert them to the ".ogg" format, theres a free online converter, and ogg works on DinkHD too.

Obviously the best solution is an official release that fixes the latest FreeDink version, but this is just for authors that want to work around this stuff in case players are using these versions.

I also fixed all the other problems in Charlie's Legacy(using DinkC) that were occuring on Linux, by filling out all the external calls with 0's for the unspecified arguments, rather than leaving them blank. &arg1-3 work normally. &arg4-8 will not pass 0's when unspecified, they pass the last known value for that argument number.