Closed larsbrinkhoff closed 5 years ago
Very cool! On my screen the window is half size too.
The window creation is at the bottom of main.c and easy to understand. Just fix it to whatever you want for the ARDS mode. I do not expect any need to change main.c in the next few days, but I will probably keep working on tek4010.c
That was quick! Did you test any of the sample pictures?
I was thinking tube_drawVector etc expects coordinates scaled to the window size? I placed my own layer in between to transform from ARDS coordinates to the tube. But I unconditionally divide by two, which I believe is wrong for large screens?
Yes, they look great.
The coordinates are very special on the Tek. The original had 1K, and used 2x2 bytes, of which some could be skipped, if they didn‘t change. When Tek moved to the 1414, with 4K horizontally (with a high resolution accessory), they implemented the additional 2 bits per coordinate in a special way, which was ignored by the older 4010 and on the 4014 without high resolution accessory. I was concerned about uneven scaling, because it always shows up in dot pictures, and also, if one looks carefully, in vectors. I did therefore try to emulate this hardware. The normal window is 1K, and just ignores the 2x2 bits exactly the same way as on the original.
If the user chooses -full, a full screen window is opened at whatever size the screen has, a scaling factor and a horizontal offset is created. This results always in a visible grating in dot pictures. That‘s not so nice, but the Raspberry Pi can definitely not open a 4K window (not enough memory and gpu speed). And it slows down the refresh.
You can decide what you want to do with the ARDS. The situation is different because of the vertical orientation. You need to handle all your scaling in your decoder.
Hello,
This adds ARDS support. It's not perfect yet; I haven't checked how the screen scaling factor works. The character size is a guess.
On my screen, the window is half size. All four sample pictures render OK.