New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fullscreen: support different display resolutions to minimise vertical borders #488

Closed
tomcw opened this Issue Sep 29, 2017 · 3 comments

Comments

Projects
None yet
1 participant
@tomcw
Contributor

tomcw commented Sep 29, 2017

Email thread with Paul Berberich, from 23/9/2017.

Hi Tom,

Do you have any plans in the near future to make full screen mode work properly (i.e. edge to edge without black borders) in AppleWin? (re: issue #168)


Hi Paul,

See this issue (#358) which explains that we use integer scaling due to poor GDI float scaling results.

What is the resolution of your PC's screen?

And from this other issue (#280), there's this comment:

Obviously, it should be letterboxed on the left and right sides on a modern display, as the Apple II-series weren't available with a wide-screen display, but it also runs letterboxed at the top and bottom of the screen, wasting a huge amount of screen real-estate in the process. (560 x 384 pixel active window when set to 640 x 480 resolution for full-screen.)

...which I assume it your point too?

Thanks,

Tom


I run AppleWin on a widescreen monitor at 1920x1080 resolution, which I'm guessing is typical these days. Yes I agree about the huge waste of screen real-estate.

A first improvement that might be easiest to accomplish, is to have AppleWin detect the Windows Y resolution, and expand each pixel size that AppleWin outputs to an amount that will fit the most. For example, the resolution on an Apple ][ was 192, so 5x that would be 960 with Windows Y resolution set to 1080.

What do you think? Would that be do-able in the next version?

Many thanks for your consideration,
Paul Berberich


From issue #358:

AppleWin will try to integer scale the base resolution of 560x384.

So this means:

  • x1 : 560 x 384
  • x2 : 1120 x 768
  • x3 : 1680 x 1152

The scaling you are after is: x2.5, ie. 1400 x 960 - which is a non-integer multiplier.

The reason why we render at 560x384 (and not 280x192) is this retains the correct aspect ratio - the Apple II video display is non-interlaced, so alternate lines are blank.

NB. All video modes render to this base 560x384 bitmap - there's no concept of a 280x192 bitmap in AppleWin. I guess that if we scaled by 0.5 then by 5 the resulting full-screen image would be terrible!

The current integer scaling is not ideal (eg. in your case). I think using DirectX/GPU to scale is the approach we need to investigate.

Currently I don't see any activity in improving this in the short term (and probably not for the next release).

Tom


Ah I see, thanks Tom!

Some displays (like mine) have a 1280x768 resolution mode. 768 is 384 x 2. Would it be possible for AppleWin to detect if this video mode is available, and if so set full-screen mode to this resolution? That would create a true full screen mode! 😊

Of course the "windowed" mode would be unaffected - this would only be the full screen non-windowed mode, and wouldn't disrupt the normal resolution windows runs under.

Many thanks again,

Paul Berberich


Well, as a crude workaround you could manually change resolution to 1280x768, run "AppleWin.exe -f" (to start-up in fullscreen), then manually restore the resolution after exiting AppleWin.

Obviously automating this would be better.

Would it be possible for AppleWin to detect if this video mode is available, and if so set full-screen mode to this resolution?

Probably, but I'd need to check the Win32 API (or the DirectX API) to understand what is involved here.

A quick search turned up this:
https://stackoverflow.com/questions/215412/programmatically-change-screen-resolution

I'll have a quick go and see if it will do the job.

Tom

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Sep 29, 2017

Contributor

Added new cmd-line switch at 3cf50d0:

-fs-height=<best|nnn>
  • best: picks the highest resolution where the height is an integer multiple of (192*2)
  • nnn: select a specific resolution with height=nnn pixels
Contributor

tomcw commented Sep 29, 2017

Added new cmd-line switch at 3cf50d0:

-fs-height=<best|nnn>
  • best: picks the highest resolution where the height is an integer multiple of (192*2)
  • nnn: select a specific resolution with height=nnn pixels

@tomcw tomcw self-assigned this Sep 29, 2017

@tomcw tomcw added this to the 1.27 milestone Sep 29, 2017

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Sep 30, 2017

Contributor

FYI, new experimental release build 1.26.3.1 here.

Contributor

tomcw commented Sep 30, 2017

FYI, new experimental release build 1.26.3.1 here.

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Oct 8, 2017

Contributor

Email from Paul:

Awesome Tom!

The only thing is that initially the full screen image is stretched wide on my wide screen monitor. I had to switch my monitor's resolution setting to 4:3 aspect ratio on that particular resolution to remove the wide screen stretch screen distortion effect (which is fine since I don't use that odd resolution for anything else). It would be perfect if a user didn't have to do this, but this is definitely a step in the right direction!

Many thanks!! =)

As I said above, DirectX/GPU should be the better solution, but that requires more effort/time than I'm prepared to invest in this for now.

Closing.

Contributor

tomcw commented Oct 8, 2017

Email from Paul:

Awesome Tom!

The only thing is that initially the full screen image is stretched wide on my wide screen monitor. I had to switch my monitor's resolution setting to 4:3 aspect ratio on that particular resolution to remove the wide screen stretch screen distortion effect (which is fine since I don't use that odd resolution for anything else). It would be perfect if a user didn't have to do this, but this is definitely a step in the right direction!

Many thanks!! =)

As I said above, DirectX/GPU should be the better solution, but that requires more effort/time than I'm prepared to invest in this for now.

Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment