The Dink Network

Hey all,

For fun I have been modernizing WDE, but I am sure there are variants out there. As part of this, I have been playing with AI up-scaling of Dink Graphics for fun. However, it would appear, as expected, that this is rather useless and has minor impact to the user experience and further would require modifications to the dink engine even if feasible.

Currently, the best result I have found is with EDSR models, but those just provide minimal improvements. If anyone has any recommendations for models that not only upscale, but provide more detail, I am willing to implement them into an editor for use into the Dink Engine. (Example: Not just up processing the grass tiles, but adding more 'realistic' grass to the texture.) The up-scaling would have to be done during editing of the dmods and not during game-play as AI processing takes a decent amount of time. Current the new version of WDE processes the up-scaling 'on the fly' via a separate processing thread, but the Dink Engine can not support rendering the up-scaled graphics without modification as the game engine would need to know the ratio to which the graphics have been increased in size.

Looking for inputs, thoughts and feedback. Either way, I will be pushing the new source code out, which updates the codeset to use more secure functionality in the latest version of C++ and Direct2d.

Edit: I know you all want to see SimonK's bouncing boobs and dicks and what not in HD.

Cheers!

Hey there, I'd be interested in seeing what can be done. I'm in the process of doing my own graphics for Necromancer, sometimes with the help of AI, although in the end I usually just go into blender/Gimp and work things manually. I did update SOB and the naked ladies at the end for the Redux version.

I messed around with some upscaling models some months before Seth released the actual models. For Dink's graphics, I found 4x SGI and FSDedither Riven were some of the better ones. Although for best results it's a matter of trial and error.

An example of FSDedither Riven

@SimonK
AI, Necromancer and naked ladies. Welcome to the Dink Network in 2024...

bro no way is necromancer gonna have AI taint in it. no way, bro. no.

Holy moly, it's WC!

I'm not sure I'm a fan of AI upscaling usually, I think it tends to look weird most of the time, but go for it!

Edit: Huh, Yeoldetoast's examples are pretty good actually!

@WC
Hi! Wasn't exactly around when you were active, but it's always nice to see old Dinkers.

@drone1400
Doesn't have much to do about the actual topic, but here's a fact about me: I actually hate both AI upscaling and upscaling filters. But that's a matter of personal preference.

Well then here's another for comparison's sake. The first is an upscale of the church using 4x SGI and the second is a render of the same size. I also attempted to apply the 8-bit palette to the render, but it was indistinguishable in quality.

I will also say now that to increase the window size in dink by 2x or 4x etc would entail making a fork that would amount to a new engine, just about.

blizzard recently tried advertising warcraft 3: reforged with ai upscaled screenshots of the game. it was pretty obvious, too. orc peons were unknown masses of smeared pixels and the alliance barracks building's roof's shingles were completely changed from their original textures. none of this was in-game, of course. their response after being caught was "UH...UH THEY'RE UH, CONCEPT IMAGES. YES!"

the lesson here is, don't be blizzard. ai upscaling tech looks nasty.

Having a screen that is 1280 by by 960 would allow for graphics with finer detail, which I would like. Working with graphics that look good until they are scaled down to fit 640x480 (or 600x400 useable space) is a tad annoying.

Trouble with up-rez stuff is you get to see the errors, or mismatch errors more easily. Some of the tiling/UV mapping in the original graphics doesn't hold up to getting up-rez'd.

War3R itself is looking pretty nice now though. But the bonus campaign is my favorite bit of it and that isn't immediately available like it was in the original TFT release, which annoys me.

War2 Remastered is consistently hanging on me, too...

sigh

@SimonK Mhmmm.. a while back, I had this idea of a true DinkHD that would support sprites/tiles of "arbirtrary" resolution...

Basically, my idea was to have an additional parameter in the dink ini defining a sprite scaling factor, much like the windows DPI. At 100%, a sprite pixel would correspond to a game logical pixel. At 200%, 2 sprite pixels would correspond to a game logical pixel. *

Then for example, if you have a sprite that's 200x100 with its scale set to 200%, in a 640x480 game window it would be scaled down to 100x50. But in a 1280x960 window, all the 100% sprites would get scaled up accordingly, while the 200x100 sprite would maintain its full 200x100 resolution. Or if the game was running at 960 x 720, you'd have the normal sprites get scaled up 1.5x while the 200x100 sprite becomes 150x75. Etc.

* Or perhaps, it would be more intuitive to specify the exact "game pixel" size you want the sprite to have. Say you have the 200x100 sprite, but you define it as 50x25. Then at lower resolutions it gets scaled down, but at higher resolutions it should be more defined.

