The Dink Network

As per the other thread, the newest release of Dink "HD" doesn't work at all in Windows 7. I managed to get it to compile and it's available for download here, with the main new feature being a "quit" button. Extract Dink.exe over the top of your existing install which will be in Appdata somewhere, along with the DLLs and the debugging symbols (I don't know why, but Seth included them too). Use Everything to find it if you cannot. Crappy old MSE claims there's a virus in it, but you can run it through VirusTotal if you're paranoid.

While building it, I managed to get it to use SDL as the audio backend which means greatly improved MIDI playback compared to the standard build which uses an old version of FMOD. To take advantage of this, you must download the Timidity GUS patches and extract them to C:\. Incidentally, if Freedink is installed, the MIDI output will automatically be upgraded for that as well, as it uses SDL2 Mixer by default.
Edit: Built with gamepad support and the debug menu. If it complains about not being able to find xinput1_4.dll, find xinput1_3.dll on your PC, copy and rename it and put it alongside dink.exe with the other DLLs
Edit 2: This should be unnecessary now!

hohoho, a QUIT button? this is the best feature you could've added to dinkhd.

yeoldetoast, damn, I was hoping it would just magically just work on Win 7. Good job doing a fix... I don't supposed you'd be interested in helping me make Dink HD suck less?

I really need help maintaining dink stuff, I'm actually working on fixing the Android version right now (not saving on the latest OS is kind of a big problem) and I'm sure the iOS version will explode soon if I don't update it.

BTW, the debug symbols are included because I have a stack tracer thing inside of Dink that can write useful stuff to the log.txt if a crash happens. Example of what its crash logger looks like:

DINK CRASHED! STACK TRACE BELOW
---------------------------------------------------------
D:\projects\proton\RTDink\source\GUI\AboutMenu.cpp (170): AboutMenuAddScrollContent

D:\projects\proton\RTDink\source\GUI\AboutMenu.cpp (535): AboutMenuCreate

D:\projects\proton\RTDink\source\GUI\MainMenu.cpp (214): MainMenuOnSelect

D:\projects\proton\shared\util\boost\boost\function\function_template.hpp (118): boost: etail::function::void_function_invoker1<void (__cdecl*)(VariantList *),void,VariantList *>::invoke

D:\projects\proton\shared\util\boost\boost\signals\signal_template.hpp (342): boost: ignal1<void,Variant *,boost::last_value<void>,int,std::less<int>,boost::function<void __cdecl(Variant *)> >: perator()

D:\projects\proton\shared\Manager\MessageManager.cpp (268): MessageManager: eliver

D:\projects\proton\shared\Manager\MessageManager.cpp (332): MessageManager::Update

D:\projects\proton\shared\BaseApp.cpp (239): BaseApp::Update

D:\projects\proton\RTDink\source\App.cpp (761): App::Update

D:\projects\proton\shared\win\app\main.cpp (1843): WinMain

d:\a01\_work\38\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl (288): __scrt_common_main_seh

ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 769A6739)

769A6739 (KERNEL32): (filename not available): BaseThreadInitThunk

ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 77CB8E7F)

77CB8E7F (ntdll): (filename not available): RtlGetFullPathName_UEx

ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 77CB8E4D)

77CB8E4D (ntdll): (filename not available): RtlGetFullPathName_UEx

That said, I just found out it didn't work anyway because it never fclosed() or fflushed the log.txt file after a crash exit, oops.

As for as xinput, huh, I guess the nice thing to do with win7 users would be either include it in the installer (if legal and not annoying/big) or somehow dynamically link and disable that part if it's missing (probably better).

Thanks Seth! For reference, the changes I made were fairly simple. First of all I changed the platform toolset for "Release GL" to the VS2017 Windows XP v141 version in VS2022, and then changed XUSER_MAX_COUNT in GamepadProviderXinput.cpp to "4", as that was what it was defined as in the Xinput 1.4 header file. I was also wrong about the DLL-renaming, as compiling it with an older Xinput makes it fall back to 9.1.0 and according to this, the only real drawcard of 1.4 is audio headsets meaning whatever new features are in 1.3 and 1.4 probably aren't used by the input handler at all. Supposedly the Windows 10 SDK can build for 7 by setting WINVER and _WIN32_WINNT in the preprocessor macros but it didn't work for me.

I built with SDL2_Mixer purely because I couldn't get FMod working, and that was by linking to the relevant library in the linker settings, and dragging in the audio handler files and uncommenting the relevant lines in App.cpp. Without the GUS patches, MIDI seems to stutter quite badly and I wouldn't recommend it for normal Windows builds.

