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