The Dink Network

This is a fork of Ghostknight's repo with a few extra features added, intended for developers and those who want to understand the engine better (edit: or cheat more effectively). After Ghostknight went to the effort to update the logging mechanism, I felt it was wasted on the existing debug interface so I made my own with Dear Imgui.

Edit: scroll to the bottom for the latest Windows and GNU/Linux builds.

Improvements are as follows:
A completely updated debug interface with a visible log and the ability for people to make their own additions,
Improved PNG support without having to do any filename rejigging or sprite resizing,
Turned off some of the annoying mouse capture options,
The OpenGL renderer is inaccessible in favour of the "software" renderer,
get_client_fork() is implemented as per Seth's recommendation and returns 3

Pitfalls and gotchas:
8-bit mode won't work at all,
The editor won't build and will throw linker errors because I didn't do the makefile properly,
The executable it outputs is still called "freedink" so don't do "make install" unless you want to overwrite,
No Windows release unless someone really wants one,
the tile surface isn't cleared upon the screen reloading meaning transparent tiles will overlay upon the previous screen's tiles like in the screenshot,

Screenshot 1
Screenshot 2

All the relevant widgets are exposed in debug_imgui.cpp in case you want to add your own features. My dev platform is macOS, but I also gave it some minor testing on Ubuntu, which worked fine. Compilation should be the usual "./bootstrap", "./configure", and "make" sequence. You may have to run "make distclean" or something if it doesn't build, I don't know. Archive here, apologies for no git.

Dang, amazing job with this. Is there any plans in expanding it further, as well as switch from old and janky autoconf into CMake?

This seems quite amazing!

I would be interested in windows release, since I'm mainly a windows user. I imagine RobJ would be too, but perhaps I shouldn't speak on his behalf haha.

Gokussj: I looked into moving the build system to Meson, but the whole transition process from Autotools would be above my current skill level and inclination. Ideally, i'd want to remove the Gnulib integration at the same time, but that's probably its own nightmare so I'm hesitant for the time being.

I did also look into making a thing for rebinding the joystick buttons but haven't fully implemented it yet. The keyboard keys are pretty much hard-coded so I wouldn't want to touch those at this stage.

drone: I did manage to get an MSYS2 Mingw64 Windows build finished that I'll upload soon. Unfortunately, for whatever reason, the "software" renderer looks terrible on Windows compared to macOS and GNU/Linux, and the build crashes upon exit despite not doing so on any other system. I couldn't get a proper debugging environment set up on there to figure out what was wrong so I won't be able to diagnose Windows-specific issues if any arise. GCC on MSYS2 (and perhaps Arch) appears to have some quirks that don't present themselves elsewhere.

Btw, one debug window suggestion I would have for future improvements, would be to have a list of the currently active scripts on screen. I imagine that would be very useful for dmod debugging.

Windows build. Somehow I managed to get it so that Imgui looks as it does on other systems, but sound effects stutter terribly, and it still crashes upon exit. I also had to include a lot of dlls, so it's best if you unzip it to its own location and run it on the command line or perhaps with Martridge if it supports arbitrary paths and --refdir. Be warned!

I put an active script counter in the "ultimate cheat" window for this build, and will attempt an x64 AppImage and new source tarball in a bit.

Other potential additions at the moment include the ability to turn off those pink squares, as well as improve the DinkC Console window so it has basic command history and a submit button, and also flesh out the ultimate cheat window a bit more.

Wow! You actually did it that fast?!

I got it to run by either copying the "dink" folder inside, or launching it with Martridge... Weird thing is, if i launch it normally without any command line parameters, it goes fullscreen and i can't click on anything, but if i launch the base dink game with Matridge it works fine even without debug mode enabled...

Martridge config example screenshot
PS: Ignore the duplicate dmods in matrtridge it seems to be a bug that i thought i fixed but uh, apparently i didn't in the version i launched?

The custom arguments option came in handy

Unfortunately, most dmods don't seem to render the menu / title screen correctly at all for me...
This is what happens if i launch Charlie's Legacy for example: screenshot

FB2 launches the menu correctly, but if i load anything, it seems none of the tiles get drawn:
screenshot of the menu
screenshot of the game

The Dear Imgui syntax is very straightforward meaning scrip names are almost finished too. It looks like you forgot the -t flag. I haven't stubbed out 8-bit mode yet so it's still required for the time being. I also don't recommend launching in full-screen mode as it occasionally has performance issues that don't present themselves when starting windowed and then maximising.

