JHRobotics
Screen resizing in 16 bit mode requires reinstall
If the driver is set to 16-bit color depth instead of 32-bit, guest auto resizing corrupts the display when the window is resized, it is then impossible to change the display mode because the display is unusable. Rebooting does not fix the problem, nor does restarting VMware.
Coupled with the design of VMware making it impossible to send keys to the VM at the beginning of the boot sequence, there is no way to enter safe-mode to remove the display driver, and because snapshots seem to not roll back changes entirely, unless a snapshot was made of the OS just before the point of changing resolution, there is no other option than to completely reinstall Windows.
These are some quite serious consequences for changing bit depth and then resizing the display.
This happens in a fresh install of VMware Workstation 17.5 with a fresh install of Windows 98SE and a fresh install of either SoftGPU 0.6.x or 0.8.x. I suggest simply disabling the 16 bit color modes until this bug is squashed, as there seems to be little to no measurable or perceivable performance advantage to changing bit depth, meaning it offers only a degradation in quality.
Just to be clear, resizing the guest display normally works perfectly with 32-bit color, this only happens in 16-bit color mode
Hi, please check the latest release (0.8.2025.51), there more VMware fixed including this. Problem was that screen width must be divisible by 8, but when driver deny not proper resolution, the auto resize will stuck. So currently driver allow any resolution[^1] but silently align the resolution to best match.
[^1]: when you have enough VRAM, VMware also has a bug that only 16 MB of actual VRAM is available.
For some reason, in order to make VM auto resizing work I had to do the same weird ritual (reverting to snapshot because of no auto resize, install 0.6.x driver, reboot, install DX9, reboot, install 0.8.x driver, reboot) I did the last time I upgraded the drivers to 0.8.x.50, I can only assume this is a VMware bug of some sort, Sorry I can't give you much more to go on, let me know if you can think of something I can do to debug this further for you.
Anyway, the good news is that with the new driver revision (0.8.x.51) resizing works within a few of pixels of perfectly in 16-bit modes, which is a lot better than hosing the OS. I notice the new resize behavior also applies to 32-bit modes, which never exhibited the skewed screen problem for me.
This is not a complaint at all, but just to inform you that the 8-bit aligned resize is happening in 32-bit mode and it probably doesn't need to, maybe someone will care and want pixel perfect resizing back - personally I couldn't give a sh...
I guess the 16MB vram thing probably explains why the vast majority of games won't work. What a shame your work is essentially useless for those of us forced to use WIndows as a host because QEMU and VirtualBox are either so buggy and/or so lacking in host integration that they're basically unusable.
I think I just need to wait a couple more decades for CPUs to get fast enough to run PCEM or 86box at more than a snails pace. ☹
OK, in current release in 32bpp is screen align to 2px (vmware alway send even resolution width).
Also when I digging more and more to virtual GPU API I can't shake the feeling that it's designed very precisely to that it can't be used for gaming. QEMU on Windows is problem (it's a shame because for example VirGL can do probably much better job in 3D acceleration), but integration tools for VirtualBox could be created 😇