Looking back through project commits, I see before there was tweaking with +1/-1 errors already with both the internal coordinate translation function and PMAP. If there is a bug, maybe it is not exactly where we think. Changing the PMAP function would be reverting previous fixes. So maybe worth a closer look.
I think part of the issue is that if we consider even default screen:
- physically pixel (0,0) occupies the area X=[0,1), Y=[0,1]
- but due to rounding the sample pixel is represented by logical coordinates X=(-0.5,0.5), Y=(-0.5,0.5)
Looking at just x coordinates to start with since it is the simpler of the x and y mappings.
Float to integer rounding:
- What is the default logical coordinate space of the screen due to rounding? (without any WINDOW statement)
- on a screen 640 pixels wide, the continuous logical coordinate space is [-0.5, 639.5)
- width of the logical coordinate space is 640 = 639.5 - (-0.5)
- float coordinates are mapped to discrete pixels (integers) in the range of [0, 639]
view (x1,*)-(x2,*)
- width = x2 - x1 + 1
- It occupies the same area as line (x1,*)-(x2,*)
- Defines the clipping window after rounding to integer
- clipping is performed on rounded integer values of coordinates
- For example (without WINDOW):
--- view (10, *), (100,*)
--- width = 100 - 10 + 1 = 91
--- logical coordinate space [9.5, 100.5) maps to [10, 100] physical
window (x1,*)-(x2,*)
- this is intended to define the limits of continuous logical coordinates
- width = x2 - x1
- So for our example of width = 640 , window (0,*)-(640,*) should be the equivalent statement to provide default logical coordinates
- I think x1, x2 can be considered the outer bounds of the continuous range.
So what we have is:
- WINDOW: mapping before rounding
- VIEW: clipping after rounding
I think it gets confusing here because we often talk about pixels discretely as point values X = 0, 1, ,2 ...
But they actually occupy space both on screen physically and in some logical coordinate space.
And we haven't really defined if we are talking about edges of pixels or centers, or something else like offsets due to rounding.
Translation Example (but no scaling):
- for example: window (-320, *)-(320,*) on our screen width of 640
- due to rounding, the current logical coordinate space will be (-320.5, 319.5)
view_w = 640
win_x = -320
win_w = 640
current PSET calculation:
- fx = ((x - win_x) * (view_w - 1)) / win_w
- fx = cint(fx)
- fx = clip(fx)
- return fx
- current PMAP calculation:
- fx = (x - win_x) * view_w / win_w
- return fx
Do either of these current calculation make sense? Do we get acceptable results only do rounding?
More to come, I think.