ZDoom

Fixed. There was a major f*ckup in the coordinate calculation code (multiplication instead of division by a fixed point value) thanks to a very broken code submission 10 months ago. It was showing problems before but my first attempt to fix it was clearly not correct.

Ironically the broken code was supposed to fix the bug being originally reported here... :?

I haven't been playing much Doom since then, otherwise I might have encountered oddities elsewhere, too.

Can't say yet. I won't have time to investiagate until mid week.

And is there a solution for this? Because it's rather a gzdoom related problem.

Otherwise is it OK to post here gzdoom bugs on zdoom forum?

[quote="cocka"]Why has this topic been moved to the Closed Bugs forum?[/quote]

Because there was nothing to investigate. Bug reports that don't get any response by the original poster even after asking for feedback can't just linger around indefinitely.

Why has this topic been moved to the Closed Bugs forum? It's a still existing problem.

Only udmf scaling was used:

Zdoom: http://imageshack.us/a/img6/5219/fhwp.png

GZdoom: http://imageshack.us/a/img835/2276/ehdt.png

Zandronum: http://imageshack.us/a/img853/4718/d7cf.png

[quote]unless someone can post an example for this problem[/quote]

But I can show you the map from where the screenshots were taken. Here it is:

[attachment=0]udmfmap.wad[/attachment]

OK, let's update this topic.

This is not an udmf-specific problem. This is obviously a bug related to GZDoom.

Proof:

http://forum.drdteam.org/viewtopic.php?f=24&t=5943

It doesn't matter whether you use udmf or hexen format, problem is the same. ZDoom does offsetting perfectly, but GZDoom doesn't.

The file is gone, so unless someone can post an example for this problem I won't be able to do anything about it.

Interesting. I tried ZDoom and you know what? Things are scaled correctly. It seems there's an issue with GZDoom. Or it could be my configuration, but I haven't changed anything in [i]years.[/i]

Here is a test map. I'm sorry it's so weird, it's a heavily cut down version of my map. The texture exhibiting this problem is BIGDOOR7, over the little hallway.

http://www.sendspace.com/file/34fzxh

ZDoom came first, so whatever it does is correct. If GZDoom deviates from that it's a bug. If the DB plugin deviates, it's also a bug.

And no, I can't diagnose anything without seeing the map.

Well honestly, basic division dictates that it is correct. The space for that texture is 128x48. 128 divided by 48 produces 2.6666666666666666666666666666667 in microsoft's calculator, which DB2 truncates to 2.667, I assume for the sake of rounding it off.

Here. I defined a new version of that texture with a Y-scaling factor of 2.666... (and shortened to 2.667) and tried it out in my map, after removing UDMF internal scaling from the line. This produces even more bizarre results. Usually, TEXTURES scaling doesn't produce any errors.

[img]http://i.cubeupload.com/YHDSrk.jpg[/img]

If you still can't think of any way to diagnose a problem, I guess I can strip down my map to just a few problem areas for you to examine.

Without seeing your map it's impossible to tell if it's a problem with ZDoom, GZDoom or Doombuilder.
If it's the same in ZDoom and GZDoom the plugin is at fault.

Okay, I've been witnessing this problem for a few months now. I extensively make use of UDMF's internal texture scaling in my maps. These show up just fine in Doom Builder 2, but in-game, there's quite a few oddities. Here's an example.

[img]http://i.cubeupload.com/aOBBc4.jpg[/img]

This texture is 128x128. The X scaling is not changed, but I used a Y scaling factor of 2.667 to make it fit this upper texture area. As you can see, it looks just fine here. But in-game...

[img]http://i.cubeupload.com/TAT9Lt.jpg[/img]

Yeaaah...

When I run GZDoom, it says "NPO2 textures supported," so I'm not sure what's up. Is scaling broken or something?