YeOldeDink: A Freedink Fork for dorks
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.
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.
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.
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.
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
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.
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.
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!
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!
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.
The next release may be a little while. Things are changing rapidly.
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.
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
- 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".
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.
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.
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).
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:
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.
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 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.)
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.
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.
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
- 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
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
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...
(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.
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
- 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.
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
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.
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.
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
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.
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?
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.
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.
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()
- 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, 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.
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.
I remember some open source fans being upset about that a while back.
Alternatively there's Gitlab which has none of that.
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
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
I still can't play yeoldedink with sound cause it sounds like crap.
But yeh, can I get a windows build. It's good for testing compatiblility and stuff.
But yeh, can I get a windows build. It's good for testing compatiblility and stuff.
You can check which audio driver is being used under System -> System Information. It sounds terrible under winmm, but directsound and wasapi should be fine, and may be set with the SDL_AUDIODRIVER environment variable. You may also want to check the sound card's output sample rate and adjust it in yedink.ini if it differs so as to cut down on resampling.
@Skurn:
compile windows builds, abandon linux
Dfarc and Dink are still part of several standard Linux builds OR at the very least remain available to Linux users through convenient Linux based tools that access https://www.gnu.org/software/freedink/.
I can assure you our tiny Dink community would be even smaller without these users. Hence twp's recent question at [ https://www.dinknetwork.com/forum.cgi?MID=208073&Posts=10 ].
compile windows builds, abandon linux
Dfarc and Dink are still part of several standard Linux builds OR at the very least remain available to Linux users through convenient Linux based tools that access https://www.gnu.org/software/freedink/.
I can assure you our tiny Dink community would be even smaller without these users. Hence twp's recent question at [ https://www.dinknetwork.com/forum.cgi?MID=208073&Posts=10 ].
I'm actually with Skorn on this one. Apart from a few Steam Deck users, I have received approximately zero feedback from GNU/Linux desktop users to the point where I can only assume there aren't any. Unless there is compelling evidence to the contrary, I won't bother making AppImages from now on.
Anyway, here's a preview of 0.8's debug output demonstrating log levels separated by colours, and emojis for easier viewing of lines.
Anyway, here's a preview of 0.8's debug output demonstrating log levels separated by colours, and emojis for easier viewing of lines.
Most likely due to the fact that it wasn't posted in any of the linux related channels and most likely won't offer much feedback as everything is kept in TDN forum only. If someone wants to commit a code that fixes some stuff ya missed or something it will not just straight up send ya a code through PM which is pretty inconvenient. Unless the project is hosted on Github or Gitlab.
Multiple open source projects are still hosted in em even if they are not finished yet.
Multiple open source projects are still hosted in em even if they are not finished yet.
@yeoldetoast:
We just had a linux specific question here.
https://www.dinknetwork.com/forum.cgi?MID=208073&Posts=10
I admit that I do not have any statistics to back the idea up*, but I know personally of several (not particularly technical) folks who have downloaded Dink for their favorite linux distro. I think there is a faction of people who use linux as a low cost OS option who also are willing to try out the free Linux games that are available.
*Is there any way we can find out how many Dink downloads take place from various distros?
We just had a linux specific question here.
https://www.dinknetwork.com/forum.cgi?MID=208073&Posts=10
I admit that I do not have any statistics to back the idea up*, but I know personally of several (not particularly technical) folks who have downloaded Dink for their favorite linux distro. I think there is a faction of people who use linux as a low cost OS option who also are willing to try out the free Linux games that are available.
*Is there any way we can find out how many Dink downloads take place from various distros?
@SlipDink:
Here's the graph for Debian. freedink-engine is the purple line, the game itself (freedink) is the other line. https://qa.debian.org/popcon-graph.php?packages=freedink-engine%20freedink&show_installed=on&want_legend=on&want_ticks=on&date_fmt=%25Y-%25m&beenhere=1
Here's the graph for Debian. freedink-engine is the purple line, the game itself (freedink) is the other line. https://qa.debian.org/popcon-graph.php?packages=freedink-engine%20freedink&show_installed=on&want_legend=on&want_ticks=on&date_fmt=%25Y-%25m&beenhere=1
@ Ducklord:
So, for the debian based distros alone, it looks looks to me we have between 200 and 250 (sometimes higher) installations (per month?) since 2012?
Am I reading this chart correctly?
So, for the debian based distros alone, it looks looks to me we have between 200 and 250 (sometimes higher) installations (per month?) since 2012?
Am I reading this chart correctly?
As far as I know, the graph just shows how many people had Freedink installed on their computers at a given time (and only among those who had the popularity-contest package installed)... So that would mean there are no new downloads when the lines don't go "up".
Also, if you look at this, it would mean that there are only around 16 Debian users who use Freedink on a regular basis right now.
Again, as far as I know, those numbers are for Debian only, not for other Debian-based distros such as Ubuntu, Devuan and so on.
Also, if you look at this, it would mean that there are only around 16 Debian users who use Freedink on a regular basis right now.
Again, as far as I know, those numbers are for Debian only, not for other Debian-based distros such as Ubuntu, Devuan and so on.
i thought linux was supposed to be focused on privacy. oh well, guess it's just as shit as the rest
The Popcon package is opt-in at installation time and was controversial to the point where they ended up completely removing it from Ubuntu and nuking all the archived stats because so many users kicked up a stink. It turns out Devuan collects them too, and has a whopping 12 installations of freedink-data etc. Of course, these stats aren't particularly indicative unless you are able to figure out what percentage of people refuse to opt in. Also, welcome back Ducklord and thanks for your d2c decompressor!
If I ever get to a 1.0 release, I may make an AppImage of that for those three interested individuals out there. Until then, it's really not worth the effort to keep building and testing for a platform I rarely use. Anyway, the palette editor is coming along nicely and will be full-featured for 0.8.
If I ever get to a 1.0 release, I may make an AppImage of that for those three interested individuals out there. Until then, it's really not worth the effort to keep building and testing for a platform I rarely use. Anyway, the palette editor is coming along nicely and will be full-featured for 0.8.
Maybe we could get a better idea of what operating systems are used by those who visit and/or download dmods from the dink network website IF Redink1 records the browser information of all the visitors in some kind of log file.
I'm talking about the kind of information that is recorded at this website (and displayed back to the visitor in this case).
https://privacy.net/analyzer/
Of course, I know that such information can be faked/spoofed using various tools, but I suspect that most visitors to the DN don't bother to do that, at least not for this seemingly benign website.
I'll ask Redink1 about that in Discord.
I'm talking about the kind of information that is recorded at this website (and displayed back to the visitor in this case).
https://privacy.net/analyzer/
Of course, I know that such information can be faked/spoofed using various tools, but I suspect that most visitors to the DN don't bother to do that, at least not for this seemingly benign website.
I'll ask Redink1 about that in Discord.
Wow, that was quick! Redink1 showed me a chart for which platforms use the in-game dmod browser.
But, it is not really the information I was looking for as the in-game-dmod browser is not one that is generally part of the Dfarc/Dink-engine combo that is part of many Linux Distros. In fact, I don't think it is part of any of the Linux distros. So, we still do not know how many visitors to the DN website are Linux users.
I'm sure that the list of Linux Dinkers is greater than one with just me and twp on it.
But, it is not really the information I was looking for as the in-game-dmod browser is not one that is generally part of the Dfarc/Dink-engine combo that is part of many Linux Distros. In fact, I don't think it is part of any of the Linux distros. So, we still do not know how many visitors to the DN website are Linux users.
I'm sure that the list of Linux Dinkers is greater than one with just me and twp on it.
Also, welcome back Ducklord and thanks for your d2c decompressor!
Thank you!
I believe most of the credit should go to Philip Gage for the original source code of the d2c converter, though. All I did was keep beating it with a hammer until it agreed to compile.
If anyone's interested, I believe this is the very first version of the source code for the expand program...
Thank you!
I believe most of the credit should go to Philip Gage for the original source code of the d2c converter, though. All I did was keep beating it with a hammer until it agreed to compile.
If anyone's interested, I believe this is the very first version of the source code for the expand program...
Speaking of GNU/Linux, I just remembered that there's a change in how Mix_FreeChunk(), the thing that clears SFX buffers, does things in later releases of SDL2_Mixer. In old Mixer releases, it would just clear the channel and continue on its merry way, however nowadays it seems to induce a segfault for reasons I couldn't figure out. I commented it out in early releases and didn't tell anyone in case it slowly leaked memory, but nothing seems to have come of it. Anyway, my assumption is that pretty much all packages of freedink-engine will be broken on newer distros including Homebrew on macOS, and that this is what caused twp's problem in the other thread. The fact that there has been only one post about this rather severe problem affirms my stance for the time being
TBH, its been a long time since the last official update for FreeDink so through the time some components that make FreeDink have been receiving updates and changes. Even now i cannot compile FreeDink at all (including YeOldeDink) from the source code so i had to find a workaround to grab the binary file. The source code is just simply old and no one joined in to maintain and fix it (until now), mix that with the fact that the game Dink Smallwood isn't well known nowadays other than by selected people.
0.8 or 0.9 should be easier to compile when it's out. For some reason, EndeavourOS can't seem to find the Freetype headers, meaning for AppImages I've had to resort to weird workarounds at compile time. Old releases before MixerX should compile the engine elf okay at least. I can't remember which packages you need to run bootstrap though apart from the autotools ones and maybe gettext, dunno which part you're stuck at.
A few weeks ago I decided to stuff around with Godot to see what it was capable of. I managed to get him walking around with background music and tiles in about an hour or so. It's a shame we're at the ded gaem stage of things because I imagine we could do some pretty amazing stuff with enough combined effort.
A few weeks ago I decided to stuff around with Godot to see what it was capable of. I managed to get him walking around with background music and tiles in about an hour or so. It's a shame we're at the ded gaem stage of things because I imagine we could do some pretty amazing stuff with enough combined effort.
i can't disassociate that word from pokemon go, teen titans go, or the general concept of zoomers. therefore, the name makes it sound like some modern bastardization of dink for the tiktok generation.
i suggest the superior name, ponydink. it exemplifies the current state of our kingdom and brings forth images of regality and yet, simplicity. perfect for the genre and a nod to the period it was made in.
i suggest the superior name, ponydink. it exemplifies the current state of our kingdom and brings forth images of regality and yet, simplicity. perfect for the genre and a nod to the period it was made in.
YeOldeDink 0.8 comes with numerous new features and improvements as follows:
- Debug messages are using a new backend which has colour-coded output on certain platforms and is toggleable.
- Starting in debug mode from the command line will display progress bars while loading
- Ghostknight's extremely verbose logging is now viewable with the relevant button in the log window.
- The OpenGL (4.x) renderer works again thanks to SDL-GPU.
- Most log messages are now prefixed by emojis so they're easier to visually sort through. They cannot be turned off.
- Many more options are now persistent, and are autosaved upon exit.
- The config file will now allow you to persistently change your default MIDI backend. See below for parameters.
- Most of the potentially data-destructible features are now hidden behind a "developer mode" toggle in case you're a wuss.
- The new colour palette editor allows you to alter and export palettes to the clipboard, although live screen alterations will only be visible in 8-bit mode for obvious reasons.
- "Smooth" shadows and fades are now available in the display options.
- Added a very basic screen tile editor meaning that in theory you can make an entire d-mod in the engine now.
- The inbuilt config file editor has been removed. Please edit the ini file manually instead.
- Added a hard.dat tile and index viewer.
- Added various minor improvements, and updated to the latest ImGui release.
- The SFX backend now uses a separate output that doesn't rely upon SDL2, and the channel count has been bumped up again to 64.
- Speech synthesis volume is now able to be altered independently, and has a bass boost applied so it's properly audible.
- Implemented get_client_version() for DinkC (thanks robj). Will return "80" for this build.
- Passing zero as the frequency in playsound() will cause the sound to be played back at its native speed.
- Bugfix: show_bmp() now cancels a fade in 24-bit mode when before it would remain black
- Added distance delay simulation for positional sounds.
- The integrated launcher is back again, and still looks awful on Windows.
Addendum and known issues
- Progress bars and coloured debug messages probably won't work on Windows unless you use something like Git Bash to launch with.
- The persistent settings are saved in your "yeoldedink" ancillary data path (with the fonts) under the name "settings.dink" with a sample set included in compiled releases. Unlike the config file, settings.dink isn't a user-editable text file and more closely resembles the save format. If your settings fail to save, please check for proper read/write access. Otherwise, if there are parameters I forgot to make persistent, please complain so they end up in the next release.
- The config file parameters have been trimmed down for this release meaning you should overwrite it with the included new one, or otherwise remove and replace fields as needed.
- The setting for "midiplayer" in yedink.ini can be either 0 for ADLMIDI (Sound Blaster FM), 1 for system output, 2 for TiMidity (requires pats otherwise crashes), 3 for OPNMIDI (Sega-style FM), 4 for FluidSynth (needs soundfont), or 5 for EDMIDI (unstable). Of course, you can still change these on the fly for the next MIDI in the audio options, but this isn't saved across launches.
- The "Smooth Shadows" setting is a reimplementation of Redink1's shadow patch that notably made Skorn cream. It's based on Redink's first release of it meaning it only works on black grids. It will not work with FastFile bmps, and toggling the setting will most likely not have an effect until you either restart or traverse through enough screens to load something new, as it is applied while graphics are loaded rather than at blit time. It also makes certain things look weird and hasn't been fully finished yet.
- The Smooth Fade option uses Tweeny with various easing functions to control the brightness and make fades look more like they did in 1.07 and earlier. This and the aforementioned shadow effect are only available in 24-bit mode.
- The OpenGL renderer is still considered experimental due to lacking a few features. As with prior releases, it may be invoked with -S on the command line.
- The distance delay setting helps cut down on the initial blast of misplaced audio positioning upon screen transition. Changing the setting requires a restart before it'll take effect as it's applied when a sound is loaded.
Future releases:
- There will probably be several updates for 0.8 before 0.9.
Links:
- exe and new dlls
- src archive
- Debug messages are using a new backend which has colour-coded output on certain platforms and is toggleable.
- Starting in debug mode from the command line will display progress bars while loading
- Ghostknight's extremely verbose logging is now viewable with the relevant button in the log window.
- The OpenGL (4.x) renderer works again thanks to SDL-GPU.
- Most log messages are now prefixed by emojis so they're easier to visually sort through. They cannot be turned off.
- Many more options are now persistent, and are autosaved upon exit.
- The config file will now allow you to persistently change your default MIDI backend. See below for parameters.
- Most of the potentially data-destructible features are now hidden behind a "developer mode" toggle in case you're a wuss.
- The new colour palette editor allows you to alter and export palettes to the clipboard, although live screen alterations will only be visible in 8-bit mode for obvious reasons.
- "Smooth" shadows and fades are now available in the display options.
- Added a very basic screen tile editor meaning that in theory you can make an entire d-mod in the engine now.
- The inbuilt config file editor has been removed. Please edit the ini file manually instead.
- Added a hard.dat tile and index viewer.
- Added various minor improvements, and updated to the latest ImGui release.
- The SFX backend now uses a separate output that doesn't rely upon SDL2, and the channel count has been bumped up again to 64.
- Speech synthesis volume is now able to be altered independently, and has a bass boost applied so it's properly audible.
- Implemented get_client_version() for DinkC (thanks robj). Will return "80" for this build.
- Passing zero as the frequency in playsound() will cause the sound to be played back at its native speed.
- Bugfix: show_bmp() now cancels a fade in 24-bit mode when before it would remain black
- Added distance delay simulation for positional sounds.
- The integrated launcher is back again, and still looks awful on Windows.
Addendum and known issues
- Progress bars and coloured debug messages probably won't work on Windows unless you use something like Git Bash to launch with.
- The persistent settings are saved in your "yeoldedink" ancillary data path (with the fonts) under the name "settings.dink" with a sample set included in compiled releases. Unlike the config file, settings.dink isn't a user-editable text file and more closely resembles the save format. If your settings fail to save, please check for proper read/write access. Otherwise, if there are parameters I forgot to make persistent, please complain so they end up in the next release.
- The config file parameters have been trimmed down for this release meaning you should overwrite it with the included new one, or otherwise remove and replace fields as needed.
- The setting for "midiplayer" in yedink.ini can be either 0 for ADLMIDI (Sound Blaster FM), 1 for system output, 2 for TiMidity (requires pats otherwise crashes), 3 for OPNMIDI (Sega-style FM), 4 for FluidSynth (needs soundfont), or 5 for EDMIDI (unstable). Of course, you can still change these on the fly for the next MIDI in the audio options, but this isn't saved across launches.
- The "Smooth Shadows" setting is a reimplementation of Redink1's shadow patch that notably made Skorn cream. It's based on Redink's first release of it meaning it only works on black grids. It will not work with FastFile bmps, and toggling the setting will most likely not have an effect until you either restart or traverse through enough screens to load something new, as it is applied while graphics are loaded rather than at blit time. It also makes certain things look weird and hasn't been fully finished yet.
- The Smooth Fade option uses Tweeny with various easing functions to control the brightness and make fades look more like they did in 1.07 and earlier. This and the aforementioned shadow effect are only available in 24-bit mode.
- The OpenGL renderer is still considered experimental due to lacking a few features. As with prior releases, it may be invoked with -S on the command line.
- The distance delay setting helps cut down on the initial blast of misplaced audio positioning upon screen transition. Changing the setting requires a restart before it'll take effect as it's applied when a sound is loaded.
Future releases:
- There will probably be several updates for 0.8 before 0.9.
Links:
- exe and new dlls
- src archive
Uh, is the machine narration a new feature, or did I screw up a Windows setting? How do I disable it?
It can be turned off in the audio window, or alternately you can delete settings.dink and do it all from scratch if you're inclined.
Havin an option to download and compile the necessary dependencies before starting with YOD would be nice. Some of em like SDL GPU and the SDL2 Mixer Ext are pretty obscure, i was lucky enough to grab the former from ArchLinux's AUR but sadly the latter one is absent.
The current plan for subsequent releases is to make those libraries compile-time options (e.g. -DUSE_MIXER_X) and otherwise fall back to another default, at least for MixerX since it's largely interchangeable with standard SDL Mixer. Compiling MixerX is an effort unto itself in many cases and not something I would want to attempt to automate. If you are looking to compile it yourself, you'll probably have to enable its GPL mode and the extra audio codec downloads for it to build properly.
In the meantime, I've started writing a guide for new users who don't want to trawl through the entire thread.
In the meantime, I've started writing a guide for new users who don't want to trawl through the entire thread.
Congrats on a great job!
I tested YeoldDink's Appimage and was very impressed with how well it supported all that I expected to work so far in terms of backwards compatibility with the current Linux version that "comes with" my favorite distro.
The Debug/Console/Ultimate-Cheat features are quite impressive too. I will definitely use this version of the Dink Engine for any difficult DinkC debugging I need to do. I tried it with several of my dmods and will keep testing to see if any problems come up. So far, so good.
I tested YeoldDink's Appimage and was very impressed with how well it supported all that I expected to work so far in terms of backwards compatibility with the current Linux version that "comes with" my favorite distro.
The Debug/Console/Ultimate-Cheat features are quite impressive too. I will definitely use this version of the Dink Engine for any difficult DinkC debugging I need to do. I tried it with several of my dmods and will keep testing to see if any problems come up. So far, so good.
login-name@system-name:~/dmods/periculo/story$ !cat cat /etc/*iss*t Ubuntu 22.04.2 LTS login-name@system-name:~/dmods/periculo/story$ cd ~/tmp/Y* login-name@system-name:~/tmp/YeOldeDink0.5$ yeoldedink-x86_64.AppImage -v GNU FreeDink 109.7 FreeDink is free software, and you are welcome to redistribute it under certain conditions; see the GNU GPL for details. http://gnu.org/licenses/gpl.html There is NO WARRANTY, to the extent permitted by law. login-name@system-name:~/tmp/YeOldeDink0.5$ yeoldedink-x86_64.AppImage -d -w -t -g ~/dmods/litleadv
@yeoldetoast
Took me long enough to actually find it.
For anyone looking for the option, press Alt+D, and find the Ausio section in the menu.
Question:
Is texture filtering an original 1.08 function or was added later?
Took me long enough to actually find it.
For anyone looking for the option, press Alt+D, and find the Ausio section in the menu.
Question:
Is texture filtering an original 1.08 function or was added later?
Thanks Slipdink, there's at least one minor graphical issue that drone1400 mentioned above in regards to 24-bit graphics looking weird when launched in 8-bit mode, but it's nothing that can't be worked around by starting in 24-bit graphics mode, and authors performing a get_truecolor() check at launch. In this case, it's the price paid for PNG support with functional transparency. Apart from that, just about everything else should be identical or at the very least non-breakingly indistinguishable.
Freedink automatically applied texture filtering in desktop full-screen and maximised windows, with Beuc having programmed the ability for nearest-neighbour as well except with no way to switch between the two until now. 1.08 never had anything like that as it has no capability for display modes with a higher resolution unless using something like DxWnd.
Freedink automatically applied texture filtering in desktop full-screen and maximised windows, with Beuc having programmed the ability for nearest-neighbour as well except with no way to switch between the two until now. 1.08 never had anything like that as it has no capability for display modes with a higher resolution unless using something like DxWnd.
Thanks Slipdink, there's at least one minor graphical issue that drone1400 mentioned above in regards to 24-bit graphics looking weird when launched in 8-bit mode, but it's nothing that can't be worked around by starting in 24-bit graphics mode, and authors performing a get_truecolor() check at launch.
Yep, I ran into that while testing and used the appropriate command line switch to resolve the matter. Like you say, "it's nothing".
Yep, I ran into that while testing and used the appropriate command line switch to resolve the matter. Like you say, "it's nothing".
I've almost managed to finish integrating Phoenix's Lua backend as an extra scripting engine which should be ready for the next release, complete with a working DinkLua debug console. It was slightly difficult to get working due to it originally being for the old 108.x branch, but so far most of the features are operable to the point where I have been able to almost completely rewrite my personal test D-mod in it. Although I don't expect people to actually use it unless they happen to be a big fan of Pico-8 or Love2D, those curious can brush up on Phoenix's spec here.
Holy crap. I never expected that thing to see the light of day again. I'm positively flabbergasted by this news!
You know, I wanted to make a new DMOD some day, but I didn't want to have to deal with DinkC again. Maybe now I actually can soon.
You know, I wanted to make a new DMOD some day, but I didn't want to have to deal with DinkC again. Maybe now I actually can soon.
I was hesitant to contact you to nag for more implementation details in case you'd lost interest, but I guess that's been answered . I've been itching to get an extra scripting engine going such as DukTape for a while now but eventually thought it best not to reinvent the wheel, but instead cobble together an old one. Thankfully most of the changes from Lua 5.3 to 5.4 seem to have been non-breaking ones, and only sound_set_vol/survive don't seem to work so far.
I can send you (and any other DinkC haters) an AppImage of it in its current state if you'd like, although keep in mind DinkC instantly segfaults when enabled and would be inaccessible...
I can send you (and any other DinkC haters) an AppImage of it in its current state if you'd like, although keep in mind DinkC instantly segfaults when enabled and would be inaccessible...
You people really are a talented and dedicated bunch...
Don't worry about contacting me/nagging me about things related to LuaDink/DinkLua. As long as it's been, I've always been keen on bringing it back. Believe it or not, but I'd started work on it a few weeks ago, but it never went anywhere, because I remembered how much of a nightmare trying to get FreeDink to compile is, and so by the time it compiled, I was kind of done with that attempt for now. Kinda makes me wonder if putting and idea out there, if only in my own mind, drives the universe to see it get done, lol.
I'd love to give it a try; I'm not bothered by it not being DinkC-happy at the moment. 😆 Not sure I'd go so far as to call myself a hater, but I'm no fan.
I'd love to give it a try; I'm not bothered by it not being DinkC-happy at the moment. 😆 Not sure I'd go so far as to call myself a hater, but I'm no fan.
I'd been sitting on the idea for months now, and managed to get your release compiled with sdl12-compat quite a while ago but only decided to attempt this a couple of weeks ago which must roughly coincide with the speed of transmitted thought from the other side of the world, so i'm inclined to believe it.
Eventually after some blood, sweat and treats I got it to compile and turn it into an AppImage! Assuming it works, the included data folder goes in ~/.config and includes the init.lua. A suitable refdir is included in the AppImage with all of the rewritten Lua scripts, but of course you can specify a different one with --refdir. Here's the relevant source tree that I don't expect anyone to get compiled and would err against anyway due to DinkC being broken, and here's my testmod which is mostly a media test but is written in Lua now as well.
Otherwise, the only other new features in this release are an item selector, and a jukebox.
Eventually after some blood, sweat and treats I got it to compile and turn it into an AppImage! Assuming it works, the included data folder goes in ~/.config and includes the init.lua. A suitable refdir is included in the AppImage with all of the rewritten Lua scripts, but of course you can specify a different one with --refdir. Here's the relevant source tree that I don't expect anyone to get compiled and would err against anyway due to DinkC being broken, and here's my testmod which is mostly a media test but is written in Lua now as well.
Otherwise, the only other new features in this release are an item selector, and a jukebox.
As an addendum, that AppImage is compiled with a glibc that's probably too new for most people at present. I'll attempt to get a more easily compilable source tree going like I said I would in the near future (will still need SDL-GPU though). In the meantime, I have DinkC working properly again (I think) except for the console. For the next release, instead of the command-line commands that were in the old 108.x release for turning Lua on and off, I will add "dinklua_enabled" as a parameter in Dink.ini so that people can explicitly set it, along with another one that will turn off DinkC.
Apart from that, there are a few remaining oddities in DinkLua, such as AlkTree nuts not disappearing upon pickup, and npcs wandering around aimlessly instead of disappearing, such as Martridge.
Apart from that, there are a few remaining oddities in DinkLua, such as AlkTree nuts not disappearing upon pickup, and npcs wandering around aimlessly instead of disappearing, such as Martridge.
I appreciate that you intend to make the AppImage version as compatible as possible. That should increase the number of our Linux Dink users that can use this more feature rich version of the Dink Engine and associated elements.
Sorry for not getting back to you about this, I have a tendency to forget things when they're out of sight, and I don't really come here very often in the first place, so I didn't think to come back and check on things since I left my last message.
And then there's the matter of my browser marking the download as having a virus/malware. Now I don't think you're trying to do anything malicious here, but it's still kind of worrisome. 😅
And then there's the matter of my browser marking the download as having a virus/malware. Now I don't think you're trying to do anything malicious here, but it's still kind of worrisome. 😅
Huh, tested the download. Similar warning. Latest stable version of Firefox. As for tha AppImage, I can't test it since I don't have any Linux distro installed, just plain Windows 11.
you might wanna upgrade to windows vista.
The old Google "safe site" nanny filter strikes again... My self-hosted file distributor randomly died at some point so I went back to using catbox temporarily. I'll get another one set up soon, and also attempt to compile a Windows build and run it past my beta tester before releasing it. In the meantime, I've fixed some issues in init.lua relating to sound effects and "sp_custom", and have added a few more parameters for sound effects. I was going insane reading about metatables only to eventually realise it was just a spelling error.
I decided to ignore the warning and give it a shot, only to be met with another problem.
Turns out my system has glibc version 2.35. Oh well. 🤷♂️
$ ./yeoldedink-x86_64.AppImage freedink: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.38' not found (required by freedink) freedink: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by freedink) freedink: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by freedink) freedink: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.36' not found (required by /tmp/.mount_yeoldegYbAkF/usr/lib/libXdmcp.so.6)
Turns out my system has glibc version 2.35. Oh well. 🤷♂️
After much testing, it's time for v0.86. A big thank you to my usual test candidate . Much like 0.85, this is a dev build intended for those interested in DinkLua, rather than those who just want to run existing d-mods.
Changes from 0.85:
- DinkC functionality is restored, with Lua switched off by default to preserve compatibility.
- Lua may now be switched on for individual d-mods by altering dink.ini with the line "dinklua_enable", and dinkc off with "dinkc_off"
- All the existing new DinkC commands are now available in Lua. e.g. playavi() as dink.playavi()
- The console now has up/down history
- Added a whole ton of new SFX parameters that may be controlled from Lua.
- The FM synthesizer for ADLMIDI in MixerX builds can now be manually selected for the next played MIDI from the audio window. Choices include Nuked and DOSBox OPL3 emulators among others, however Nuked sounds the best.
Known issues:
- The DinkC console will not work for this release and will eject an error message instead. It should not cause a crash this time, however.
- Video playback may cause a crash even if you have FFMpeg installed.
- Launching with debug mode on will cause a crash if the path to debug.txt cannot be written to, such as for the main game.
Other remarks:
- The debug consoles will only appear for their respective languages if they're enabled in Dink.ini.
- The Lua console is not sandboxed in the same way scripts are for preventing direct file access etc, and does not run inputted commands as a script attached to sprite 1000 as DinkC does. Some features available to scripts are not yet accessible from the console.
Links:
- exe and DLLs along with a second exe with a much higher sprite limit (~100MB)
- x64 AppImage compiled on Ubuntu that should work on Phoenix's PC but has no MixerX or bundled freedink-data (~25MB)
- a source tree that might be easier for gokussj6 to compile (103MB)
- SkeLuaton, for making d-mods in Lua with (362KB)
- The testmod, updated with a new feature test and some other stuff to show off what may be done with Lua (34MB)
Due to the controversy surrounding catbox, this release will also be distributed as a torrent (magnet link). If it's not seeding I'm probably asleep.
Changes from 0.85:
- DinkC functionality is restored, with Lua switched off by default to preserve compatibility.
- Lua may now be switched on for individual d-mods by altering dink.ini with the line "dinklua_enable", and dinkc off with "dinkc_off"
- All the existing new DinkC commands are now available in Lua. e.g. playavi() as dink.playavi()
- The console now has up/down history
- Added a whole ton of new SFX parameters that may be controlled from Lua.
- The FM synthesizer for ADLMIDI in MixerX builds can now be manually selected for the next played MIDI from the audio window. Choices include Nuked and DOSBox OPL3 emulators among others, however Nuked sounds the best.
Known issues:
- The DinkC console will not work for this release and will eject an error message instead. It should not cause a crash this time, however.
- Video playback may cause a crash even if you have FFMpeg installed.
- Launching with debug mode on will cause a crash if the path to debug.txt cannot be written to, such as for the main game.
Other remarks:
- The debug consoles will only appear for their respective languages if they're enabled in Dink.ini.
- The Lua console is not sandboxed in the same way scripts are for preventing direct file access etc, and does not run inputted commands as a script attached to sprite 1000 as DinkC does. Some features available to scripts are not yet accessible from the console.
Links:
- exe and DLLs along with a second exe with a much higher sprite limit (~100MB)
- x64 AppImage compiled on Ubuntu that should work on Phoenix's PC but has no MixerX or bundled freedink-data (~25MB)
- a source tree that might be easier for gokussj6 to compile (103MB)
- SkeLuaton, for making d-mods in Lua with (362KB)
- The testmod, updated with a new feature test and some other stuff to show off what may be done with Lua (34MB)
Due to the controversy surrounding catbox, this release will also be distributed as a torrent (magnet link). If it's not seeding I'm probably asleep.
Well, you're right that it "works" on my PC, in that it doesn't give annoying GLIBC errors anymore, but I still can't get it to run. This is what I get when I try:
It looks like it can't find a font file, but it's not being particularly helpful in telling me which one or where it's looking for it.
$ ./yeoldedink-x86_64.AppImage Warning: Missing charsets in String to FontSet conversion Please select your main data location Select folder from /home/alex/yeoldedink086lua (esc+enter to cancel): yeoldedink ERROR: Could not load settings! Will create upon exit yeoldedink-x86_64.AppImage: imgui_draw.cpp:2202: ImFont* ImFontAtlas::AddFontFromFileTTF(const char*, float, const ImFontConfig*, const ImWchar*): Assertion `(0) && "Could not load font file!"' failed. Stack trace (most recent call last): #14 Object "[0xffffffffffffffff]", at 0xffffffffffffffff, in #13 Object "./yeoldedink-x86_64.AppImage", at 0x55c0bb7b52e4, in #12 Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7fe1aca35e3f, in __libc_start_main #11 Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7fe1aca35d8f, in #10 Object "./yeoldedink-x86_64.AppImage", at 0x55c0bb7ad991, in main #9 Object "./yeoldedink-x86_64.AppImage", at 0x55c0bb7ac399, in #8 Object "./yeoldedink-x86_64.AppImage", at 0x55c0bb7edaf4, in #7 Object "./yeoldedink-x86_64.AppImage", at 0x55c0bb803e7f, in #6 Object "./yeoldedink-x86_64.AppImage", at 0x55c0bb8020cc, in #5 Object "./yeoldedink-x86_64.AppImage", at 0x55c0bb888562, in #4 Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7fe1aca45e95, in __assert_fail #3 Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7fe1aca3471a, in #2 Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7fe1aca347f2, in abort #1 Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7fe1aca4e475, in raise #0 Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7fe1acaa2a7c, in pthread_kill Aborted (Signal sent by tkill() 432 1000) Aborted
It looks like it can't find a font file, but it's not being particularly helpful in telling me which one or where it's looking for it.
It's either looking for Roboto-Medium.ttf (unless you changed it in the config file) or NotoEmoji-VariableFont_wght.ttf. Did you move the included ancillary data folder to ~/.config? They should both be in there.
Nope, I'm a colossal dolt who didn't read the readme.
Unfortunately, AppImages are sandboxed in a way in which they can't look next to their current path to find stuff, meaning that ~/.config is hard-coded on GNU/Linux builds. The Freedink-data package should still be in the repos on Debian etc in case you don't want to have to pick it each time.
all these issues only exist due to linux.
I still suspect that a good number of our (relatively recent) first time users are users of Linux, because the original Dink Smallwood Game is available as a part of (or as a very easy addition to) most Linux distros.
The same cannot be said about Windows. In fact, I suspect you'd have to really go out of your way to find a complete .exe and data file set for the original game that you can download that is not part of the (frankly rather obscure) Dink Network or Robinson Technologies websites.
How many people just happen to come across this OLD game otherwise?
Also, don't forget the port of DinkSmallwood HD to Android is (at least in large part) a Linux port.
The same cannot be said about Windows. In fact, I suspect you'd have to really go out of your way to find a complete .exe and data file set for the original game that you can download that is not part of the (frankly rather obscure) Dink Network or Robinson Technologies websites.
How many people just happen to come across this OLD game otherwise?
Also, don't forget the port of DinkSmallwood HD to Android is (at least in large part) a Linux port.
boom roasted. The Windows builds are actually the most difficult to get compiled now for various reasons. Anyway, I've updated The Guide with various notes for the newest release.
Also Phoenix, if you do manage to get it working i'd like to know if everything on the DinkLua front is as you expected, or if there are any glaring flaws or oversights etc. I'm thinking of making it so that future releases save Lua globals to disk alongside conventional saves. Right now the Lua state is completely lost once it's closed.
Also Phoenix, if you do manage to get it working i'd like to know if everything on the DinkLua front is as you expected, or if there are any glaring flaws or oversights etc. I'm thinking of making it so that future releases save Lua globals to disk alongside conventional saves. Right now the Lua state is completely lost once it's closed.
they're the hardest because linux is bad.
The Windows builds are now the hardest to get compiled because Linux is bad?
I guess it'd be naive to think Skurn is always logically consistent. But from another perspective, who is?
As much as I'd love to test this thing to death for you yeoldetoast, I've got personal struggles that stop me from even taking proper care of myself, so I wouldn't hold my breath. But yeah, there's a reason I hooked Lua into the same global variables as the Dink engine supports, so you could save them. Lua globals can be arbitrary Lua data, which I think is much too complex to save to disk very easily.
Ah I see, good luck and take care. I shall attempt to hold my breath anyway. It looks like globals are just a table in Lua so they're probably capable of being dumped to disk.
As for an dev update, I'm currently looking into fancy text boxes like what Seth has.
As for an dev update, I'm currently looking into fancy text boxes like what Seth has.
A while back now I also started upon a fork of Freedinkedit, and implemented a few features into it for ease of use as well as fix some bugs along the way. Due to the apparent lack of interest in d-modding, I decided not to develop it much further or release it in any form until now, and just kept it for my own personal use to test yeoldedink with before its map-editing features were developed.
I've migrated the build system to Meson which should make it much easier to compile on GNU/Linux and macOS etc. Basic instructions are provided on the page. It will even compile on a RasPi4 but will probably crash unless you have a 2GB model or above. Anyway, due to the aforementioned reasons, there will not be any formal releases.
You have been warned!
I've migrated the build system to Meson which should make it much easier to compile on GNU/Linux and macOS etc. Basic instructions are provided on the page. It will even compile on a RasPi4 but will probably crash unless you have a 2GB model or above. Anyway, due to the aforementioned reasons, there will not be any formal releases.
You have been warned!
I've made a few updates that i'll push to the repo at some stage. It turns out the minimap preview's slowness was due to the 60 FPS frame limiter. Turning it off means that even large maps now only take a few seconds to fully render...
I've also implemented a new feature that saves entire maps to one giant PNG. Here's a full-sized Mystery Island. If there are any d-mods you've ever wanted to have rendered at full size, now's the time to ask!
I've also implemented a new feature that saves entire maps to one giant PNG. Here's a full-sized Mystery Island. If there are any d-mods you've ever wanted to have rendered at full size, now's the time to ask!
That sounds like a great feature that would be very useful for walkthroughs. I'd love to see full-sized maps of Cloud Castle 2 : Scarab, Cast Awakening Part 1 : Initiation, and I, Kara Gu. A long time ago, I actually began working on a walkthrough for Initiation. I believe I made a map of an entire level by freezing every sprite and having an invisible Dink walk to each screen. Then I would take a screenshot, and assemble all of my screenshots into a single map once I was done. Your way sounds so much easier though.
Sadly, I have very little time for Dink at the moment, and once I actually have time for it I will owe SlipDink a new Periculo Island playthrough. So these walkthroughs are not for tomorrow.
But hey, after being around twenty years late, I guess nobody's actually expecting those anymore, right?
Sadly, I have very little time for Dink at the moment, and once I actually have time for it I will owe SlipDink a new Periculo Island playthrough. So these walkthroughs are not for tomorrow.
But hey, after being around twenty years late, I guess nobody's actually expecting those anymore, right?
Half the reason I implemented this feature was to figure out how to traverse that maze in Ikaragu, in fact. Here's a few i've done so far with an obligatory dial-up warning, as some of these are up to 50MB and all are uncropped.
Prelude
Cloud Castle 2
Ikaragu
Mayhem
Cast Initiation
Periculo just in case inspiration strikes tomorrow.
Prelude
Cloud Castle 2
Ikaragu
Mayhem
Cast Initiation
Periculo just in case inspiration strikes tomorrow.
Outstanding work, thank you very much!
Half the reason I implemented this feature was to figure out how to traverse that maze in Ikaragu, in fact.
Strictly speaking, one could say that there are several maze-like places in I, Kara Gu; but I'd be willing to bet that you're talking about the Cave of Trials/Cave of Tribulations, which is probably the most confusing maze in the game.
Half the reason I implemented this feature was to figure out how to traverse that maze in Ikaragu, in fact.
Strictly speaking, one could say that there are several maze-like places in I, Kara Gu; but I'd be willing to bet that you're talking about the Cave of Trials/Cave of Tribulations, which is probably the most confusing maze in the game.
Ah yes, THAT maze, I should have capitalised. Anyway, in the lead-up to the imminent release of 0.9, I have (re)uploaded some old Python utilities I wrote a number of years ago when I was still figuring out Dink's data formats. Some of them do vaguely interesting things, such as photohard.py which was written 18 months ago and is the most recent of what's in there.
In the meantime, however, Duckbench is progressing nicely, and demonstrates the performance gains of the new Y-sorting algo. The old one only gets around 2,000 on my old crappy i7.
In the meantime, however, Duckbench is progressing nicely, and demonstrates the performance gains of the new Y-sorting algo. The old one only gets around 2,000 on my old crappy i7.
The score it gives you is basically the amount of sprites you can reliably have going simultaneously, sort of. Here are some scores I have collected so far on hardware I have been testing it on prior to release:
RasPi3 in kms/drm mode on Lite image - 1,006
Windows 7 - Xeon X5670 - 7,000
macOS - i7 3615QM - 9,782
Windows 10 - i5 6400T - 13,063
Windows 10 - AMD 2500U - 13,742
Windows 10 - overclocked i7 3770k - 20,000
When I can get over the last few minor hurdles and release 0.9, it would be interesting to see what someone with a high-range CPU from the last few years can get.
RasPi3 in kms/drm mode on Lite image - 1,006
Windows 7 - Xeon X5670 - 7,000
macOS - i7 3615QM - 9,782
Windows 10 - i5 6400T - 13,063
Windows 10 - AMD 2500U - 13,742
Windows 10 - overclocked i7 3770k - 20,000
When I can get over the last few minor hurdles and release 0.9, it would be interesting to see what someone with a high-range CPU from the last few years can get.
bro imagine overclocking your cpu to have more sprites in dink
>When I can get over the last few minor hurdles and release 0.9, it would be interesting to see what someone with a high-range CPU from the last few years can get.
Can't wait for that > : )
Can't wait for that > : )
I'm in the process of re-implementing the DinkC console at the moment, and am realising I probably shouldn't release it with an unlimited sprite cap due to the presence of pseudo sprite 1000, commonly used for cross-screen processes. The hard limit for sprites might have to be 999 in which case Duckbench ain't gonna happen.
Aw, such a good opportunity to introduce new and exciting bugs into Dink
Just think how much fun it would be for D-Mod authors trying to track down the cause of the weird behaviour this might create!
Just think how much fun it would be for D-Mod authors trying to track down the cause of the weird behaviour this might create!
It would be a case of "script_attach(1000) when real sprite 1000 shows up ". It's definitely something that could be worked around by having new sprites assignments just skip index 1000, but in the short-term I don't want to find that out it breaks scripted warps or something.
At this point, however, I will most likely release an uncapped exe as a secondary release with a big fat warning on it somewhere, as a replacement for the old unofficial benchmark of pressing space in DinkEdit while holding a stopwatch is long overdue.
At this point, however, I will most likely release an uncapped exe as a secondary release with a big fat warning on it somewhere, as a replacement for the old unofficial benchmark of pressing space in DinkEdit while holding a stopwatch is long overdue.
After many trials and tribulations, YeOldeDink 0.9 brings many changes and new features and is a general release recommended for all users.
Bugfixes:
* Fixed a bug introduced in 0.85 in which screen scripts would run twice on occasion, and do funny things such as creating two Jacks in Jack and Maria's house.
Changes:
* Overhauled the sprite editor/viewer and split it off into a separate window.
* The system information window shows you a little more system information
* Bumped up Dear ImGui to the newest release and made it save settings in the ancillary data path rather than next to the executable.
* Bumped up MixerX as well which resolves minor problems with certain tracker files, makes the OPN output sound nicer, and allows for PXTONE ptcops with playmidi().
* The twirling arrows in choice menus will use the maximum amount of frames in the sequence rather than restarting at 7, should you want to replace them.
* Initfont will also search for TTF files in the dmodfile path if it can't find them elsewhere, with Fontconfig lookup also enabled on Windows.
* Removed some useless DinkC-equivalent trigonometric and other mathematical functions from Lua.
* The DinkC console should operate as it did in 0.8 and earlier and has up/down history too.
* The sprite limit is set to 999 in case of emergency.
New features:
* Added dink.set_music_tempo(float tempo) to Lua. 1.0 is the default and 0.5 is half etc.
* Added dink.is_music_playing() to Lua to return true or false.
* Added dink.get_last_sprite() to return the number of the highest sprite created, along with dink.get_fps() to get frames per second for the sake of Duckbench.
* The "speed" menu (hidden behind dev mode) has two new options within; The first is "remove frame limiter" which will give you max frames and allow you to run around very fast assuming you aren't Vsync-locked by SDL2. The second is "Use old sprite ranking" which switches back to the original much slower Y-sorting system.
* The "quick save" menu now has an option to autosave to slot 10 every time you walk to a new screen. Requires transition effect on in order to activate.
* The ADLMIDI or OPNMIDI engine can be set from yedink.ini. Set them to zero to enable Nuked which is the best-sounding of the FM emulators. If you have a decrepit PC and experience crackling, set them to -1 instead to use the defaults.
* The SoundFont for FluidSynth can be set from yedink.ini, and is searched for in the ancillary data location next to yedink.ini. Included is good old TimGM6MB.sf2 to start you off with, particularly for map.mid in Mystery Island 33 seconds in. Set it to zero (0) to use SDL_SOUNDFONTS environment var instead.
Technical changes:
* Updated the build system from Autotools to Meson and messed with the internal DinkC function-binding system.
* Windows releases now contain far fewer DLLs (10 vs 50+)!
* SDL-GPU and MixerX are optional build dependencies and will allow you to still compile with reduced functionality. Please see the included readme for build instructions.
* Added spdlog and cereal as build dependencies. Please install them from your package manager if you're going to attempt to compile, as Meson's wrap system for auto-installation doesn't always work too great.
Known issues:
* The OpenGL renderer will look weird in windowed mode unless you change to full-screen and back, assuming it works at all.
* The translation system will not translate text for the time being.
* If you have an old CPU such as a Core2Duo it may not launch because I switched on compiler optimisations, in which case do nag for a recompile.
Links:
* exe and DLLs (~40MB)
* Source archive tar.xz (24MB)
* AppImage by request only
* Also on Google Drive this time
Bugfixes:
* Fixed a bug introduced in 0.85 in which screen scripts would run twice on occasion, and do funny things such as creating two Jacks in Jack and Maria's house.
Changes:
* Overhauled the sprite editor/viewer and split it off into a separate window.
* The system information window shows you a little more system information
* Bumped up Dear ImGui to the newest release and made it save settings in the ancillary data path rather than next to the executable.
* Bumped up MixerX as well which resolves minor problems with certain tracker files, makes the OPN output sound nicer, and allows for PXTONE ptcops with playmidi().
* The twirling arrows in choice menus will use the maximum amount of frames in the sequence rather than restarting at 7, should you want to replace them.
* Initfont will also search for TTF files in the dmodfile path if it can't find them elsewhere, with Fontconfig lookup also enabled on Windows.
* Removed some useless DinkC-equivalent trigonometric and other mathematical functions from Lua.
* The DinkC console should operate as it did in 0.8 and earlier and has up/down history too.
* The sprite limit is set to 999 in case of emergency.
New features:
* Added dink.set_music_tempo(float tempo) to Lua. 1.0 is the default and 0.5 is half etc.
* Added dink.is_music_playing() to Lua to return true or false.
* Added dink.get_last_sprite() to return the number of the highest sprite created, along with dink.get_fps() to get frames per second for the sake of Duckbench.
* The "speed" menu (hidden behind dev mode) has two new options within; The first is "remove frame limiter" which will give you max frames and allow you to run around very fast assuming you aren't Vsync-locked by SDL2. The second is "Use old sprite ranking" which switches back to the original much slower Y-sorting system.
* The "quick save" menu now has an option to autosave to slot 10 every time you walk to a new screen. Requires transition effect on in order to activate.
* The ADLMIDI or OPNMIDI engine can be set from yedink.ini. Set them to zero to enable Nuked which is the best-sounding of the FM emulators. If you have a decrepit PC and experience crackling, set them to -1 instead to use the defaults.
* The SoundFont for FluidSynth can be set from yedink.ini, and is searched for in the ancillary data location next to yedink.ini. Included is good old TimGM6MB.sf2 to start you off with, particularly for map.mid in Mystery Island 33 seconds in. Set it to zero (0) to use SDL_SOUNDFONTS environment var instead.
Technical changes:
* Updated the build system from Autotools to Meson and messed with the internal DinkC function-binding system.
* Windows releases now contain far fewer DLLs (10 vs 50+)!
* SDL-GPU and MixerX are optional build dependencies and will allow you to still compile with reduced functionality. Please see the included readme for build instructions.
* Added spdlog and cereal as build dependencies. Please install them from your package manager if you're going to attempt to compile, as Meson's wrap system for auto-installation doesn't always work too great.
Known issues:
* The OpenGL renderer will look weird in windowed mode unless you change to full-screen and back, assuming it works at all.
* The translation system will not translate text for the time being.
* If you have an old CPU such as a Core2Duo it may not launch because I switched on compiler optimisations, in which case do nag for a recompile.
Links:
* exe and DLLs (~40MB)
* Source archive tar.xz (24MB)
* AppImage by request only
* Also on Google Drive this time
In that Google Drive folder is another exe from the same source tree with a sprite limit of around 100,000 and a bat file for launching Duckbench that I'll put it on Catbox too just in case. For best results, the sprite sort algo should be set to the new one, and the frame limiter should be off while it's running. You may need to have it on initially though in order to walk around reliably to talk to the duck to set it going.
I should also mention that for most d-mods run using the normal exe, the Y-sort algo should be set to the old one, as it seems to not play nice with certain editor sprites for reasons I haven't fully ascertained yet.
I should also mention that for most d-mods run using the normal exe, the Y-sort algo should be set to the old one, as it seems to not play nice with certain editor sprites for reasons I haven't fully ascertained yet.
> is a general release recommended for all users.
If you're serious about this, I might (might!) work on and release a new DMOD using Lua to script it, since never wanting to deal with DinkC again was one of my major roadblocks for doing more Dink stuff. The "downside" of course being that it'll only work with your engine. ?
If you're serious about this, I might (might!) work on and release a new DMOD using Lua to script it, since never wanting to deal with DinkC again was one of my major roadblocks for doing more Dink stuff. The "downside" of course being that it'll only work with your engine. ?
By that I mean that all the various bugs introduced by me copying and pasting in your scripting abstractor have most likely been resolved to the point where it's invisible to the user unless otherwise specified, and under normal circumstances it should run as 0.8 did when it was just DinkC, except for a few debug log entries I should sort out.
>The "downside" of course being that it'll only work with your engine. ?
And of course your old source tree . Although if you went really nuts you could double-up with *.c scripts.
I gotta admit though, after using DinkLua for a few minutes, I never want to go back to DinkC except for the most minor of operations. Having loops and proper vars really is a different world.
The source release should be pretty easy to compile compared to previously, although please do indicate if you get stuck or would like an AppImage of it.
>The "downside" of course being that it'll only work with your engine. ?
And of course your old source tree . Although if you went really nuts you could double-up with *.c scripts.
I gotta admit though, after using DinkLua for a few minutes, I never want to go back to DinkC except for the most minor of operations. Having loops and proper vars really is a different world.
The source release should be pretty easy to compile compared to previously, although please do indicate if you get stuck or would like an AppImage of it.
I dunno if I asked this prior and I currently don't have a PC setup to test, but did yeoldedink fix that bug in Freedink 1096 that returned the soundbank +1 (so you had to -1 to soundbank numbers before using sound commands or it wouldn't work).
It was a Freedink 1096 only bug I believe.
It was a Freedink 1096 only bug I believe.
Technically, it was fixed beforehand! Ghostknight caught it about the same time I did meaning all releases from 0.1 to 0.6 behave as per spec. For 0.7, the SFX system was gutted and replaced meaning all playsound invocations return unique IDs now instead of numbers between 1 and 20. In general, all known Freedink bugs have been resolved except for that one rare and elusive inventory-related crash that seems impossible to reliably reproduce.
I tried YeOldeDink and it replaced one of the files that WDED uses and make that stop functioning.... sigh
I have all the program files in the master "dink" folder
dink.exe
freedink.exe
yeoldedink.exe
WinDinkEditPlus2_drone.exe
etc
so I copied across the WDED version of SDL etc etc and got that working as that is my main editor for dmods. switching to DinkHD for playing and testing...
I have all the program files in the master "dink" folder
dink.exe
freedink.exe
yeoldedink.exe
WinDinkEditPlus2_drone.exe
etc
so I copied across the WDED version of SDL etc etc and got that working as that is my main editor for dmods. switching to DinkHD for playing and testing...
Yeh, some of the DLLs are different but same name. I tend to keep stuff in its own folder for that reason.
Yeah, not really legitimate when WDED runs fine regardless as to where it's placed. Nevertheless, The Guide, which i'm in the process of updating, has some tips and tricks for running DFarc3 with a subdir path.
Hey yeoldetoast. I've been playing around in YOD 0.9 and I think I've uncovered a bug. It seems to have to do with your new sprite ranking. Or, I should say, turning on "Use old sprite ranking" makes the bug go away, so I assume that's the problem. The issue seems to be related to redrawing hardness. Here are some examples from the original Dink game:
Before pushing bonca rock,
After pushing bonca rock:
"Old" sprite ranking,
"New" sprite ranking. Notice also how the bush lost its hardness, too.
Bridge to Terris:
"Old" sprite ranking,
"New" sprite ranking. Notice how the newly spawned hidden sprite has no hardness, so I can just cross the bridge without paying the toll.
Before pushing bonca rock,
After pushing bonca rock:
"Old" sprite ranking,
"New" sprite ranking. Notice also how the bush lost its hardness, too.
Bridge to Terris:
"Old" sprite ranking,
"New" sprite ranking. Notice how the newly spawned hidden sprite has no hardness, so I can just cross the bridge without paying the toll.
Yep, I mentioned it above but thanks for reminding me to actually fix it . I only figured out it wasn't as production-ready as I thought until after release. 0.91 will have it "inverted" in the debug menu instead which i'll ship as soon as I finish touch controls and the updated guide.
I have another update request if you're willing. There are some bugs and things missing in init.lua that should be fixed/included in upcoming versions; I put the changed script up on GitHub gists (with diff), if that helps. Hopefully my comments suffice, but feel free to ask me if you have questions.
To update, Phoenix has been tiring away diligently to update the Lua environment for Lua 5.4 while i've been attempting to resurrect the wasm build in the midst of making another demo to show off some more Lua capabilities. So far, most features are working including gamepad controls and MixerX for audio.
Also don't attempt to switch on debug mode while it's in full swing unless you have a supercomputer capable of handling a million additions to the javascript console per second as your fps will tank and the tab may hang. I'd also be curious to know if there were any d-mod authors itching to upload their creations to itch.io in this form, as it seems to work quite well so far.
Also don't attempt to switch on debug mode while it's in full swing unless you have a supercomputer capable of handling a million additions to the javascript console per second as your fps will tank and the tab may hang. I'd also be curious to know if there were any d-mod authors itching to upload their creations to itch.io in this form, as it seems to work quite well so far.
Dear god, that demo gives me Amiga/DOS Demoscene vibes
@GOKUSSJ6:
Me too! I owned 2 Amigas, centuries ago. Alas, they are gone now, as is nearly everything else Amiga.
Me too! I owned 2 Amigas, centuries ago. Alas, they are gone now, as is nearly everything else Amiga.
so like, is this version of freedink going to replace both dinkhd and freedink since both are abandoned?
and does that mean that, once yeoldedink is finished, toast disappears as well and doesn't maintain it and then *another* new source port is released that makes yeoldedink inferior and...
yeah, can we just have one version forever already
and does that mean that, once yeoldedink is finished, toast disappears as well and doesn't maintain it and then *another* new source port is released that makes yeoldedink inferior and...
yeah, can we just have one version forever already
Seth pushed an update quite recently that went unannounced. RTDink is in no way abandoned.
Ideally when it's finished and I disappear (1.0 release), it'll be feature-complete to the point where it won't really need any updates. More source ports are always welcome though. Something similar to the million variants of Doom would be best for everyone. Everything else is for the existing userbase of 6 people to decide.
Ideally when it's finished and I disappear (1.0 release), it'll be feature-complete to the point where it won't really need any updates. More source ports are always welcome though. Something similar to the million variants of Doom would be best for everyone. Everything else is for the existing userbase of 6 people to decide.
6 ppl huh. I can't help but think that once ya mention the Linux community about that project they would most likely make some nice stuff, specially when ya implemented LUA support.
EDIT: Having a Github/Gitlab page would also greatly help as well.
EDIT: Having a Github/Gitlab page would also greatly help as well.
not announcing an update is almost functionally identical to not updating at all. i had thought about using dinkhd recently and then thought...you know, this isnt actually up to date anymore is it?
Yeah six is a little optimistic. If itch.io goes well I may host all future releases there. They also have a jam feature which might be interesting to try out. Once the web build evens out, one could even submit their creation to something like this.
Skurn, you gotta be trolling, where were you when Seth released all those updates for DinkHD last year?! At the moment, I think DinkHD blows FreeDink out of the water.
I think I like YeOldeDink's MIDI soundfont better though...
I think I like YeOldeDink's MIDI soundfont better though...
Skorn trolling? Unlikely. Unfortunately, the user experience of RTDink is appallingly slow compared to Freedink or even 1.08 from a dev perspective. This becomes notably apparent when you're doing small minor iterative edits to a script, dink.ini, or map data etc and want to check the results.
By the time RTDink's finished checking for updates and you've skipped loading the save state to get to your title screen, you've already confirmed your scripts work in Freedink. I didn't even bother trying to get the background-changer working in PNGtions because I didn't want to have to wade through all those slow-as-molasses interface animations more than once.
>I like YeOldeDink's MIDI soundfont better though...
Heh. The included SoundFont is the one I nagged Seth to ditch and replace with GUGS because I thought it sounded bad. I only included it so that people would replace it with a nice-sounding one, and because it takes up minimal disk space Although it may just be that FluidLite is capable of rendering it better than FMOD ever did. MIDI playback is an afterthought in most libraries these days.
By the time RTDink's finished checking for updates and you've skipped loading the save state to get to your title screen, you've already confirmed your scripts work in Freedink. I didn't even bother trying to get the background-changer working in PNGtions because I didn't want to have to wade through all those slow-as-molasses interface animations more than once.
>I like YeOldeDink's MIDI soundfont better though...
Heh. The included SoundFont is the one I nagged Seth to ditch and replace with GUGS because I thought it sounded bad. I only included it so that people would replace it with a nice-sounding one, and because it takes up minimal disk space Although it may just be that FluidLite is capable of rendering it better than FMOD ever did. MIDI playback is an afterthought in most libraries these days.
>Unfortunately, the user experience of RTDink is appallingly slow compared to Freedink or even 1.08 from a dev perspective.
Ah, that makes sense, I do wish there was a flag you could send to RTDink to make it skip the update checks and all of that... Maybe I'll pester Seth about it :V
About the sound font, maybe it's just nostalgia on my part hah!
Sure, I could add a flag to skip stuff... it's really that slow?!
Also the other day I was thinking "why don't I have a hotkey like ~ or something that pulls up the debug log over the gameplay", currently you have to wade through menus to enable debug mode, then to open the log, it's really slow and clunky, but being able to see errors/msgs live during gameplay would probably be pretty useful if anybody actually wanted to use RTDink for devving.
Also the other day I was thinking "why don't I have a hotkey like ~ or something that pulls up the debug log over the gameplay", currently you have to wade through menus to enable debug mode, then to open the log, it's really slow and clunky, but being able to see errors/msgs live during gameplay would probably be pretty useful if anybody actually wanted to use RTDink for devving.
I would like that...
And would it be possible to change midi volume level, or music level with DinkC?
I kinda wrote a loop to set the volume on .wav files but not sure there's a way to do this with midi
And would it be possible to change midi volume level, or music level with DinkC?
I kinda wrote a loop to set the volume on .wav files but not sure there's a way to do this with midi
Sure.. like set_music_vol(0 to 100); I guess? This will be apply a modification to whatever the current music volume level is set by the user in the Options menu.
Does that mean it'll move the slider independently of what the user's set? I refrained from adding something like that due to implications of betrayal of trust. There are myriad personal reasons why they may already have the volume slider very low or even at zero that I don't believe scripters should be able to override. To me, that's like having a TV that can turn itself up or down without the remote.
I would mod whatever the options slider is currently set to - so if the options slider was set to 50%, dink script setting it to 50% would actually make it play at 25%. (Dink script should have no idea what the real music slider is set to)
It couldn't actually ever go higher than what the options slider is set to. So if the options is at 0, any set_music_vol command would be modifying the range between 0 and 0 so it could never turn on the music at all.
Changes in a DMOD would never modify the real slider.
It couldn't actually ever go higher than what the options slider is set to. So if the options is at 0, any set_music_vol command would be modifying the range between 0 and 0 so it could never turn on the music at all.
Changes in a DMOD would never modify the real slider.
Makes sense. I simply found the phrase "mods the volume slider" to be somewhat ambiguous.