search

hajimehoshi / ebiten

Ebitengine - A dead simple 2D game engine for Go
https://ebitengine.org
Apache License 2.0
11.02k stars 660 forks source link

ebitenutil: DebugPrint ignoring image origin #2977

Closed tinne26 closed 4 months ago

tinne26 commented 6 months ago

Ebitengine Version

v2.7.2

Operating System

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 commented 6 months ago

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 commented 6 months ago

I feel like this is an expected behavior.

Zyko0 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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