Is DISPLAY_CROPPED_AND_SCALING possible ? (with integer factor)

[dglaude]

Your software is great and works out of the box for the WAVESHARE_ST7735S_HAT.
My use case is to play pixel perfect Pico-8 but I would like a simultaneous HDMI display.

I want pixel perfect on the SPI LCD, but I want bigger that 128x128 on the HDMI.

So rather than to define my HDMI to be 128x128:
hdmi_group=2
hdmi_mode=87
hdmi_cvt=128 128 60 1 0 0 0

I would like a standard resolution, so that I can connect an HDMI screen.

So the idea would be to use a kind of DISPLAY_CROPPED_INSTEAD_OF_SCALING but every pixel from the LCD would match 4x4 or 5x5 ... or 8x8 pixels on the HDMI side.

That would require to define DISPLAY_CROPPED_AND_SCALING and a scaling factor.

In my case all the pixels should be of the same color, but I guess otherwise the GPU would average the color in the downscaling process... can it do that?

Do you think it would be easy to implement?
I am looking in gpu.cpp and maybe by changing the math I could make it work...

Or maybe there is already a set or parameter that would archieve something similar?

Regards

PS: Right now here are the alternative I found:

• I can display a tiny 128x128 in the middle of a 1920x1080, but this is too small. So if I could display a 1024x1024 made of 8x8 "pixels" it would be perfect.

• I can display in 1024x768 perfectly(?) scaled to 128x128, but then the aspect ratio is not respected, it should be 1:1 on screen where my resolution is 4:3 on a 16:9 screen/TV.

https://twitter.com/DavidGlaude/status/1163942579001593858?s=20

[juj]

You can achieve this by editing the crop pixel sizes at

fbcp-ili9341/display.h

Line 50 in a01f9e3

#define DISPLAY_NATIVE_COVERED_LEFT_SIDE 0

For example see

fbcp-ili9341/freeplaytech_waveshare32b.h

Line 19 in a01f9e3

#define DISPLAY_NATIVE_COVERED_TOP_SIDE 18

that configures a similar crop for freeplaytech devices.

You can try taking out equal width from both sides, I.e. set crop left and right to (1920-1024)/2 and top and bottom to (1080-1024)/2

[dglaude]

Are you sure it is the DISPLAY_NATIVE_COVERED that I need to modify?

I don't read CROP, I read COVERED... where is CROP?

Those (COVERED) are hidden pixels on the SPI side and for my WAVESHARE_ST7735S_HAT=ON the proper value come from st7735r.h:

#define DISPLAY_NATIVE_COVERED_LEFT_SIDE 2
#define DISPLAY_NATIVE_COVERED_TOP_SIDE 1

If I change those value left and right to (1920-1024)/2 and top and bottom to (1080-1024)/2 it crash.

Here I want to crop/ignore pixels from fb0 (HDMI) before copying on SPI.

[dglaude]

Maybe I need to change the overscan in gpu.cpp ???

double overscanLeft = 0.00;
double overscanRight = 0.00;
double overscanTop = 0.00;
double overscanBottom = 0.00;

Something to match left and right to ((1920-1024)/2)/1920 and top and bottom to ((1080-1024)/2)/1080 ?

This would be similar to changing in /boot/config.txt to

overscan_left=448
overscan_right=448
overscan_top=28
overscan_bottom=28

[dglaude]

Ok, I may have a solution by forcing in gpu.cpp those value:

  double overscanLeft = 0.0259259;
  double overscanRight = 0.0259259;
  double overscanTop = 0.2333333;
  double overscanBottom = 0.2333333;

And here is the output, were the only disturbing thing is 1025x1025 rather than 1024x1024:

DISPLAY_FLIP_ORIENTATION_IN_SOFTWARE: Swapping width/height to update display in portrait mode to minimize tearing.
Relevant source display area size with overscan cropped away: 1025x1025.
Source GPU display is 1080x1920. Output SPI display is 130x129 with a drawable area of 128x128. Applying scaling factor horiz=0.12x & vert=0.12x, xOffset: 2, yOffset: 1, scaledWidth: 128, scaledHeight: 128
Creating dispmanX resource of size 134x240 (aspect ratio=0.558333).
GPU grab rectangle is offset x=3,y=56, size w=128xh=128, aspect ratio=1.000000
All initialized, now running main loop...

I added printf before and after your "Overscan must be actual pixels computation."

  printf("overscanLeft=%f overscanRight=%f overscanTop=%f overscanBottom=%f\n", overscanLeft, overscanRight, overscanTop, overscanBottom);

  // Overscan must be actual pixels - can't be fractional, so round the overscan %s so that they align with
  // pixel boundaries of the source image.
  overscanLeft = (double)ROUND_TO_FLOOR_INT(display_info.width * overscanLeft) / display_info.width;
  overscanRight = (double)ROUND_TO_CEIL_INT(display_info.width * overscanRight) / display_info.width;
  overscanTop = (double)ROUND_TO_FLOOR_INT(display_info.height * overscanTop) / display_info.height;
  overscanBottom = (double)ROUND_TO_CEIL_INT(display_info.height * overscanBottom) / display_info.height;

  printf("overscanLeft=%f overscanRight=%f overscanTop=%f overscanBottom=%f\n", overscanLeft, overscanRight, overscanTop, overscanBottom);

And maybe the 1025 vs 1024 come from the small difference. I don't know what is wrong in the math. Maybe the round CEIL and round FLOOR is affecting here.

overscanLeft=0.025926 overscanRight=0.025926 overscanTop=0.233333 overscanBottom=0.233333
overscanLeft=0.025000 overscanRight=0.025926 overscanTop=0.232813 overscanBottom=0.233333

At least on the LCD it seems "pixel perfect" from the logical 128x128 from Pico-8 and the 128x128 from the LCD.

If you find a flaw, or some way to improve that, do not hesitate.

A general solution where overscan are computed automatically based on a scaling factor would be a great feature. Right now, changing 4 lines in the code is good enough for me. I might submit a pull request for you to review.

Thanks for this great piece of code, it is very well documented, very customisable code, and very useful to me.

[juj]

Err, of course the overscan and not the covered values, sorry for the mixup! Glad you were able to locate the right spot. Not immediately sure about the rounding issue, it could be a off by one issue (inclusive vs exclusive) of the last pixel in the crop rectangle, or something similar.

If you put up a showcase of some action shots, would love to see! :)

[dglaude]

This is the result with both screen side by side: https://twitter.com/DavidGlaude/status/1164665482290577411?s=20

I'll try to document better, with easy to follow instruction, maybe a fork first, then a pull request.

I discovered the hardware thanks to this: https://lexaloffle.com/bbs/?tid=34934

What I did is very similar to what is described here by someone before me, I just found out about having the HDMI usable simultaneously: http://reinvanderwoerd.nl/thoughts/2019/02/25/pico-8-mini-console-with-raspberry-pi-zero

But your software was suggested to me by https://twitter.com/Pi0CKET

[juj]

Looks great, nice project! I'll close this issue as resolved.