Incidentally, on DinkHD you can already do something like this by setting sprite's size below 100%. For example if sprite's size is 50 and game is on 1280×960 window then the sprite is just rendered at its original resolution (Or it would, if not for some other HD's quirks), while size 100 sprites are upscaled.

I have had annoying experiences with depth dot and hardness issues when changing size of sprites

Well how about that, it does indeed. Another discovery to add to Seseler's list. The render of the church was scaled to 40 in this instance. I'm assuming those edges in the screenshot are some sort of rounding error.

It's not particularly outstanding discovery as you just have to look at some downscaled sprites...

Agree'd. I am still playing with models (EDSR looks alright, but I want more!). However I need to write more code that will allow for ESRGAN models. I did write in code that figures out what areas of sprites are the old school 'shadows' and upscales them to a truly transparent shadow. Additionally I will need to add 'zoom' functionality into the editor. I can send a version of the editor for anyone who wants it, thought I am still working on some modernization and haven't tested all functionality. I figure if I can get a nice solution plugged into WDE, it shouldn't be hard to retrofit it into a dink engine. The engine could theoretically upscale the graphics in the background and cache them for future use. That or we can run dmods through a batch process to handle that.

@drone1400

My newest version of the editor has a built in 'cache' of the upscaled graphics that are generated. In the cache, it stores path, the image, the original size, and the new upscaled size for comparison for rendering.

> Incidentally, on DinkHD you can already do something like this by setting sprite's size below 100%. For example if sprite's size is 50 and game is on 1280×960 window then the sprite is just rendered at its original resolution (Or it would, if not for some other HD's quirks), while size 100 sprites are upscaled.

There's an issue with hardness, iirc, sprite hardness does not get scaled with the sprite at all.

Edit: Also it would be annoying tweaking individual sprites instead of configuring them once in the dink.ini

For the hardboxes not scaling, since you usually only use the sprites on one scale you can just make it match the scale you intend to use to display the sprite.

But if one were willing to actually try to do an engine-level support for high-res sprites, I'd like if it didn't depend on dink.ini, but was something like (using the inter/save/save- as an example seq): the game checks if the sequence's graphics normally (i.e. first from d-mod folder, falling back for main game if d-mod does not have the seq), and if there's a [seq-name]-[frame-number]_x#.bmp (where # is integer > 1), then it would load that file as higher-resolution replacement for the original file. So, for example, for inter/save/save-01.bmp, if there is inter/save/save-01_x2.bmp at the same directory, then it'd load the latter file and downscale it to ½-size when rendering.
This would allow one to add hi-res graphics for the main game and have them work with the existing D-mods without modifying the D-mods. If an engine added this, it should not load hires-graphics from the main game if the d-mod has nornal-res-graphics of the same name, as they're likely different from the main game's.

Seseler,

Here is how my beta build currently does it (searches for AI upscaled graphics, then a .bmp, then a fastfile starting in the dmod folder, and then falling back to the dink folder). It will allow for upscaling of hardness as well, but that doesn't do anything on the game engine side.

I peeked at the Dink source code today and almost stroked out... looks like a full rewrite.

shared_ptr<GRAPHICQUE> searchForGraphic(string location, D2D1_COLOR_F color_key) {
shared_ptr<GRAPHICQUE> que = nullptr;
for (const auto& path : { dmod_path, dink_path }) {
#ifdef AI_UPSCALE
que = gfx->ReadGraphicFromStore(path, location); //find potential AI upscaled graphic
if (que) return que;
#endif
fs: ath bmp_file = path / location;
if (fs::exists(bmp_file)) { //if the file is there, load it.
que = gfx->loadBitmapFromPath(bmp_file.wstring().c_str(), color_key);
}
else {
//if not, find it in the dir.ff
auto bData = extractBitmap(bmp_file);
if (bData.size) {
que = gfx->LoadBitmapFromData(bData, color_key);
}
}
if (que) {
que->path = bmp_file;
que->isUpscaled = false;
return que;
}
if (path == dink_path) break; //this is the dink path, no further searching required
}
return que;
}

>I peeked at the Dink source code today and almost stroked out
Yeah, that is fairly typical reaction.

Update. I just got pytorch enabled in WDE and am running 4x-FSDedither-Riven on all the dink graphics. Stay tuned....

Edit: Sprites look decent. Terrain is not so great. I could argue the terrain is 'better', but it has a grainy texture to it and make drawing the minimap look less than stellar. I am going to play with training a few models to see if I can improve the results.

Also: Does dink have a discord?

Are yes, the tiles... currently my frustration, the whole repeat of 100 by 100 px. Every time I try to use something like 200x200 I get caught with the various corners or hills where you want to move away from a vertical or horizontal line

"Does dink have a discord?"

Yes - clicky on that Chat button up top there ^^^