Following on from a bit of digging that I did as a result of this thread: viewtopic.php?f=123&t=74110
It seems as if UDB might not be aware of (G)ZDoom's special handling of graphics in the flats namespace that are bigger than 64x64 (or probably just power of 2 rather than just any increase in size - but I'm pretty sure that they have to be square... *I think*. So I think that 128x128 and 256x256 will do this, but 64x128 might not.
*-See edit at the bottom of the post* ).
I'm mentioning this here first, rather than on GitHub because it could just be that I have missed an option or something.
Anyway, one of the early implementations of hi-res graphics in ZDoom (and therefore carried into GZDoom) was that if you put a FLAT in a WAD that was bigger than 64x64 - e.g. 128x128 or 256x256, ZDoom would auto-scale it to behave like a 64x64 flat. This was designed waaaay back in the day when importing the graphic had to be in the FLAT format (RAW or whatever that format is) but this is still supported today even if the graphic is in the PNG format (as in the above linked thread).
So, anyway, here are a couple of examples.
This UDB screenshot shows a map - with no in-map scaling and no additional control lumps - with a 128x128 FLAT used on the floor, ceiling and a wall. The graphic is just a copy of DOOR9_2 imported into a WAD between F_* markers, in FLAT format and called TESTFLT1.
Obviously, the graphic is being shown as an unscaled 128x128 graphic.
In GZDoom it looks like this:
The graphic has been scaled to 64x64 and is effectively a hi-res flat/texture. This, as far as I know, is correct behaviour.
And just for completeness, here is the same map loaded with a PK3 resource. In this case, a colour-modified (just so I could be sure I'd loaded the right one) PNG copy of DOOR9_2 has been put in the Flats folder as TESTFLT1.PNG and it works in exactly the same way as the WAD version.
UDB
GZDoom
In case it helps, the map and resource files are attached. Unpack the zip and load the FlatMap.wad with either the FlatTest WAD or PK3.
So, I suspect that this is an unimplemented feature in UDB but I thought I'd check here first.
[edit] I've done a bit of testing, and GZDoom only seems to scale the graphic if it is 128x128 or 256x256. Bigger powers of 2 do not scale (e.g. 512x512), non powers of 2 do not scale (tested 192x192 and a few other random values) and non square versions (even if they are powers of 2 - e.g. 256x128, 64x128 etc) also do not scale.
Also, FWiW, smaller values (32x32) do not seem to scale up either.
So, I guess the short version of all of this is:
If a graphic in the flats namespace is 128x128 or 256x256, GZDoom autoscales it to behave like a hi-res 64x64 image. However, UDB does not seem to be aware of this. [/edit]