Oh! You are correct! That was it!

Edit: Oh, I found out why I couldn't click things fullscreen. It seems, due to the aspect ratio being different, the cursor positions get fugged. I think without the -t flag the cursor image wasn't rendering. The windows cursor position that interacts with the Dear Imgui elements is in one place, and the in-game cursor is in a different place. When you keep it in windowed mode at 4:3 it's fine.

But this is so weird... It probably has to do with how freedink itself handles cursor tracking... When i move the winodws cursor way to the right, the in-game cursor gets clamped to the right. You'd expect it to move left immediately as i move left, but no, I have to move the cursor about halfway on the screen until the in-game cursor starts moving left!

Edit2: I found a bug you might be interested in. If i put some Dear Imgui window behind the "Debug mode enabled" info overlay, and accidentally click on the overlay, it goes on top over the window and i can't click the window at all anymore. It seems it resolves itself if i toggle debug mode on and off though.

PS: I had another suggestion i forgot to mention, a hardness view toggle would probably be useful too. Something like alt-h, toggling drawing the hardness like in the editor.

>how freedink itself handles cursor tracking

Yeah, the engine uses relative mouse positioning for mouse mode which I've messed around with, but I tend to use the keyboard or joystick there due to it being in use for roughly 3 seconds, after which you're using the keyboard or joystick anyway. Unless someone really wants to make a sequel to Agathain Sea Traders or Dink Mines using this, I won't change anything.

>i can't click the window at all anymore

The transparent info window can have its position changed to other corners of the screen by right-clicking it. In a worst-case scenario, you may have to edit imgui.ini manually with new screen coordinates.

>a hardness view toggle

Done! Will be in an upcoming release.

>Done! Will be in an upcoming release.
Man, you work fast! How do we vote you into taking over the official freedink repo, lmao.

Yeoldetoast and Ghostknight, you two are the real Freedink MVPs this year!

wait, yeah, why arent you

At that point I may as well learn French fluently and take over Beuc's entire life

The next release may be a little while. Things are changing rapidly.

I like what I'm seeing

0.2 update:
In addition to the aforementioned:
- Got rid of some windows and moved things into the menu bar
- 8-bit mode is now inaccessible
- Added sprite, variable, and script info viewers
- Moved the DinkC console into the floating info window and the log
- Added the option to pause while the console is active, and also display a warning
- The game itself is now viewable in a separate window (yo dawg)
- The main renderer can now be switched off too, along with the pink squares and some other things
- Expanded "Ultimate Cheat" and the log window a bit more
- Added a "map viewer" window indicating which screen you're on
- Added quick save/load (slot 1337)

Archive, plus Windows build. I also took the hint and looked at that FB2 map bug but it's out of my depth, unfortunately.

Coming in 0.3:

- Added sysinfo window
- Expanded audio control window
- added a slow mode
- added controller rumble when hurt
- pressing Tab increases speed only in normal mode
- Added a speed menu to debug mode
- Added "play_mod_order(int order)" to DinkC allowing basic tracker module control. Requires SDL Mixer 2.6 and up.
- SoundFonts also seem to work now, at least on macOS.

I've also turned my interest to YeoldeDinkEdit, or Yedit for short, which will have the same sort of interface, as well as PNG support. So far I have managed to squash a few bugs relating to being unable to place sprites or tiles properly if you should happen to create your own MAP.DAT from scratch(er) with an empty file. Will probably get a release when it has enough features. Please list your current FreeDinkEdit gripes below if you should have any.

Screenshot 1
Screenshot 2

I think a useful thing for a YeoldeDinkEdit, if possible, would be to (optionally) render adjacent screens so you can see how sprites align between screens. But that might be rather complicated to implement?... I don't suppose you can just call a screen rendering function to some canvas using just different screen ids, hah.

>I don't suppose you can just call a screen rendering function to some canvas using just different screen ids, hah.

It was the first thing I tried! Only to find out that the backend renderer is designed for loading/displaying one screen at a time . For certain stuff I'm using the temporary buffers for the screen transition, and I may be able to hack something together with the minimap preview thing if I can eventually figure it out. The FreeDinkEdit source is basically the original DinkEdit with various SDL replacements for DirectDraw meaning it's mostly still a mess of nested if-statements and occasional use of "goto".

Why not work with making a new version of the more versatile Windinkeditplus2 instead of the original DinkEdit?

