adventuregamestudio / ags

AGS editor and engine source code
Other
700 stars 160 forks source link

"Black Morph" text glitches #1909

Closed ivan-mogilko closed 6 months ago

ivan-mogilko commented 1 year ago

This ticket is a recreation of #835. Unfortunately, in the original ticket the problem was not explained well from the start, and diagnosing did not progress at first. For that reason it contains a number of unrelated information and screenshots. This may cause misunderstanding for anyone who reads it. Another thing, the eventually posted screenshot which was displaying the actual problem is not longer available, but fortunately I found a copy saved on my disk.


The problem

@rofl0r reported text glitches in the game "Black Morph". The game may be found in AGS game database (link)

Following is a screenshot of the problem, made in the very first room after starting a new game, when you interact with the "Reeds" hotspot: blackmorph-rofl0r Following is how the text is supposed to look like: blackmorph2-ags360-linux

In other words, a text is drawn with some parts cut off. Also note that parts of the textbox's frame is also either not drawn, or painted over with black color.

According to the initial report, the issue appeared starting with AGS 3.5.0; and game looked fine in 3.4.x engine. The issue was noticed on a Linux system (my guess, it's "Sabotage Linux", specifically). It persists regardless of a graphics driver: both Software and OpenGL renderers were tested with the same result.

The engine was built using common makefile, found in the Engine dir (not using cmake).

As a guess, this may be related to a change to alfont and/or freetype library: before 3.5.0 AGS was linking to a system freefont library on linux, but starting with 3.5.0 we have a particular version of freefont embedded into the engine.

Similar problem was not reported by anyone else since, which makes it seem a niche case. @rofl0r suggested trying a linux distro that uses musl libc, such as "alpine linux". The suggestion is that the problem is caused by an undefined behavior in either alfont or freefont, and musl may be more sensitive to those.

Unfortunately, at that time, I failed to build all necessary libraries for 3.6.0 engine (e.g. SDL_Sound) on alpine linux, and because this was such a strange report, left it for later, and forgot about it eventually. In retrospect I could try building and testing a 3.5.0 engine instead too.


May be related (or not): #1438, #1939

messengerbag commented 1 year ago

Notice that it is not just the text that is distorted: the whole screen is wrong (or at least, the whole upper part). This can be readily seen in the dithering patterns of the background (e.g. on the cliffs above the text box).

ivan-mogilko commented 1 year ago

Speaking of potential bugs in ttf renderer (alfont), see description to #1939.

ericoporto commented 1 year ago

@ivan-mogilko , I think this error in particular is just downscaling.

ivan-mogilko commented 1 year ago

@ivan-mogilko , I think this error in particular is just downscaling.

This might have been a (uneven) scaling issue, but it's difficult for me to imagine how downscaling occured for this game. The game's native size is 240x135! The user who reported this mentioned he was playing both fullscreen and in window, in two different renderers. This was reported for 3.5.0 and 3.6.0 engines, and apparently in both cases they used default game's config, which (at least in 3.6.0) probably supposed to create a desktop-sized fullscreen or max-sized window with the game scaled up. I wish I've asked for a log back then to see how gfx mode initializes exactly.

AlanDrake commented 1 year ago

Couldn't this be a hardware/driver bug? Remember that time I had to switch D3D rendering to a texture because stretching was not doing its job properly? Maybe this is a similar case...

ericoporto commented 1 year ago

It could. I am also thinking if maybe there is a case where find_nearest_supported_mode in the graphics mode code, fails.

ivan-mogilko commented 6 months ago

@rofl0r it's been a long time since this problem was reported, but if you're still around and have a spare time, could you retest this game using the latest master branch?

Comparing your old screenshot and the correct game looks (as demonstrated above), it seems like the issue is not related exclusively to fonts, but a large chunk of the game screen is drawn with uneven scaling (at least he upper half). I've only been able to reproduce something similar if I reduce the game's window to less than its nominal resolution, but given it's 240x135, I find that unlikely to happen on purpose. Perhaps there are other combinations of display modes that may cause this (especially with "stretch to fit" setting).

If you still have same problem, could you post a log of the game, specifically where it prints the display mode, gfx filter, and "draw frame" size?

rofl0r commented 6 months ago

indeed, the problem seems gone in current engine version. for code archeology purposes, it would be interesting to see which exact commit fixed it via bisecting, but even compiling ags once takes almost too much time for my taste.