| Re: [hatari-devel] VDI resolution limits |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On 04/29/2018 05:57 PM, Thorsten Otto wrote:
If you have contrary test-data for different VDI bit-depths from:
- multiple TOS versions (1.04, 2.06, 3.06 and latest EmuTOS),
Tos 1.04 may not work with screen sizes larger than 32KB. Without patches, at
least the mouse drawing routines have problems then IIRC.
But 2.06 and above don't have that restriction.
Besides, as mentioned in the Hatari manual, in monochrome 300kB is
enough for resolutions like FullHD (1920×1080), WUXGA (1920x1200)
and QWXGA (2048x1152), so it's not *that* small...
But only for monochrome. With 16 colors, the largest i can get is 896x672,
that is an annoying restriction. 256 colors isn't even supported in TT-mode
yet.
BTW. there is definitely something wrong with that routine:
if (bIsEmuTOS || TosVersion >= 0300 || ConfigureParams.Memory.STRamSize_KB
< 4*1024)
The 0300 was maybe meant to be 0x300.
Yes.
But it does not work anyway, because TosVersion isn't even set at that point.
Good catch, thanks.
I commited a fix:
https://hg.tuxfamily.org/mercurialroot/hatari/hatari/rev/2efe58341175
The code falls into the else, which
reads:
if (VDIWidth > 3*128 && (VDIWidth-128) % 256)
VDIWidth -= 128;
I don't get that. Why is 1280 not a valid screen width? It is reduced by 128.
Where does that strange formula come from?
That screen size alignment is required to prevent TOS crash when
mouse goes to 16x16 area at bottom right corner of screen:
http://www.atari-forum.com/viewtopic.php?f=51&t=33129&start=100
I also don't understand what the
screen size has to do with wether more than 4MB ST memory is available.
That was found out by testing. If you can come up with
a good explanation, I would be interested.
When i disable the call to VDI_ByteLimit, and that routine above,
i can get larger resolutions without problems:
>
with 3.06:
Please look into comments in STMemory_SetDefaultConfig() for phystop
on TT.
with 2.06:
Crashes when you move mouse to bottom right corner. Unless you
use "--grab" or switch to fullscreen, you may not be able to
(easily) move mouse there.
With EmuTOS:
Yes plain EmuTOS is supposed to work fine. However, nobody's
interested just to run TOS desktop in VDI mode.
all three are 1280x960, in 16 colors. Didn't test NVDI, but if that does not
work, there should be a hint in the manual that this is incompatible, or a
newer version of NVDI is needed, rather than disabling it for all others.
If some applications crash, it's possible that whole lot of other
applications also crash. Application crash typically means user
data loss, which is not acceptable.
Do you have somebody who's willing to go through few hundred most
common GEM applications, utilities and games, and verify that
most of their functionality also works fine?
After that kind of testing is done, and it finds that >95% of
them have *no* problem in any of their functionality, I can agree
on changing the default and just marking non-working apps in
the compatibility list.
That's still iffy, unless those crashing cases crash right at
beginning, so that user doesn't have time to use the app, and
lose data. User's don't typically read manuals...
- Eero