| |
chatGPZ
Registered: Dec 2001
Posts: 11140 |
VICE threaded UI test builds
In this thread i will post test builds of the (hopefully) soon to be merged threaded ui rewrite.
Linux and OSX users can always grab the current state from dqh's git repo here: https://github.com/dqh-github/vice-experiments/tree/threaded-ui.. (make sure to checkout the "threaded-ui-exp" branch after cloning the repo)
Please test and report back positive and negative results. Especially interesting right now are rendering errors/problems and unexpected crashes. Please tell exactly what OS you are using, and what GPU.
I will keep posting new windows builds here - starting with todays: https://sourceforge.net/projects/vice-emu/files/experimental%20..
64bit only right now - i'll have to figure out how to build proper 32bit binaries on my box (not that you should be still using a 32bit OS in 2020). |
|
... 149 posts hidden. Click here to view all posts....
|
| |
tlr
Registered: Sep 2003
Posts: 1723 |
Quote: Quote:The one that is different in Atomic/NR? What was wrong in the AR and RR implementation in vice?
yes, mode $22 - you'll see the fix soon, i'll also commit elaborate test programs soonish. (AR is already fixed and prints warnings to the log...)
Cool! But mode $22 for Atomic/NR was correct already, yes? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11140 |
nope =P it was broken everywhere (aka: nobody uses nordic power), including 1541U and chameleon. see https://sourceforge.net/p/vice-emu/patches/230/ (please lets continue there....) |
| |
cadaver
Registered: Feb 2002
Posts: 1154 |
Happy to see it run very smooth on Win10, I've been using offensively old VICE versions for a long time. Only thing I noticed was that sometimes after startup and loading a disk, audio latency was high (> 1 sec). This got fixed by fiddling with the sound buffering settings, now have smallest fragment size and "adjusting" sync method, and the high latency hasn't reappeared so far. |
| |
JackAsser
Registered: Jun 2002
Posts: 1990 |
I started messing with the mouse problems. The wrap problem is due to that gtk_warp_device always is relative to the considered default monitor for the screen. I’ve fixed that and compensated properly. So capture of the mouse now works properly. There are still problems getting relative coords though, the motion callback is triggered but the calculated deltas are 0,0 unless I move exceptionallly fast. I assume this is due to deltas are calculated after pixel scale compensation which is plain wrong. I’ll fix that also. |
| |
JackAsser
Registered: Jun 2002
Posts: 1990 |
Also thinking if it wouldn’t be better to hook into the usbhid layer directly instead and get relative hw-coords right away... this warping of the pointer feels utterly ugly |
| |
JackAsser
Registered: Jun 2002
Posts: 1990 |
Quote: I started messing with the mouse problems. The wrap problem is due to that gtk_warp_device always is relative to the considered default monitor for the screen. I’ve fixed that and compensated properly. So capture of the mouse now works properly. There are still problems getting relative coords though, the motion callback is triggered but the calculated deltas are 0,0 unless I move exceptionallly fast. I assume this is due to deltas are calculated after pixel scale compensation which is plain wrong. I’ll fix that also.
Further debugging reveals that after a pointer warp gtk will report motion, but not updated coords for about 200ms, causing everyrthing to fuck up. Digging further into the gtk/gdk sources to see why this behavious exists and possible ways to prevent it.
Recent gtk doesn't event support pointer warp anymore and the APIs have been removed alltogether so I suppose a more direct way of getting relative mouse motion is needed to be future safe. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11140 |
aaaaarg. another thing we need to solve with archdep code? SATAN! |
| |
JackAsser
Registered: Jun 2002
Posts: 1990 |
Quote: aaaaarg. another thing we need to solve with archdep code? SATAN!
Yup.. |
| |
JackAsser
Registered: Jun 2002
Posts: 1990 |
Quote: aaaaarg. another thing we need to solve with archdep code? SATAN!
Should consider libusb for input handling. That would make hid-input portable. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11140 |
i already hate that idea :) |
| Previous - 1 | ... | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | ... | 17 - Next |