@SlipDink
Oh, speaking of that, there is a slight hope that RW might release the source code for it. I managed to get in contact with him a few months ago but, he has to find it first, although he said he should still have it somewhere... Currently waiting for another reply.

>Why not work with making a new version of the more versatile Windinkeditplus2

1. As has been mentioned above, the source isn't available.
2. Even if it was, I wouldn't bother. The WDE source is a mess in other ways, mainly due to being Windows-only.
3. Beuc attempted a LinDinkEdit port years ago which never reached a functional state.
4. My general dislike of WDE is well-known.
5. The minor things holding back FDE that would make a big difference such as sprite property editing and default nohit etc should be straightforward to implement.

Edit: 6. Now that RW has ported the rendering backend of WDE2+ to SDL2, it might be feasible to strip away all the Windows-specific MFC stuff and replace its functionality with ImGui.My brief investigations have yielded positive results in that regard, but I don't know how it would be in practice. My wheels are already in motion with Freedink/edit, however, and I don't really have the inclination to attempt such a thing.

Not sure why but all the sound effects stutter/lag when I use the windows build of yeoldedink. Music is fine, it's only sound effects. Probably a issue only on my end but I can't figure it out. FreeDink doesn't do it.

Don't worry, it's a known issue in SDL Mixer on Windows at the moment! I've recompiled using a newer version of Mixer, and SFX sound as they should on my end once again, although some people are still reporting that the stuttering may be Windows 11-specific.

Changelog:
- As above plus,
- MP3 audio precedence for the one d-mod that uses it (Prelude)
- The bug mentioned in the WDE2+ thread has been rectified meaning hard.dat tiles for tile screen 41 will now load and overlay as expected

On the topic of AppImages, I can't generate them due to stuffing up the makefile. If any GNU/Linux users need assistance with compiling, don't hesitate to ask.

Yeoldedink 0.3 for Windows with included datadir for those who don't want to stuff around with --refdir
0.3 for Windows with just exe and dlls
Sores arechive for compiling yourself

This will probably be the final release unless someone recommends a specific feature, or there's a major bug somewhere that reveals itself tomorrow (again).

I'll give it a whirl on the weekend and see if i run into any bugs...

Speaking of bugs, I had another look at this one. The relevant lines are in game_engine.cpp in game_load_screen(), and are as follows:

