Reply 40 of 53, by Dege
wrote:Ideally, I would like dgvoodoo to be "Resolution = unforced". Just render at Glide resolution from _grSstWinOpen. Scaling is optionally controlled by host environment using the HWND based on the size of the client area. It doesn't have to scale perfectly, just try the best to keep the aspect ratio and performance. It is OK to leave black borders. QEMU does the same to its 2D SDL display for scaling. OpenGlide would render from lower-left corner and leave black borders on top and right. Resizing window is done prior to activating Glide and the size cannot change once Glide is running. I would like to experiment with this design concept for Glide games that only support 640x480. LFB accesses must be maintained at Glide resolution to make things work.
Then let's just set resolution to unforced in the config file. dgVoodoo currently has no support for applying its scaling modes (centered, stretched, kept, etc.) for windowed mode, as it doesn't really make sense for most of the cases: the content is always stretched along the entire window and it's up to the user how he/she sizes the window itself. The only help is 'Keep window aspect ratio' config option that forces manual sizing operation to keep the aspect ratio of the output resolution (forced, unforced). But this is done through a hooked windowproc too.
So, if I completely remove window hooking for QEmu then Alt-Enter is lost, and window size doesn't change at all, independently on wrapper resolution (forced, unforced), it's up to QEmu to give it an initial size + window sizing ends up in stretched image without keeping aspect ratio.
LFB accesses works because they are independent on window size.
wrote:Gulikoza's patch actually resizes the window for dgVoodoo1 based on Glide resolution. It is detecting dgvoodoo1 by the exported symbol "DispatchDosNT". Obviously, this had failed for dgVoodoo2. If you add back the symbol as dummy, then DOSBox will resize the window for you, too.
It's new information for me, thanks!! 😁 😁