The DirectX End-User Runtime Web Installer contains the relevant Xinput dlls, but also attempts to install the Bing toolbar ... It could probably be integrated into the Dink installer and set to run silently somehow, but 9.1.0 and 1.3 DLLs would be present on just about everyone's PCs already anyway, assuming they're using a crusty old PC with an equally decrepit install of W7 with years of updates and various other things installed like I am.

I was thinking of submitting a pull request for the Cmake Linux stuff as that seems a bit neglected, but as for RTDink, i'm not much of a C++ dev at all and barely know what a strcpy is meaning I doubt i'd be of much real assistance with anything of great depth. If I was going to change anything, i'd make it so that the MIDI dls feature is present on Windows too rather than just iOS/Emscripten as that would probably fix the janky fmod output and sound a lot better than the built-in Roland GS. Is there anything particularly major that needs addressing on Windows? How's 64-bit support?

Hey thanks that's very helpful! Ok, I will get a Windows 7 system going and try to do those things and see if I can get my build working Win7 again, it would be mean to leave 12% of people out in the cold if we don't have to.

I know near-zero about the linux CMake stuff so sure, any patches would be appreciated. I doubt Proton resources/samples even build on linux anymore. The guy who wrote those (Aki) has moved on.

I re-did the entire Android build system to get with the times so will be doing a bunch of Proton commits soon for that. (Submitted Mind Wall to the android store today, it's one of my old apps that were de-listed for being old)

64 bit dink works.

Yeah, updating to latest fmod studio and finding a license-friendly dls file might help with audio, mobile versions might be able to benefit there too as it was like uhh.. 12 years ago that I found the current set being used on mobile.

Anyway, I'll go through some old threads and look for other issues I have to fix and then maybe post with a new build and look for feedback.

I should also mention that the platform toolset for Windows XP is an optional install in VS2022 which is marked as deprecated and probably won't be around for much longer, but includes the 7 SDK despite its name, and builds for 7 by default even on 10 (I did most of this in a VM).

And yeah TimGM6MB.dls, according to this site, is GPL despite the author of it saying it's public domain, as it uses GPL samples within. There are a few potential PD replacements such as Chaos at 12MB, and General User GS which is substantially larger at 28MB but sounds really good. On Windows I use CoolSoft VirtualMIDISynth and onestop.mid to test them.

Someone send for help! They appear to be talking in tongues.

Ok, I've done the things discussed and I'm hoping it's about ready to go (for both Windows and Android) but I haven't actually tested on Windows 7... (been procrastinating installing it somewhere)

Anybody out there have a Win7 machine setup? If so, please try this beta build!

https://rtsoft.com/dink/DinkSmallwoodHDInstallerBeta.exe

Will do the real release in a day or two. Android submission soon too.

Here are the changes:

* Should work on Windows 7 again (in theory.. uhh.. )
* Now using HTTPS for all communications/downloads on all platforms
* Download & DMOD install is now much faster
* Windows now using a 64 bit build and latest FMOD Studio version for audio
* BUGFIX: All cheats now properly show up if DinkC Debug Toggle is used from the debug mode (previously, Ghostwalk didn't appear)
* (Android) Fixed issue with Android 11 not being able to save
* (Windows) Running dink.exe with /? or --help will now show a list of possible command line parms
* (Android) Now using FMOD for the sound engine here, now all supported platforms have audio feature parity and should sound the same
* BUGFIX (Android): Installing certain large DMODs will no longer crash due to JNI not being able to garbage collect strings fast enough,
although this bug might be something that only happened on this build due to DMOD install optimizations, not sure
* (Windows) Added note on about screen: "Click and drag to move this window, yeah, this GUI was originally made for mobile so it's weird",
* (Desktop versions) In-game Options menu now shows active dink and DMOD paths, About page shows dink dir and dmod base dir
* Midi improvements - using a new MIDI soundfont ( GeneralUser GS 1.471.sf2, but I converted it to .dls1 as FMOD only supports that) -
I think it's probably better than the default Windows midi player so I went ahead and enabled it for Desktop versions too, but .. I don't know,
I feel like some instruments are a bit loud so maybe someone can suggest/engineer a better .dls file than I did
* DMOD browse menu (showing things you can install) now shows file size

If anybody has any easy-to-do changes they want to get in or knows of a DMOD that won't work, please chime in!

Yeah, I realised just after I posted that only the rather old Fmod EX supports sf2. No idea why they removed it but I'm guessing it's Apple-related. There's Fury.dls which might be okay as I cannot find any copyright info for it. Of course, for whatever reason, there are approximately zero commercial DLS soundfonts out there for situations like these 🤷🏻‍♂️. Unfortunately, Reverie is still broken about halfway through (although sounding far better) suggesting there's most likely a problem in FMOD itself in regards to how it handles MIDI events by refusing to cull old notes. I have a feeling the MIDI file itself has something wrong with it, as I noticed in my SDL2 build that notes in one of the tracks seemed to hang for much longer than expected.

Can confirm that that build works on 7 and 10. I ran it on a rather underpowered Braswell NUC for the latter which ran into a minor issue related to high DPI screen scaling while outputting to a TV. I found that the resolutions in the options don't match up with what's actually displayed, and that attempting to go full screen didn't seem to work properly for either of the fullscreen modes. The IGP supports OpenGL 4.4 and DX12, and the debug log doesn't indicate anything out of the ordinary. I was then greeted by this which may have been from buggering around with screen resolution settings too much. I'm not sure if this is reproducible though and I am not that bothered if it won't be fixed.

More importantly, there seems to be a problem with input handling in which you can't move more than one step at a time with the keyboard after triggering the F1 menu and then returning. I had a DualShock 3 plugged in as well which continued to work fine, but this issue with the keyboard is present on that beta build, my hack build, and the 1.93 build across different PCs so it should be reproducible. You may have to input both keyboard and controller events for it to break though.

haha funny post. now write it in words

Thanks for trying the beta! I think I've got a good idea on how to deal with both of these issues...(DPI scaling and the joystick issue)

That screenshot with the fences in the wrong place... woah, weird, can't think how that could happen. Maybe related to DPI scaling, it can cause some insidious pixel position problems if the app doesn't tell Windows to not mess with it. (recently went through this with a different app, UGT)

The android version is now live (along with two of my other games that were "refreshed") so at least Android 11 people can save the game again, as well as enjoy the beefed up midi.

Yeah the dls+FMOD situation isn't great.. but I do like using the same sound engine everywhere without fuss - Hmm, I couldn't get the fury.dls link to load for me just now, but in any case I'm a little leery of using it without a clear license, just want to avoid any problems down the line.

I'm now working on refreshing some iOS stuff to get them back in the store (I plan to make it all free soon, but that means zero if the games got delisted on android/ios for being old!)

Anyway, will post a new Windows beta here soon.

Ok, new version with the following fixes has been uploaded:

* BUGFIX: Plugged in XInput devices no longer cause dink to stutter while walking if using keyboard to move
* BUGFIX: Fixed some weirdness that happend if DPI scaling is enable

Dink HD Beta Build 4

I'm getting no sound from this beta. Except for MIDI it seems. Can someone reproduce this?

RangerLord: Weird, FMOD should be using whatever the default sound device is. Haven't had that issue here. Maybe the log.txt file has a clue? If you click "About", it should show where the main dink dir is located to find it.

In other news, I found a 25 year old bug that suddenly caused issues on the new Android build, Dink uses strcpy in an unsafe way in a few places, oops! Who knows what weirdness it caused throughout the years, it could cause dinkC commands to lose a few characters.

I'll probably be doing the final (until a new bug is found.. ) Windows release soon.

Thanks for fixing that strcpy bug as I was having trouble with that exact problem when attempting to build on Linux, with various lines completely mangled by the parser. I imagine that when the commits are available on GitHub that it'll run perfectly to the point where i'll be able to upload my build scripts and generate an AppImage, as everything else seems to work just fine.

Also I do get sound on both Windows 7 and 10 with that build, with DPI scaling and input behaving as expected. Hurrah.

Okay, I discovered the reason. Apparently using the default install location caused it. Could be some issue with my Windows. Wish my SSD wasn't full of games so I could do a completely clean install and test it.

Cool, yeah I'll github everything up soon. The bug was in strip_beginning_spaces, if the dest and src in a strcpy overlapped, certain implementations explode apparently.

The fix I did was just force it to use my own version there:

char *strcpy_safe(char *dest, const char* src)
{
char *ret = dest;
while (*dest++ = *src++)
;
return ret;
}

Ok, as for dink, I've released 1.95 for Windows:

Dink Smallwood HD 1.95

People running the older version will get notified at startup.

Big thanks for the help!