Closed DavidLudwig closed 7 years ago
It is not necessary a fractional ratio, eg 1.5x. I believe any up-scaling may need anti-aliasing.
To simply the user input, I propose:
I sincerely believe if use any acceleration D3D or OpenGL may not be a good idea for cross platform support. Let's try something simple first for anti-aliasing. In the end, it is just a filter with matrix operation.
Is there any reason to require a user to specify an integral scaling factor, as opposed to having the machine determine what the largest possible value would be (given their display's dimensions), and using that?
A side-note on scaling: SDL2 has code to handle scaling. By default, it uses a 3D API. If that is not available, it falls back to a software implementation. My inclination is to use that, which has been used and tested in a large range of things, rather than to try writing something custom, even if the custom implementation is a "simple" one.
Yes. All comes from Window mode, instead of full screen.
There is no fixed screen resolution in BII. User can define whatever they want. If you specify resolution in the settings, you'd expect that it is what you get.
The case you mentioned seems to limit to the fullscreen. What if that's not what they want. Or the hi-res monitor in the future can reach 10K. It doesn't make sense to make it full screen and make it scale from 640x480 to 10K with 20x scaling factor.
Regarding to the implementation, I'm with you. Just use whatever SDL2 provides, instead of reinventing the wheel.
Maybe, when in windowed mode, the window itself could be resized via standard, host OS, window-resizing controls? If and when this happened, the screen would stretch. I'm not sure if this is the right solution, though. Thoughts regarding it, welcomed.
On Sun, Aug 13, 2017 at 9:19 PM, Ricky Zhang notifications@github.com wrote:
Yes. All comes from Window mode, instead of full screen.
There is no fixed screen resolution in BII. User can define whatever they want. If you specify resolution in the settings, you'd expect that it is what you get.
The case you mentioned seems to limit to the fullscreen. What if that's not what they want. Or the hi-res monitor in the future can reach 10K. It doesn't make sense to make it full screen.
Regarding to the implementation, I'm with you. Just use whatever SDL2 provide, instead of reinventing the wheel.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/DavidLudwig/macemu/issues/10#issuecomment-322080663, or mute the thread https://github.com/notifications/unsubscribe-auth/AAdC0MJPQfrk10M3qskzkgbJLfXQlfKKks5sX6CmgaJpZM4O1urS .
Resize should not be supported during run time. That may mess up guest OS internal.
OK. IMO, we are spending too much time in figuring out the right interface.
But we'd better have a PoC that can do at least 2x/3x first in windows mode for 512×384 . After we have that, we can consider if anti-aliasing is necessary.
Anti-aliasing is already set up and working. I committed it earlier this afternoon. It'll be in the next prerelease. I think you over-estimated how much time that would take.
Scaling the guest OS up is easy, given the architecture of SDL2. I think you are also overestimating how much effort that would take.
On Mon, Aug 14, 2017 at 4:03 PM, Ricky Zhang notifications@github.com wrote:
Resize should not be supported during run time. That may mess up guest OS internal.
OK. IMO, we are spending too much time in figuring out the right interface.
But we'd better have a PoC that can do at least 2x/3x first in windows mode for 512×384 . After we have that, we can consider if anti-aliasing is necessary.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/DavidLudwig/macemu/issues/10#issuecomment-322293949, or mute the thread https://github.com/notifications/unsubscribe-auth/AAdC0K1Ir8fwzDZdDmw5gPM6mV_1OQ-fks5sYKgTgaJpZM4O1urS .
Added via commits 9116cae and b9c9687.
@rickyzhang82, are you concerned about the approach in implementation?
If so, is there some specific reason, or reasons, that you are concerned about it?
Side-note: regarding a resize-able window, my thought was to have a window that would retain the guest OS' display size, but scale it up to the native window's size. This is pretty easy to implement with SDL2. ;-)
I just get XCode build works. Great job to bring XCode build back. I can ditch QtCreator IDE in Mac now.
It seems that you just removed all legacy Cocoa version preference UI. IMO, the preference UI should be deprecated and use GTK/QtPython or whatever modern tools to unify UI. We can revisit this later.
In any case, I don't see your scale factor in ~/.basilisk_ii_prefs file. The commit only show anti-aliasing. Have you implemented the scale up? I want to see how it looks in scale up.
Re: Side-note If guest OS runs in 640x480 and I apply 2x scale up factor on the screen, it will generate 4 new pixels from the original 1 pixels with or without anti-ailiasing smoothing. That we will have 1280x960
Is my understanding correct?
Yes, however in most cases, a GPU will handle the scaling.
In terms of scaling up, that was already implemented.
But how to zoom?
Could you elaborate how to zoom?
In fullscreen, zooming is performed automatically.
In windowed mode, at least as of Prerelease 5 (just released) on an OSX host, resizing the host OS window will cause the guest OS' display to be scaled/stretched/zoomed, either up or down as needed.
Thanks! I gave a try. It works.
SDL2 has a hint to apply this, which is not yet enabled (in Basilisk II).