Integer-scaling breaks when Rotate screen is On

[dfilskov]

Integer-scaling works nicely when Rotate screen is Off ...

but when Rotate is On the integer-scaling is applied before the rotation instead of after.

That makes the pixels un-even / not integer-scaled resulting in shimmering and incorrect graphics.

I believe this is the case for most - if not all - cores with rotation.

[jotego]

Is this specific to JT cores or a general MiSTer problem?

[dfilskov]

I'm not sure.

The issue doesn't seem to be there in e.g. the Atari Lynx core but it might be a coincidence (I use a 1920x1920 monitor btw.)

I'm talking only about cores with both screen rotation in their settings - and integer-scaling. Not easy to find.

I'll keep testing to see if I can find a non -JT core with the same issue (but if I find one I won't know if it's a general issue or another coincidence.)

[dfilskov]

An easy way to check if integer-scaling works is to turn on Horz filter (in Video processing) with

LCD_NN_Type0_020 or LCD_NN_Type1_020

The pixel outlines will make a grid/mesh which is clearly even/symmetrical or uneven.

[dfilskov]

E.g. Arkanoid doesn't have integer-scaling. That really shows with the LCD filter.

[dfilskov]

sorgelig writes:

"If i remember right scaling is depend in rotation ... framework receives rotated image, so it scales the image which is already rotated"

But then I don't see how it can not work on JT cores. If the framework integer-scales the rotated signal it should work.

Unless there's a bug in the framework that only happens when a core rotates its video signal before sending it on for integer-scaling. But that doesn't make sense.

[dfilskov]

Not sure if this issue is related but e.g. Bomb Jack and Up'n'Down surprisingly changes sizes when I rotate them on my square resolution (1920x1920) both when scaling is set to Original and Fullscreen.

I'd expect a rotated core video signal to stay the exact same size no matter what the scaling is set to on a square monitor.

There must be something wrong with the scaling somehow. Perhaps it happens when the pixel-size isn't square and the uneven ratio is somehow being applied to the scaling in the wrong direction when the signal is rotated.

[dfilskov]

Scandoubler CRT scanlines don't work either.

Please check this video of Dimahoo to see for yourself that scanlines does not appear when you turn on scandoubler:

https://github.com/user-attachments/assets/5a89e83c-8648-4d9c-b32b-be545919a2d8

[jotego]

I have enabled integer scaling when video is rotated. Because scan line options do not work on rotated video, they appear now as disabled. You can try the two cores in this file vscaling.zip for the changes. Public files will be updated next JTFRIDAY.

[real-amano]

Will we lose scanlines on rotated video in general? Or just for the case that you turn on rotation AND integer scaling? Is it because there ist too little vertical resolution left for a rotated image, shrunk for correct integer scaling and then proper scanlines added to it?

[jotego]

As far as I know, this is how scan lines work on the MiSTer framework. I am not sure what the reason is. I have just disabled the option when it has no effect so the user interface is more clear.

[asturur]

dfilskov How do you drive a 1920 by 1920 screen with mister? the max i can go is 1920x1440. or 2048x1536. Also what monitor is it?

[asturur]

Also just for clarity i never had an issue with scanlines done with video processing in vertical shooters like dondonpachi ( not jtframe )

[dfilskov]

dfilskov How do you drive a 1920 by 1920 screen with mister? the max i can go is 1920x1440. or 2048x1536. Also what monitor is it?

I'm using this video mode that I created myself:

video_mode=1920,16,8,16,1920,16,8,16,230500

I use an HDMI to DVI cable (and the no audio setting in Mister.ini)

This is the monitor - not easy to find these days (supports 60 Hz only):

https://www.eizoglobal.com/support/db/products/model/EV2730Q

You can see it "in action" here briefly:

https://youtube.com/shorts/5Fi50vZ7tig

[asturur]

@jotego to be honest i do not understand the commit that references this PR here: https://github.com/jotego/jtcores/commit/3cf62624b059c03722f39e621d11a869e55d22e4#diff-291d944f9375ebd5e4f1728404b37e3d33b6849938087554b26a30724ae2061cR821

You allow for cropping with 216 lines also when the screen is rotated. But when the screen is rotated the 216 lines go to fill up the 1920 part of the screen not the 1080, so i m not sure is anymore relevant.

[asturur]

I was trying to spend some time on this issue that interests me. It looks like to me that if you want to have integer scaling for vertical games the safe options is to set to 1 the scaling mode in mister.ini. This disable cropping for some reason that i do not really understand and i can't find a way playing with the source to enable crop no matter what.

Enabling cropping for rotated games does not make sense unless we get a way to crop columns rather then rows in the framebuffer used for rotation.

I also see that cropping is limited to 1080p and given some games having a vertical resolution of 256px or given the 1536p screens it would be nice to enable crop also for those screens here.

I wrote some code to test it but of course it doesn't work,

[dfilskov]

I've always been using vscale_mode=1

Isn't the 1920x1080 "hack" crop workaround programmed by Sorgelig?

I think a more flexlible general (vertical and horizontal respectively) cropping feature would be much more useful (for getting a larger integer-scaled signal on all resolutions/displays).

[asturur]

with mode 1 is always integer. I ll have to check arkanoid and try to reproduce your issue for my own curiosity.