int game_load_screen(int mapdat_num) {
	if (g_dmod.map.ts_loc_mem[mapdat_num] != NULL) {
           memcpy(&cur_ed_screen, g_dmod.map.ts_loc_mem[mapdat_num], sizeof(struct editor_screen));
        else if (load_screen_to(g_dmod.map.map_dat.c_str(), mapdat_num, &cur_ed_screen) < 0)

In terms of data:
- mapdat_num refers to the screen number in map.dat that is to be loaded
- g_dmod.map is the struct that holds Dink.dat (the screen index etc)
- cur_ed_screen is the map.dat screen data in memory that you end up seeing after a redraw

The most pertinent of what's in there is ts_loc_mem[769], which is an array of the same data type as cur_ed_screen, i.e. it holds map screens in RAM. It seems to only be used for the test suite and is never modified anywhere else, meaning that for normal use, the "else if" executes instead since all values in ts_loc_mem are empty. In FB2 and other d-mods with large amounts of screens where the author decided to use MapNuke, there's the eventual problem where DinkEdit makes more than 768 screens, as MapNuke doesn't actually remove anything, and only zeroes the reference in Dink.dat. In the case of FB2, it has 804 screens in its MAP.DAT.

For screens above 768, my assumption is it's going outside the bounds of ts_loc_mem and seeing if memory values above that are NULL, of which many wouldn't be, and then causes a segfault when it tries to memcpy 31280 bytes of something else it shouldn't into cur_ed_screen, hence why, as Scratcher says, it crashes even if MAP.DAT isn't there. What flummoxed me initially was that it was occasionally loading screens above 768, probably due to comparing to an address out of bounds that just happened to be zero and thus loading normally. The next release will have this rectified, probably by getting rid of the if/else if.

A little demonstration of some features in yeoldedinkedit. Apologies for the terrible audio.

I also had a look at this bug which I assume is related to a minor annoyance I was experiencing in which all text immediately displayed after a warp would appear white. If the map is faded down at all even during a warp, it will make the text white so as to be visible should the screen fade down completely. The fix is to make it not do so if it's in the process of fading up.

I'm still steadily chipping away at this on occasion. This time around I managed to reintroduce 8-bit mode for the 3 dmods that require it, along with the OpenGL 2.1 renderer while also adding a simple variable editor. For some reason, certain things look weird (text background) in the OpenGL renderer meaning the "software" renderer will probably still be the default when it's released. I may also include a few toggleable GLSL 1.20 shaders if I can figure out how to get them working properly.

Btw, yeoldetoast, a couple of months ago, I did some sprite resize render comparisons between various Dink engines, and found out that FreeDink is off by a couple pixels when rendering resized sprites, probably due to some rounding errors or something.

I finally remembered to upload my research results, and now they're on TDN here: https://www.dinknetwork.com/file/dink_engine_sprite_rendering_resize_tests/

When you have time, have a look at the pdf and comparison images to see what I mean, and maybe add the sprite resize thing to your list of fixes

There's also a sprite render test dmod included that you can use to see if the game is rendering resizes correctly, or rather, faithfully to Dink V1.08
(Edit: The dmod works by having some rectangular test sprites resized and/or trimmed on each screen, and having some pixel guides embedded in the tile sheets, that show you where the sprite edges should be.)

Well, this is interesting. A brief glance at dresize reveals that the SDL_Renderer "software" backend produces results that are consistent with your output. Running it with the OpenGL 2.1 backend on the other hand looks very different for me, which is troubling as the OpenGL backend is what I assumed you would be using, as it should be the default output mode in Beuc's last release of 109.6 from 2019 if not run with the -S flag. Are you able to figure out which backend you were using? Starting in debug mode and then searching for "dinkgl" or "graphics mode" in the debug.txt file should indicate what's in use.

Yup, it seems it runs in OpenGL by default, just as you said.

Btw, while there are some discrepancies in how the two renderers handle scaling *INSIDE* the sprite, I think that is to be expected. Every renderer will have different pixel interpolation I imagine, so the inner pixels can't be expected to be the same unless the exact same scaling algorithm is used. I think I mentioned this in the read me and the PDF appendix chapter.

The issue is the outer bounds of the sprite. In your first image, this seems to happen for the bottom right corner at scales of: 95, 90, 85, 80, 75, 65, and 55. It's the same for the 2nd picture too actually. At all of these scales, the bottom right corner is off by 1 pixel both horizontally and vertically.

If you look at "size1_chart.png" in the TEST_CHART_2 folder, the 4th column, the FreeDink column, manifests bottom right corner issues at the scales: 95, 90, 85, 80, 75, 70, 65, 65, 60, 55, 40, 30, 20, and possibly 10, hard to tell with that one as it's too small. In addition, it also has the wrong upper right corner at scales 90, 80, 40, 20 and 10. Which in your pictures does not seem to happen. [*]

I think that we should only expect the outer bounds and trimming edges to be the same between different engine implementations.

Although, that being said, different rendering of the inner pixels can affect shadows in a way that is not really demonstrated by these rectangular test sprites I used. Depending on the scaling algorithm, it can lead to funky situations where the shadow grid pattern either becomes solid black or fully disappears. Perhaps I should think about updating the test dmod so that it also has realistic sprites that have shadows as well?...

Edit:

* - actually, I am curious if the original freedink version has different outer bounds issues on different operating systems and such, hmm! I only tested these under Windows 10.

Edit 2:

Now that I think about it, I think I have some flaw in how I handled this... All of my sprites have their position set to *EVEN* coordinates. But having the sprites be at *ODD* coordinates might affect rendering too... So really, I should just double up all the test screens and offset all the sprites by a pixel, and see what happens under those circumstances.

I may just do that this weekend... And maybe add some scripting so each screen explains what exactly you should look for.

>updating the test dmod so that it also has realistic sprites that have shadows as well?

Please do. Even though I have encountered the line-skipping issue before, it would be nice to see how it looks in real-world scenarios or if it perhaps breaks any known dmods.

>different outer bounds issues on different operating systems and such

My cursory reading suggests the discrepancy with the OpenGL renderer could be due to different GPU manufacturers and their OpenGL implementations. That means that it may look different on an Intel iGPU when compared to a Radeon etc. I did a little test of setting the "software" renderer to use OpenGL and actual software rendering instead of Metal and saw no difference. My assumption is that it's the same across all its internal backends including DirectX9. The actual OpenGL renderer, however, uses explicit OpenGL calls to do just about everything, and therefore might still differ across platforms. You might remember my early compilation attempts in which the viewport was upside-down as a result of VirtualBox and its OpenGL "implementation". It might be possible to write/steal a shader that would make it look nicer when downsizing once I bother to learn enough OpenGL to figure out what's actually going on underneath it all.

0.5 Release changes:

- 8-bit mode works again meaning you will need to use -t for 24-bit mode.
- The OpenGL 2.1 renderer is accessible and half works and may be invoked with the -S (capital) command line flag, i.e. the opposite of normal Freedink.
- The "software" renderer is still the default for the time being, as GL has problems with transparency and 8-bit mode
- The GL renderer is locked to 24-bit mode
- Pressing Tab in mouse mode puts the cursor in the centre of the screen in case you lose it
- The system cursor should be invisible when not in debug mode now
- Added variable and sprite editors. Most sprite parameters are accessible, and input boxes can by typed into by activating the console
- Added "infinite health" to the cheat thing
- Linear filtering can be switched off for extra pixelly goodness

Known issues:

- In choice menus, there is sometimes an FPS dip but only on Windows.
- The sprite editor can occasionally lock input meaning you'll have to exit and restart.
- Audio may stutter when using the winmm backend. Should be fine in directsound and wasapi. Open "system information" to check.
- High DPI display mode switching doesn't scale properly
Edit: turns out there's a problem with certain sprites that are clipped and scaled to the point of invisibility!

Otherwise, when not run in debug mode, it should now be transparent with Freedink 109.6 in terms of behaviour except for Tab in mouse mode.

Downloads:
- Sores archive for compiling yerself
- Windows exe and new DLLs

Planned for 0.6:
- a config file for various audio settings
- joystick and gamepad stuff
- an x64 appimage

After a few months of putting it off, i've managed to generate an x64 AppImage using Linuxdeploy. It comes bundled with freedink-data meaning you should be able to just double-click it and have it play the main game. It should also support command line switches such as -w, and -game, although for the latter the full path must be specified for it to find it.
If it fails to open, make sure you have set the relevant permissions with "chmod a+x" or similar. If it complains about missing Liberation Sans at the start, you may install the "fonts-liberation2" or "ttf-liberation" package from your package manager for it to find it. The AppImage was generated on EndeavourOS and should work with most up-to-date distros that have at least glibc 2.35, and might work on the Steam Deck as well.

Download

what kind of dork would ever be caught dead using yedink

Hope you don't mind, but in the latest release of Martridge (V0.6.2.0 as of right now), I've added Ye Olde Dink V0.5 to the auto-installer list on windows.

(Although I should mention, you have to delete the old configInstallerList.json file to get it to show up)

Edit: Huh, playing around with Periculo and YeOldeDink some more I think I found a bug in V0.5! It seems that if I launch the Periculo DMOD (V1.04) without True Color mode disabled, the animated Dink in the main menu doesn't have transparency!

This works fine in V0.3 both with True Color enabled and with it disabled! But in V0.5, it only works if True Color is enabled...

Very cool! Is it easier if I release the 7z files with everything in the root dir? I'll upload 0.6 very soon.

That transparency discrepancy only showed up when I updated SDL_Image more recently. I haven't looked into it, but I don't consider it a real bug in this case as those sdink-* BMPs are 24-bit anyway, and I only consider 8-bit mode to be a legacy feature to be used with old D-mods, or those using palette swapping. 0.3 was locked to 24-bit so it'd never be apparent.

Release notes for 0.6:
- Improved gamepad support. The game controller API now being used is a higher-level one in SDL2 that uses a standard config and mapping across most controllers that have a SNES-style layout, similar to how Xinput does it. Previously, the standard joystick interface would attempt to automap, but it was rather hit and miss, with some layouts completely absent. My Sixaxis had punch on the select button when connected via bluetooth, for example.
- If you can find your particular model in this list it will probably work, and you can go into the relevant info window to see if it's properly detected with a mapping assigned.
- Assuming a Switch Pro Controller: A is talk, B is attack/select, Y is magic, and X is inventory.
- Assuming a DualShock, R1 is high-speed mode, R2 is attack. L1 is button7.c and L2 is magic.
- Start/+ is the escape menu, and back/select/- is the map
- The left analogue stick is bound to movement along with the directional buttons
- The right analogue stick is currently unbound, and the clicky stick (R3) crappily toggles debug mode on and off a hundred times per second.
- Unfortunately the layout cannot be rearranged at the moment, and some bindings may differ across manufacturers for magic and inventory. Check the mapping guide for more info. There is also no ability for rich people to choose a second or third device for input right now should they have more than one.
- Disconnects and reconnects should now be autodetected, assuming you started without -nojoy and had something connected and detected at launch. Otherwise, there's a button in the joystick settings window for connecting after launch that will sometimes work.
- The debug interface has gamepad control enabled too and should be switched off if you're not using it as it may interfere.

- Along with the live sprite editor in the previous release, there is now a map sprite editor. This means you can edit sprites right in the engine and save them to MAP.DAT. Be aware that there's no undo.
- The live sprite editor now has an overlay for Dink.ini properties to help you with your hardbox and depth dot. Set brain to zero for animated sprites beforehand!
- The menus have been moved around again, and the info overlay no longer displays by default.
- Pressing Alt+U will unfreeze sprite 1 (player/mouse sprite).
- High-DPI still doesn't work properly and probably never will
- Updated to the latest Dear Imgui stable release which may have fixed the aforementioned FPS dip on Windows.
- If no launch options are specified, a box will pop up and let you choose windowed mode, as well as optionally select a d-mod to run. This is mainly for AppImage users who might not have a front-end available to them. It doesn't seem to work on EndeavourOS, and will look wrong on Windows. Ubuntu 22.04 and later should be fine.
- Due to the general crappiness of MIDI on GNU/Linux, AppImage builds are now linked against MixerX instead of SDL-Mixer for audio, and use ADLMIDI's OPL3 emulation for playback by default, reminiscent of the way many of us originally heard Dink's music. This doesn't require a SoundFont or GUS patches and hopefully should always work. The MIDI backend can be selected in the audio settings window for FluidSynth and Timidity++.
- Bugfix: sprites that were clipped to be invisible while resized were causing segfaults while using the software renderer, such as the rock on the bridge at the start of Quest for Dorinthia 2.

Links:
- exe and DLLs (~20MB)
- x64 AppImage with included data (~40MB)
- Source for DIY compiling (73MB)

Todo for 0.7:
- Implement the config file and make settings persistent
- A save editor, or something along those lines
- Start using a proper file host

In the latest version, the game is crashing upon trying to play some midi's.
Here's one in particular that crashes in case you want to test: 210.mid

Doesn't crash in previous verison.

Thanks! The good news is that it seems to be limited to Windows. The bad news is that I can't figure out what's causing it on there. I've made an alternate build with MixerX that may be more stable. Please let me know if it crashes again.

exe and DLLs

Well, now I'm getting OPL3 MIDI. Good news: it no longer crashes. Versions before v0.6 did not have the crashing problem. I don't know much about programs, so that's all I can tell.

>I'm getting OPL3 MIDI

As it should be for an authentic Dink experience. Hurrah. I should also mention that debug.txt is not written to by default in this release, but can be toggled in the menu.

>Very cool! Is it easier if I release the 7z files with everything in the root dir? I'll upload 0.6 very soon.
Actually it would have haha, but I already solved that so it's fine, just keep doing it as you have so far!

>That transparency discrepancy only showed up when I updated SDL_Image more recently. I haven't looked into it, but I don't consider it a real bug in this case as those sdink-* BMPs are 24-bit anyway, and I only consider 8-bit mode to be a legacy feature to be used with old D-mods, or those using palette swapping. 0.3 was locked to 24-bit so it'd never be apparent.

AH! That does make sense! Fair enough.

Forgot to mention, during some testing for Periculo, we found a DinkC related bug, where upon calling the `random` function with the range set to 0, would crash the game due to a division by zero. Iirc, yeoldedink was affected too?

Something to add to your things to do/check for the next version

>just keep doing it as you have so far!

Oops, too late.

>yeoldedink was affected too?

Just had a look and I was indeed greeted by a floating point exception. I'll include the fix in 0.7.

By the way, was trying to run YeOldeDink (V0.6) on the Steam Deck using the AppImage you provided, and it seems i'm getting an error about `GLIBC_2.34` and `GLIBC_2.35` not being found.

Weren't AppImages supposed to contain all the required files?

Or should i be installing the libraries manually on the deck?

Edit: Hmm, this is weird, I thought I was on the latest stable update.. but apparently after downloading some beta update for the Steam Deck, it runs...

Edit2: Actually, seems it's not finding the "LiberationSans-Regular.ttf" font xD

Edit3: So playing around a bit with it, it seems to run pretty well if you launch it in Game Mode (see: https://www.steamdeckgaming.net/post/how-to-install-appimages-on-steam-deck-for-game-mode )

If you launch it in Desktop Mode however, the buttons are kind of whack and not really working as expected hah...

I also tried using Martridge with the appimage - launching dmods won't work if you use a relative path (since Martridge makes the path relative to the appimage file but it needs to be to wherever the yeoldedink binary file resides in /tmp/ or what have you...)

Martridge itself seems to work as intended in Desktop Mode, except it won't detect the base game in the appimage file... So you can't use it to launch the original Dink xD

On the other hand, running Martridge in Game Mode is a disaster! Apparently the AvaloniaUI version I built it on, or perhaps the theme I'm using?.. Either way, something about it is not right, the combo-boxes and the menu drop-downs don't work at all! Navigating the UI is also kind of a pain with the gamepad controls... I think I'll have to rethink the interface a bit and find a way to bind commands in the interface to gamepad inputs as well.

Edit4: Oh yeah, so I suppose, make sure to include the Liberation Sans fonts in your app image for 0.7, so it works on Steam Deck without having to install them separately

>Weren't AppImages supposed to contain all the required files?

This isn't DinkOS i'm releasing!

> the buttons are kind of whack

I forgot to include the controller mappings file with the AppImage and only realised after uploading. I've made another one with it in there that should also be a bit smaller because it doesn't include freedink-data twice... If the controller doesn't work properly after that then it's a mystery.

Updated 0.6 AppImage.tar.gz

To get the included launcher working, you may install "zenity" with pacman.

In regards to fonts, the engine does two different checks at startup. The first is one in which it directly looks for the TTF file in that resources directory. If it fails to find it there and it was compiled with Fontconfig, it'll use that to find a system-installed font of the same name. Unfortunately, Beuc was fairly insistent on Liberation Sans to the point where the engine just gives up if it can't find it, meaning the next release will search for either Arial or OpenSans, as the latter is installed on most distros and looks authentic enough, and the former is always available on Windows and is the default in <=1.08 anyway. If it can't find anything it'll pop up with a file selector for you to choose your own TTF.

Some may have noticed, but there seems to be a problem with typeface rendering on GNU/Linux, with Liberation Sans looking like a jagged mess. It seems Freetype changed their default rendering algo at some point, and most distros, if they do bundle Liberation Sans or provide a package, use a newer release that looks somewhat different to the one we're accustomed to due to being designed for the newer Freetype renderer. There's some stuff in the Arch wiki regarding Freetype configs that may assist, but probably won't.

It turns out that Imgui can also use Freetype very straightforwardly too, and as the engine's using it anyway, it makes sense to switch so that the debug interface looks a bit crispier in future releases.

In regards to the deck, from what I can ascertain, it doesn't work properly at all in desktop mode, and comes up with an on-screen keyboard and non-working buttons even with the controller map loaded. I may remap the buttons again in the next release if I can find a config that works unless everyone's fine with using an AppImage integrator for game mode. Also of note, there might be an invisible touch-screen directional controller in the middle of the screen that will allow you to move around unless I turned it off early on, or differs between desktop/game mode yet again.

Release notes:
- Zero used as the range for calls to random() no longer causes a floating point exception (thanks drone1400).
- math_mod() will now throw an error in the log if it gets fed zero as the divisor instead of crashing, and "/" should silently fail.
- Added an editor type/frame override viewer.
- Added a colour palette viewer
- Added get_platform() to DinkC with return values corresponding to RTDink
- Reintroduced playavi() using ffmpeg's "ffplay".
- Added the option to ignore the 4:3 aspect ratio and use the full width of the window
- Made the variable and sprite editors less dumb in terms of selection
- The map screen index viewer now allows you to create new screens (copies the one you're on like Dinkedit does) and edit MIDI number and indoor status
- The audio window now shows you more details about what's playing and allows you to type in media file names directly for playback
- The debug interface now uses a different font with improved rendering, and in the event a suitable display typeface can't be found, a selector will pop up and let you choose one (on GNU/Linux only).
- Updated the game controller database
- Added various minor improvements
- Implemented the config file (yedink.ini) this time around so you can change a few parameters.
- Rewrote the SFX backend using SoLoud, and increased the voice count from 20 to 40


Addendum and known issues
- The random() bug was reported by Someone in 2008 and was never rectified until now. The random number generator in this release is somewhat different and is being used for most random calls within brains now too.
- There are a few SIL-OFL TTF files distributed with compiled builds that I took from ImGui and other sources, and you can add your own to the "yeoldedink" data subdir and change it in the config file (unless you're an AppImage user). The bundled typefaces are:
- CascadiaCode.ttf JetBrainsMono-Regular.ttf ProggyClean.ttf
Cousine-Regular.ttf Karla-Regular.ttf ProggyTiny.ttf
DroidSans.ttf LiberationSans-Regular.ttf Roboto-Medium.ttf
- For playavi() to work, you must have ffmpeg's ffplay in your PATH environment variable somewhere. This will be the case if you use your distro's package manager, or something like Chocolatey or Scoop on Windows. This is neither a mature nor stable feature and should not be used by anyone, other than for brief entertainment.
- You can now use Ogg Vorbis, FLAC, and MP3 with load_sound() so as to finally bring us up to speed with Seth as of 2010.
- Some SFX-related stuff may sound a bit different, particularly sound_set_vol(). The return values from playsound are now unique for each call which shouldn't affect D-mods, but does break RobJ's vcheck.
- The new hardbox and dot viewer/editor may sometimes cause a crash with certain sprites, and hitting "redraw" in the map sprite editor may also.
- Pressing Tab will centre the player in Cast V Revolution. I'm not sure if it sets mode 3 properly.
- Maximising on Windows might be troublesome
- The OpenGL renderer still doesn't work properly and never will
- A segfault will occur when you exit if you run with sound off.

Links:
- Sores archive ~70MB
- x64 AppImage coming soon
- exe and DLLs ~24MB SHA1: f0deb4d1fa4e952a34b8bd5f772bb4d5da331b29

Plans for 0.8
- Use the new icon
- Implement a palette editor
- Do something about sound_set_vol()

Question, why not create a Github site for this?

Heh, I remember that thread about the random bug. Awesome work, Toast!

Thanks Marpro!

As for Github, in usual Dink fashion, I am somewhat embarrassed by the quality of it all, and wouldn't want to upload it there until I fully rejig the build system with Meson, and fix the opengl backend and such. Unfortunately, in order to do that, one must become an expert in GNU Autotools and OpenGL so as to unravel it all... In the meantime, I would prefer to just use this thread as my own DinkHub. The audience for this fork is very limited as it is, and the included changes are probably not to everyone's taste meaning i'd prefer to just keep it all here rather than attempt to get it included in any package managers beyond Martridge.

Anyway, the reason there's no AppImage yet is because i'm still refining the use of another command line parameter, -c, for specifying a path to a config file. 0.75 will also include speech synthesis that reads out all the game's text in a horrible voice (switched off by default ), and gold/stats will lerp up when your total changes rather than endlessly clattering, or turning into a choir cacophony.

>As for Github, in usual Dink fashion, I am somewhat embarrassed by the quality of it all

Ah, I know that feeling

Also I suppose there's an argument to be made about Github possibly training its copilot AI thingamagig on your code, regardless of any potential licensing conflicts :V
I remember some open source fans being upset about that a while back.

It'd be their loss in this case . Anyway, once again i'm delaying the next release for the sake of testing new stuff. Speaking of AI, i've got Elevenlabs working with a singular voice for everything. Here's a test with Mystery Island. Most likely won't be in the final release, however, as it has to do an HTTP request for every line of text.

Also I suppose there's an argument to be made about Github possibly training its copilot AI thingamagig on your code, regardless of any potential licensing conflicts :V
I remember some open source fans being upset about that a while back.

Alternatively there's Gitlab which has none of that.

Yeah, that's what RW uses for WinDinkEditPlus.

YeOldeDink 0.75 Release Notes

This is a minor incrementation upon 0.7 with the following additions:
- Gold and stats will lerp when changed
- The default save info now includes the date and time like every other save manager in existence, rather than the level
- Crappy speech synthesis is available in the audio options
- A config file can be specified with -c on the command line, and a sample file is included with the AppImage zip. Remember you'll have to specify the full path if you're going to use it.

Links:
- x64 AppImage
- src arc hive
- Windows build only if someone who isn't Skorn really wants one

compile windows builds, abandon linux