Comments (20)
I suspect a race condition between the mouse interrupt and main VDI code. But absolutely no clue.
from fvdi.
I can reproduce that too, using Hatari, and the bitplane driver with 16 colors. I'm not entire sure whether that is only mouse related, as there sometimes seem to be some other random garbage:
Also it seems to be an old bug, happens both with the old and new versions.
from fvdi.
There is denfinitely something strange going on there. Attached is an animated gif, where i switch in gemini from the console to a file window, and back. Look at the prompt in the console window...
from fvdi.
Idea of animated GIF for bug reports is really brilliant
from fvdi.
these artifacts are also observeable on the FireBee, but a lot less prominent. You really need to make an effort to create them (just browsing through a menu is definitely not enough most of the time).
fVDI appears to disable interrupts when calling functions with "special stack".
Line 87 in cfb8c68
Depending on how long these functions run, it might well be the cause for all kinds of strangeness.
(and yes, animated gifs are nice ;) )
Hmmm, no. This macro does not seem to be used anywhere.
from fvdi.
My Amiga drivers (UAEGFX and SAGA) based on the 16-bit driver also exhibit mouse artifacts, occasionally. I suspect a race condition between the mouse interrupt and the main code (to be proved).
from fvdi.
The saga driver has gotten a new flag for accelerated mouse drawing. That should use the hardware mouse capabilities of the card, maybe that works better.
from fvdi.
Some findings so far:
-
there is a flag "oldmouse", both in fvdi.sys and for the driver. Setting this would have the effect that the mouse routines from the "old VDI" (ie TOS) are called. Does that make sense? I can't imagine any situation where that should be useful, or even work (the old VDI may have its own idea where the mouse is located)
-
when using an "accelerated" mouse drawing function (which is the default case for the bitplane driver), the functions v_hide_c() and v_show_c() check the wk->mouse.type member, which was set in init.c. However, vq_mouse only tests the global stand_alone flag. I could imagine that this causes trouble with AES.
The other pixel garbage from text output seem to be unrelated to this, and maybe cause by other bugs in the text drawing functions.
from fvdi.
Note that, when working on my drivers derived from Falcon 16-bit, I noticed that there was no mouse support for 16-bit modes. I guess that oldmouse was useful in that case (on Falcon). In other words, use fVDI implementation on Falcon for anything except the mouse. As a result, I needed to invent new fVDI mouse routines for 16-bit modes, when the underlying TOS has no support for those modes.
from fvdi.
I needed to invent new fVDI mouse routines for 16-bit modes, when the underlying TOS has no >support for those modes.
But these were only used for the uaegfx/saga drivers. In the meantime however, similar routines have also been implemented for the generic 16_bit driver. So if i'm not wrong, all supported drivers have now "accelerated" versions. That means, you still have the choice to turn them off for a particular driver using the accelerated option, which should have the same effect and call the TOS functions.
from fvdi.
There are actually 3 possible implementations for mouse :
- use the underlying TOS routines
- implement mouse routines inside fVDI using bitmap blits
- implement mouse routines inside fVDI using some hardware acceleration (i.e. hardware sprite)
from fvdi.
For hardware sprites, there is already an additional flag hwmouse for the saga driver (the only one that supports it currently).
from fvdi.
Some more findings (maybe not related to the bugs, but still strange):
- in the drivers init() function, graphics_mode is examined. However, several drivers (aranym, uaegfx and saga at least) set that to the actual mode being specified by the driver options. That is done in initialize(), which is called later.
- most drivers have a norestore option, that is nowhere documented. I haven't fully understand yet what it does, but it has something to do with mouse redrawing
- in EmuTOS (and also in TOS i assume), mouse redrawing is protected by mouse_flag. This is definitely needed to avoid for example saving a screen background in v_show_c() that is just being updated by the timer interrupt. No such thing seems to be done by fVDI. Maybe it is expecting the driver to take care of that?
from fvdi.
I can usually rather quickly produce some artifacts with Hatari, when moving the mouse from one menu title to another:
Strangely, i cannot reproduce the same using StonX.
from fvdi.
I don't think that's specific to Hatari, I can (although a lot more difficult) reproduce the problem on the FireBee as well.
from fvdi.
While further looking at the code, i'm currently in the mood of rewriting that whole stuff about mouse management. There are so many variables and states currently, that it is difficult to maintain. Amongst others, that are:
-
booted. This variable is currently used to indicate that fVDI was booted from auto-folder, and has to be set manually in the config file. This is imho nonsense, or at least obsolete, since running fVDI from the desktop does not work at all.
-
fakeboot. Related to above, forcing fVDI into believing it was run from auto-folder, even if it wasn't
-
disabled. Intended to just test the boot code, but not loading any drivers. Just a debug feature, and does not seem to work.
-
oldmouse (both as global variable, and also as setting for the driver)
As already discussed, that variable is currently responsible of calling the previous mouse functions for v_hide_c() etc. Since all drivers now have their own mouse drawing functions, calling any previous functions should not be needed anymore, and i expect that actually to cause that trouble. Amongst others, the vbl-routine of the previous TOS (if already installed), is left alone, and might interfere with fVDI's own drawing. -
wk->mouse.type. Derived from oldmouse, once the driver is loaded.
There are some other srange things that need to investigated. Eg. when opening a (physical) workstation, VEX_CURV and VEX_TIMV are hooked, but VEX_MOTV and VEX_BUTV aren't, these are redirected to TOS instead.
from fvdi.
I'm not sure, but bitplane.sys mouse artifacts didn't happen anymore for me in recent tests?
@th-otto : did you change anything related to this, did they vanish "magically" or is it just my flaky testing?
from fvdi.
from fvdi.
Ah, thank you, great! Then I didn't just dream it ;)
I'd suggest we could close this issue now?
from fvdi.
closed with c36b716
from fvdi.
Related Issues (20)
- Build system is not great HOT 2
- CI broken HOT 2
- Font autohinting causes crashes HOT 6
- Fonts do not sit correctly on baseline HOT 3
- Reduce binary size (improve performance?) HOT 2
- Proper fix31 support HOT 4
- v_gtext horizontal alignment is wrong HOT 1
- .pcf font files not loading anymore
- ALL_BLACK and ALL_WHITE appear to be implemented wrongly for raster copy functions HOT 2
- Aranym screen driver does not honour offscreen bitmap handle
- bitplane.sys is not included in snapshot archives HOT 2
- Teradesk Preferences dialog redraw errors in 8bpp HOT 3
- FVDI building for 680x0 depends on installed PortAsm HOT 6
- v_clswk() crashes in FreeMiNT console at 8bpp with fVDI present
- vst_point broken by fix31 patches
- commit 7d17626 breaks build HOT 7
- does not run on FireBee anymore HOT 2
- MicroAPL related content
- Weird colors with fvdi aranym HOT 16
- Update freetype support HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fvdi.