On 04/30/2018 01:28 AM, Thorsten Otto wrote:
On Sonntag, 29. April 2018 23:18:02 CEST Eero Tamminen wrote:
Crashes when you move mouse to bottom right corner.
Cannot reproduce that.
It doesn't crash if you use 2MB of RAM, but does if you use *>=4MB*.
And note that you may need to move the mouse in the *16x16 area*
at the *bottom right corner* of the screen for *several seconds*
before the crash happens.
If you can debug what actually happens, maybe propose a workaround,
that would be really great!
> And i don't use --grab or fullscreen.
You *need* to use either of those to be able to reliable move Atari
mouse in the bottom right corner of the Atari screen.
Without them, your mouse is very likely to move out of the Hatari
window instead of moving the Atari mouse cursor in the Atari screen
corner.
If there are
really cases where that crashes, then i would guess because VDI and/or
blitter
are trying to access memory beyond the end of video memory, and that
you need
some gap there before end of physical memory (or ROM).
That gap is really a pain in the exterior too. Some things don't work
if it's larger than the largest normal resolution on given machine,
but TOS memory detection doesn't work if the gap differs from
the actual (VDI) screen size.
But that still does not
have anything to do with the alignment of the screen width.
Cr*p. I'm able to reproduce the TOS crashes with >=4MB even with
the alignments, just by moving the mouse up to 5 secs in that screen
corner.
And I'm seeing them also with 2.0 WinUAE and 2.1 OldUAE, so it's not
core specific, and if it's a regression, it's not a recent one.
I faintly remember this working at some point, but it's possible that
I hadn't just tested mouse in that corner (diligently enough), only
moving it at the bottom of the screen.
Does somebody have prebuilds of earlier Hatari version to check
whether this worked with e.g. v1.4 or v1.8?
It's also not
clear why (aside from the required memory) a screen width of 1280 is
valid in
monochrome, but not in color modes.
That's due to 300KB limit.
And it also does not explain the rather
random limit of 300k for video memory.
It was result of testing. After more than 300kB was used,
some of the GEM programs I was testing, started to crash.
(I would have liked to use 150kB for TT, which is what the largest
TT mode takes, but on request from Uwe, raised it to 300kB to
support FullHD in mono, as that's most common resolution nowadays.)
Do you have somebody who's willing to go through few hundred most
common GEM applications,
That's imho not necessary. Just the hint that extended VDI modes may
work or
not, and that it is up to the user to try it out, will be good enough.
What then happens:
* User tries larger VDI mode and is happy that it works
* User tries it with GEM program he's actually interested to use
* If that doesn't immediately crash, he notices that large screen
gets updated too slowly to be usable (*), so he adds NVDI
And when things crash, users complain and would then be pissed
at us because we wasted their time by providing something that
"isn't even supposed to work".
(*) fast forward mode does make things fast, but it ruins
mouse interaction, so while it's fine when e.g. using
TOS desktop and during program startup, it's not really
an option for actually using most of applications.
User's don't typically read manuals...
Yes, but that also applies to games. You already expect them
to look at the compatibility list when something goes wrong.
Users do have some expectations about problems with game / demo
emulation. They don't expect problems with GEM programs, because
those work fine (without the VDI mode) on any emulator. That
makes a difference.
But don't get me wrong. It would be just a nice feature to be able to use
higher resolutions. If you think that it would too much hassle, then i
have to
live with the current limits.
What's the use-case where you want those large color resolutions?
(Only one I have for that is GEM NetHack, and it's fine with
640x480 @ 16 colors. Everything else I would want to use with
larger screen is fine, and much faster, in monochrome.)
- Eero