ebitenutil: DebugPrint ignoring image origin

[tinne26]

Ebitengine Version

v2.7.2

Operating System

• Windows
• macOS
• Linux
• FreeBSD
• OpenBSD
• Android
• iOS
• Nintendo Switch
• PlayStation 5
• Xbox
• Web Browsers

Go Version (go version)

go1.22.2

What steps will reproduce the problem?

Using ebitenutil.DebugPrint() on an image with non-zero origin.

What is the expected result?

Text drawing on the top left.

What happens instead?

Text being cut or not visible.

Anything else you feel useful to add?

E.g., see https://github.com/hajimehoshi/ebiten/blob/v2.7.2/ebitenutil/debugprint.go#L48C3-L48C32 trivially replace with:

bounds := image.Bounds()
DebugPrintAt(image, str, bounds.Min.X, bounds.Min.Y)

[tinne26]

I mean, I'm unsure of the exact desired behaviors, in some cases DebugPrintAt() might also need some changes, in which case the fix would be more involved?

[hajimehoshi]

I feel like this is an expected behavior.

[Zyko0]

I feel like this is an expected behavior.

Yes, I think it's for the same reason that if you do DrawImage to a sub-image, you also have to translate the origin of the destination sub-image explicitely.

edit: maybe this is not really desirable (?) but at least it seems consistent with the other API behaviours regarding sub-images

[tinne26]

I mean, the documentation says:

DebugPrint draws the string str on the image on left top corner.

There are two possible interpretations of this:

1. "[...] draws the string on image's top-left corner", in which case, top-left corner is the image's origin, and the function description doesn't match its current behavior, as an image origin is image.Bounds().Min.
2. "[...] draws the string on image, at coordinates (0, 0)", in which case, the current documentation is very ambiguous and easy to misinterpret. Notice that (0, 0) is not even the top-left corner of the screen, but technically, the top-left corner of the parent of image. So even trying to rewrite as "[...] draws the string on image, on the top-left corner of the screen" wouldn't be technically correct. An alternative description would be "with no translation".

I'm fine with current behavior being the desired one, but I don't think the most reasonable interpretation of the function description matches the current behavior.

Regarding Zyko's comment, DrawImage() doesn't have this problem, and in fact, you depend on GeoM, which has this explicit documentation:

// The default (zero) value is identity, which draws the image at (0, 0).

So, I think there is no parallel with DrawImage() here, this is purely on DebugPrint()'s description / behavior mismatch.

[hajimehoshi]

Ok so I'd like to update the documentation side.