| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
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). |
|
| |
spider-j
Registered: Oct 2004
Posts: 444 |
I assume GTK3 should be tested? No special ./configure params? |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
macOS Catalina 10.15.4
Intel UHD Graphics 630
(x86_64-apple-darwin19.4.0)
GTK 3.24.18
./configure --enable-native-gtk3ui --enable-embedded
host_vsync_macos.m:30:10: fatal error: 'NSOpenGL.h' file not found
OpenGL was deprecated in macOS 10.14...
I assume you just need a way of vsyncing on MacOS. This is normally done via the CVDisplayLink. See example here: https://stackoverflow.com/questions/14158743/alternative-of-cad.. |
| |
spider-j
Registered: Oct 2004
Posts: 444 |
Clicking on "CRT controls" occasionally just shows thin borderlines and the content from the windows / desktop below:
Didn't happen with the "Mixer controls" switch so far.
Ryzen 3700X, RX 5700, Gnome 3 "Classic" X-Session.
Kernel 5.6.13-arch1-1, mesa 20.0.7-2, gtk3 1:3.24.20-1, gnome-desktop 1:3.36.2-1, xorg-server 1.20.8-2
Don't really know what to look for. Wild clicking through the menus and wild resize / fullscreen toggling seems to be stable.
EDIT: added more detailed sys specs |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
Quote:I assume you just need a way of vsyncing on MacOS.
No, obviously also for rendering GL is needed. Without that, prepare for using the SDL port =P (Who would have thought dropping GL was the silliest idea apple ever had). |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Quote:I assume you just need a way of vsyncing on MacOS.
No, obviously also for rendering GL is needed. Without that, prepare for using the SDL port =P (Who would have thought dropping GL was the silliest idea apple ever had).
Couldn't agree more. The SDL port is awesome once I understood how to make my own keybindings.
I'll try to check if there are GL backports somehow. |
| |
Mr. SID
Registered: Jan 2003
Posts: 421 |
OpenGL will go the way of the dodo, on all platforms, eventually.
Sure, Khronos Group will try to convince you that it will stay around forever, but as GPU architectures change, the resources to keep OpenGL in a working state for legacy software on that newer hardware is going to become unsustainable. It's design is just too contradictory with how GPUs work already now, but it will become worse in the future.
There are certainly a few years left before that happens though, and even after that you'll see enthusiasts (Mesa?) hack new drivers together somehow.
But it seems that now would be a great time to consider alternatives. But there's no single API for all platforms, so VICE is out of luck. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Anyway. I commented out the vsync code since this is just to change swapIntervals for the currrent gl context. Then it built but seg faults. (master branch VICE builds fine and doesn't crash).
Process 57778 launched: '/Users/andreaslarsson/Downloads/vice-experiments/vice-emu-code.nosync/vice/src/ x64sc' (x86_64)
Error - Default keymap not found, this should be fixed. Going on anyway...
Error - Default keymap not found, this should be fixed. Going on anyway...
Error - Default keymap not found, this should be fixed. Going on anyway...
Error - Default keymap not found, this should be fixed. Going on anyway...
Error - Default keymap not found, this should be fixed. Going on anyway...
Initializing chip model "MOS8565" (63 cycles per line, 312 raster lines).
VSP Bug: safe channels are: 1257. Emulation of memory corruption is disabled.
Error - failed to initialize GResource data, don't expect much when it comes to icons, fonts or logos.
Error - Failed to find CBM.ttf
Error - failed to register CBM font.
Reading configuration file `/Users/andreaslarsson/.config/vice/vicerc'.
*** VICE Version 3.4 ***
Welcome to x64sc, the free portable C64 Emulator.
Current VICE team members:
Martin Pottendorfer, Marco van den Heuvel, Fabrizio Gennari, Groepaz,
Errol Smith, Ingo Korb, Olaf Seibert, Marcus Sutton, Kajtar Zsolt, AreaScout,
Bas Wassink, Michael C. Martin, Christopher Phillips, David Hogan.
This is free software with ABSOLUTELY NO WARRANTY.
See the "About VICE" command for more info.
Palette: Error - Palette not found: `mps803.vpl'.
MPS-803: Error - Cannot load palette file `mps803.vpl'.
Palette: Error - Palette not found: `nl10.vpl'.
NL10: Error - Cannot load palette file `nl10.vpl'.
Palette: Error - Palette not found: `1520.vpl'.
plot1520: Error - Cannot load palette file `1520.vpl'.
DriveROM: Error - 2000 ROM image not found. Hardware-level 2000 emulation is not available.
DriveROM: Error - 4000 ROM image not found. Hardware-level 4000 emulation is not available.
Drive: Finished loading ROM images.
VIC-II: Initializing chip model "MOS8565" (63 cycles per line, 312 raster lines).
Process 57778 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x8)
frame #0: 0x00000001038eb918 libgio-2.0.0.dylib`do_lookup + 88
libgio-2.0.0.dylib`do_lookup:
-> 0x1038eb918 <+88>: movq 0x8(%r14), %rdi
0x1038eb91c <+92>: movq %rbx, %rsi
0x1038eb91f <+95>: callq 0x10393f240 ; gvdb_table_get_raw_value
0x1038eb924 <+100>: testq %rax, %rax
Target 1: (x64sc) stopped.
|
| |
Flavioweb
Registered: Nov 2011
Posts: 447 |
Distributor ID: openSUSE
Description: openSUSE Tumbleweed
3D controller: NVIDIA Corporation GM108M [GeForce MX110] (rev a2)
Model name: Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz
On Boot:
** (x64sc:25894): WARNING **: 23:23:29.369: AT-SPI: Could not obtain desktop path or name
** (x64sc:25894): WARNING **: 23:23:29.373: AT-SPI: Could not obtain desktop path or name
** (x64sc:25894): WARNING **: 23:23:29.374: atk-bridge: get_device_events_reply: unknown signature
** (x64sc:25894): WARNING **: 23:23:29.374: atk-bridge: get_device_events_reply: unknown signature
** (x64sc:25894): WARNING **: 23:23:29.374: atk-bridge: GetRegisteredEvents returned message with unknown signature
Sound: Opened device `alsa', speed 44100Hz, fragment size 2,9ms, buffer size 101ms
** (x64sc:25894): WARNING **: 23:23:29.378: AT-SPI: Could not obtain desktop path or name
** (x64sc:25894): WARNING **: 23:23:29.378: atk-bridge: get_device_events_reply: unknown signature
** (x64sc:25894): WARNING **: 23:23:29.378: atk-bridge: get_device_events_reply: unknown signature
** (x64sc:25894): WARNING **: 23:23:29.378: atk-bridge: GetRegisteredEvents returned message with unknown signature
X64sc crash if i open monitor (Alt+h) then try i command like "d" with:
uimon.c:142: Error: lib_debug_guard_size(): Cannot find debug address 0x7f8a000c2df0!
uimon.c:141: Error: lib_debug_guard_remove(): Cannot find debug address 0x7f8a000c2df0! (make sure to use functions from lib.h, do NOT use lib_free on pointers allocated by other functions.) |
| |
dqh
Registered: Jun 2019
Posts: 46 |
Quoting JackAsser
./configure --enable-native-gtk3ui --enable-embedded
host_vsync_macos.m:30:10: fatal error: 'NSOpenGL.h' file not found
Do you have Xcode installed? What version? Are you following the build instructions at https://sourceforge.net/p/vice-emu/code/HEAD/tree/trunk/vice/do.. ?
Edit: I just edited those instructions to stop recommending that we disable OpenGL during the build. |
| |
dqh
Registered: Jun 2019
Posts: 46 |
Quoting Flavioweb
X64sc crash if i open monitor (Alt+h) then try i command like "d" with:
uimon.c:142: Error: lib_debug_guard_size(): Cannot find debug address 0x7f8a000c2df0!
uimon.c:141: Error: lib_debug_guard_remove(): Cannot find debug address 0x7f8a000c2df0! (make sure to use functions from lib.h, do NOT use lib_free on pointers allocated by other functions.)
I hadn't been testing with --enable-debug , it turns out that the memory debug code wasn't thread safe. I have pushed a fix for this, thanks. |
| |
dqh
Registered: Jun 2019
Posts: 46 |
Quoting Mr. SID
But it seems that now would be a great time to consider alternatives. But there's no single API for all platforms, so VICE is out of luck.
A single API isn't the problem - in a vacuum it would be simple to write some DirectX or Metal code to get an image on the screen. The problem is that whatever we do needs to integrate with the GTK3 UI around it. OpenGL views are natively supported by GTK3. Once this single threaded to multi threaded conversion is complete and stable, I intend to look at what it would take to hack in a native child window or similar to host a DirectX / Metal view for VICE. It may even be possible for these APIs to attach to the main GTK3 window itself and just be told where to render .. hopefully I find a good option. |
| |
Flavioweb
Registered: Nov 2011
Posts: 447 |
Quoting dqhI hadn't been testing with --enable-debug , it turns out that the memory debug code wasn't thread safe. I have pushed a fix for this, thanks.
Now, during compilation, I get this:lib.c:117:41: error: ‘PTHREAD_RECURSIVE_MUTEX_INITIALIZER’ undeclared here (not in a function); did you mean ‘PTHREAD_MUTEX_INITIALIZER’?
117 | static pthread_mutex_t lib_debug_lock = PTHREAD_RECURSIVE_MUTEX_INITIALIZER;
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| PTHREAD_MUTEX_INITIALIZER
compilation terminated due to -Wfatal-errors. |
| |
dqh
Registered: Jun 2019
Posts: 46 |
Quoting FlaviowebQuoting dqhI hadn't been testing with --enable-debug , it turns out that the memory debug code wasn't thread safe. I have pushed a fix for this, thanks.
Now, during compilation, I get this:lib.c:117:41: error: ‘PTHREAD_RECURSIVE_MUTEX_INITIALIZER’ undeclared here (not in a function); did you mean ‘PTHREAD_MUTEX_INITIALIZER’?
117 | static pthread_mutex_t lib_debug_lock = PTHREAD_RECURSIVE_MUTEX_INITIALIZER;
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| PTHREAD_MUTEX_INITIALIZER
compilation terminated due to -Wfatal-errors.
Ugh, lost my previous reply.
I've pushed a fix for this and a bunch of other issues that were WIP when this thread was posted (i'd stupidly been using this git branch as a conduit between my dev machines, and so it wasn't in a good state)
macOS, Windows, Linux are stable for me at the moment, although I should point out that i don't expect OpenGL to be stable at all as it is running without any locking. As I said - was between sensible places. But i'll fix that soon. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Quoting JackAsser
./configure --enable-native-gtk3ui --enable-embedded
host_vsync_macos.m:30:10: fatal error: 'NSOpenGL.h' file not found
Do you have Xcode installed? What version? Are you following the build instructions at https://sourceforge.net/p/vice-emu/code/HEAD/tree/trunk/vice/do.. ?
Edit: I just edited those instructions to stop recommending that we disable OpenGL during the build.
I have XCode 11.4.1 (11E503a) running on macOS 10.15.4 (Catalina)
The problem is that NSOpenGL has been deprecated and is now finally removed from AppKit. Since you only use NSOpenGL to acquire the current GL context and change swapInterval you might as well use OpenGL directly (i.e. gl/opengl.h) which still is not removed from MacOS.
However you will need to get the GL context from GTK somehow in this case and then ask for the swapInterval extension and use that instead.
Another way is to skip using OpenGLs mechanisms for vsyncing and instead hook your screen refresh directly to the CVDisplayLink.
Anyway, with the OpenGL code removed I simply got a segfault instead so there is something else broken. |
| |
dqh
Registered: Jun 2019
Posts: 46 |
Quoting JackAsser
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x8)
[/code]
Any chance you can revert your local changes, git pull the latest code and try again? macOS Builds with no OpenGL support at all now work again.
That said - you should be using OpenGL on macOS now. My primary dev machine is running macOS 10.14 and VICE OpenGL backend is many many times better than the cairo backend, which is slow AF. If you like, you can try a recent (non-threaded) macOS GTK binary with GL support: https://sourceforge.net/projects/vice-emu/files/releases/binari..
If you are building with latest Xcode and they've completely removed the OpenGL headers, then you can install an older Xcode and use xcode-select to pick one. I'm using Xcode 10.3 for various reasons relating to being able to produce working macOS 10.9 binary distributions. |
| |
dqh
Registered: Jun 2019
Posts: 46 |
Quoting JackAsserI have XCode 11.4.1 (11E503a) running on macOS 10.15.4 (Catalina)
The problem is that NSOpenGL has been deprecated and is now finally removed from AppKit. Since you only use NSOpenGL to acquire the current GL context and change swapInterval you might as well use OpenGL directly (i.e. gl/opengl.h) which still is not removed from MacOS.
However you will need to get the GL context from GTK somehow in this case and then ask for the swapInterval extension and use that instead.
Another way is to skip using OpenGLs mechanisms for vsyncing and instead hook your screen refresh directly to the CVDisplayLink.
Anyway, with the OpenGL code removed I simply got a segfault instead so there is something else broken.
If the non-NS* openGL stuff is still there, then my latest commit should build for you then. I migrated to using CGL to enable vsync.
Previously I assumed you were building with --disable-hwscale to disable OpenGL but i see how that this wasn't the situation. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Quoting JackAsserI have XCode 11.4.1 (11E503a) running on macOS 10.15.4 (Catalina)
The problem is that NSOpenGL has been deprecated and is now finally removed from AppKit. Since you only use NSOpenGL to acquire the current GL context and change swapInterval you might as well use OpenGL directly (i.e. gl/opengl.h) which still is not removed from MacOS.
However you will need to get the GL context from GTK somehow in this case and then ask for the swapInterval extension and use that instead.
Another way is to skip using OpenGLs mechanisms for vsyncing and instead hook your screen refresh directly to the CVDisplayLink.
Anyway, with the OpenGL code removed I simply got a segfault instead so there is something else broken.
If the non-NS* openGL stuff is still there, then my latest commit should build for you then. I migrated to using CGL to enable vsync.
Previously I assumed you were building with --disable-hwscale to disable OpenGL but i see how that this wasn't the situation.
I can confirm it now builds, but I still get the immediate segfault crash immediatly on launch. I'm investigating as I'm quite sure it has something to do with my setup. |
| |
dqh
Registered: Jun 2019
Posts: 46 |
Quoting JackAsserI can confirm it now builds, but I still get the immediate segfault crash immediatly on launch. I'm investigating as I'm quite sure it has something to do with my setup.
You could build in Xcode and run it in the Xcode debugger - there's doc on how to do it in in doc/building. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Quoting JackAsserI can confirm it now builds, but I still get the immediate segfault crash immediatly on launch. I'm investigating as I'm quite sure it has something to do with my setup.
You could build in Xcode and run it in the Xcode debugger - there's doc on how to do it in in doc/building.
It now works, I had forgotten the initial make install. Thought it wasn't needed since I build my VICE all the time and install them. Will test performance and reports bugs now. :) |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Works alot better now. CPU usage is on part with the SDL2-build and the jerky motion is much less severe now. It's what you can expect running 50Hz stuff on a 60Hz screen.
The first bug that I encounter is that rescaling the main window is completly wonked here and entering fullscreen makes me only see the lower left portion of the emulator screen, and zoomed about 2x too much.
Moving the main window between external displays also produce different (and wrong) scaling.
However, good work still!! Keep it up! I'm eager to switch to a proper GTK-build once the initial bugs are solved (and mouse grabbing and 1351 support actually works). |
| |
dqh
Registered: Jun 2019
Posts: 46 |
The resizing bug is actually in GTK3 macOS itself - i've replicated it in their GtkGlArea example. In all likelihood i'll have to fix that bug myself.
For me though, going fullscreen always sorts it out, and returning from fullscreen also. Sounds like that's not the case for you. What hardware are you testing on - are you using a retina display? |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: The resizing bug is actually in GTK3 macOS itself - i've replicated it in their GtkGlArea example. In all likelihood i'll have to fix that bug myself.
For me though, going fullscreen always sorts it out, and returning from fullscreen also. Sounds like that's not the case for you. What hardware are you testing on - are you using a retina display?
Yes, I'm using Retina. Was my first suspicion also, that in didn't handle pixel scale property (2x pixels)
MacBook Pro (15-inch, 2018)
Processor: 2,9 GHz 6-Core Intel Core i)
Memory: 16 GB 2400 MHz DDR4
Graphics: Radeon Pro 560X 4GB + Intel UHD Graphicvs 630 1536 MB |
| |
dqh
Registered: Jun 2019
Posts: 46 |
Interesting, i'm using a retina laptop with a regular external screen. I see the same types of fuckery except that switching to or from fullscreen always fixes. I expect that the same bugfix will apply to all these cases. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Interesting, i'm using a retina laptop with a regular external screen. I see the same types of fuckery except that switching to or from fullscreen always fixes. I expect that the same bugfix will apply to all these cases.
Yeah. Let's wait and see until you've applied your own bugfix to this. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Quoting spider-jClicking on "CRT controls" occasionally just shows thin borderlines and the content from the windows / desktop below
Didn't happen with the "Mixer controls" switch so far.
Weird, on my box (Debian 10.3 with Cinnamon, i5-7400 + nvidia 1060GTX 3GB) that works fine with both trunk and dqh's branch.
I recently did some work on the CRT sliders, reducing vertical space by using two columns and using larger negative margins for the sliders (yay Gtk).
Does this also happen with trunk? |
| |
Flavioweb
Registered: Nov 2011
Posts: 447 |
Now it compiles and i can put some command in monitor window...
But...
If i try a "chis", x64sc freezes and i can only kill him.
"chis 50" or "chis 100" works, but using a value ">189" seems to make x64sc crash.
(I have always used the command without parameters but, since it crashes, i have tried with a value to understand what happened.)
I compiled with ./configure --enable-native-gtk3ui --enable-static-ffmpeg --enable-cpuhistory --enable-new8580filter --enable-x64 --enable-debug
I don't know if this is directly related to this version... but that's it.
(the rest seems to work well ... at least as far as I've tried) |
| |
spider-j
Registered: Oct 2004
Posts: 444 |
Quote: Quoting spider-jClicking on "CRT controls" occasionally just shows thin borderlines and the content from the windows / desktop below
Didn't happen with the "Mixer controls" switch so far.
Weird, on my box (Debian 10.3 with Cinnamon, i5-7400 + nvidia 1060GTX 3GB) that works fine with both trunk and dqh's branch.
I recently did some work on the CRT sliders, reducing vertical space by using two columns and using larger negative margins for the sliders (yay Gtk).
Does this also happen with trunk?
Nope, doesn't seem to happen with trunk here. |
| |
Flavioweb
Registered: Nov 2011
Posts: 447 |
Found another problem.trace load $dc01
causeslocking: "configure-event"[G_CALLBACK(on_window_configure_event)]
Error: lib_debug_guard_add(): Out of debug address slots. (increase LIB_DEBUG_SIZE)
Error: lib_debug_alloc(): Out of debug address slots. (increase LIB_DEBUG_SIZE!)
Error: lib_debug_guard_add(): Out of debug address slots. (increase LIB_DEBUG_SIZE)
Error: lib_debug_alloc(): Out of debug address slots. (increase LIB_DEBUG_SIZE!)
Error: lib_debug_guard_add(): Out of debug address slots. (increase LIB_DEBUG_SIZE)
uimon.c:160: Error: lib_debug_guard_size(): Cannot find debug address 0x7f1bf003a350!
uimon.c:160: Error: lib_debug_guard_remove(): Cannot find debug address 0x7f1bf003a350! (make sure to use functions from lib.h, do NOT use lib_free on pointers allocated by other functions.) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
i like how basically our own code says its broken =D |
| |
spider-j
Registered: Oct 2004
Posts: 444 |
I get the same "CRT controls" glitch on my laptop. It's pretty much the same system regarding software.
Intel i5-7200U, HD Graphics 620, Gnome 3 via xorg-server
Kernel 5.6.13-arch1-1, mesa 20.0.7-2, gtk3 1:3.24.20-1, gnome-desktop 1:3.36.2-1, xorg-server 1.20.8-2
By the way: the controls don't seem to be the same as in trunk. So it could be this glitch did exist in trunk at some point in the past and it's here because the current state isn't in the github repo? |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Could be. Though my changes in the ctrcontrols.c are mostly limited to splitting the widgets into two columns, nothing fancy. I do use a little CSS to reduce vertical space, but that worked before and still works on my box.
I haven't added anything that would require changing my code to use the threaded stuff. |
| |
dqh
Registered: Jun 2019
Posts: 46 |
Quoting FlaviowebFound another problem.trace load $dc01
causeslocking: "configure-event"[G_CALLBACK(on_window_configure_event)]
Error: lib_debug_guard_add(): Out of debug address slots. (increase LIB_DEBUG_SIZE)
Error: lib_debug_alloc(): Out of debug address slots. (increase LIB_DEBUG_SIZE!)
Error: lib_debug_guard_add(): Out of debug address slots. (increase LIB_DEBUG_SIZE)
Error: lib_debug_alloc(): Out of debug address slots. (increase LIB_DEBUG_SIZE!)
Error: lib_debug_guard_add(): Out of debug address slots. (increase LIB_DEBUG_SIZE)
uimon.c:160: Error: lib_debug_guard_size(): Cannot find debug address 0x7f1bf003a350!
uimon.c:160: Error: lib_debug_guard_remove(): Cannot find debug address 0x7f1bf003a350! (make sure to use functions from lib.h, do NOT use lib_free on pointers allocated by other functions.)
This looks like something i fixed a day or two ago, if you get the latest do you still see this? |
| |
Flavioweb
Registered: Nov 2011
Posts: 447 |
Quoting dqhThis looks like something i fixed a day or two ago, if you get the latest do you still see this?
I've cleared, downloaded and compiled from scratch everything and now the "trace" crash seems gone.
But the "chis" freeze still here.
I got tons of Error: lib_debug_guard_add(): Out of debug address slots. (increase LIB_DEBUG_SIZE)
Error: lib_debug_alloc(): Out of debug address slots. (increase LIB_DEBUG_SIZE!) untiluimon.c:141: Error: lib_debug_guard_remove(): Cannot find debug address 0x27868bc0! (make sure to use functions from lib.h, do NOT use lib_free on pointers allocated by other functions.)
free(): invalid pointer then x64sc crash. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
Here is the next build. This one is what the windows peoples have been waiting for. seriously :) https://sourceforge.net/projects/vice-emu/files/experimental%20.. |
| |
Burglar
Registered: Dec 2004
Posts: 1031 |
well, I'm rolling back :) was running fine, but I hit alt-w often and then this happened (on linux):
Quote:(x64:11625): Pango-CRITICAL **: 20:45:47.186: pango_layout_set_attributes: assertion 'layout != NULL' failed
(x64:11625): Pango-CRITICAL **: 20:45:47.186: pango_layout_set_alignment: assertion 'layout != NULL' failed
(x64:11625): Pango-CRITICAL **: 20:45:47.186: pango_layout_set_ellipsize: assertion 'PANGO_IS_LAYOUT (layout)' failed
(x64:11625): Pango-CRITICAL **: 20:45:47.186: pango_layout_set_wrap: assertion 'PANGO_IS_LAYOUT (layout)' failed
(x64:11625): Pango-CRITICAL **: 20:45:47.186: pango_layout_set_single_paragraph_mode: assertion 'PANGO_IS_LAYOUT (layout)' failed
**
Gtk:ERROR:../../../../gtk/gtklabel.c:3396:gtk_label_update_layout_width: assertion failed: (priv->layout)
Aborted (core dumped)
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
more verbose please, what git version exactly? :) |
| |
Burglar
Registered: Dec 2004
Posts: 1031 |
commit 3cc4e63ee2d3c30776877fe69f08f2288f3dc4fe (HEAD -> threaded-ui-exp, origin/threaded-ui-exp) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
here is a 32bit build for the retro OS users: https://sourceforge.net/projects/vice-emu/files/experimental%20.. |
| |
iAN CooG
Registered: May 2002
Posts: 3132 |
Thanks, much appreciated.
I tested vsid, but after playing a tune, alt-tab to write here, alt-tab to get back to it, and the window didn't redraw anymore, not responding, and after few seconds had to be closed forcefully.
Seems randomly crashing even selecting another tune. I can provide a .dmp if it helps. |
| |
dqh
Registered: Jun 2019
Posts: 46 |
Quoting Burglarwell, I'm rolling back :) was running fine, but I hit alt-w often and then this happened (on linux):
Quote:(x64:11625): Pango-CRITICAL **: 20:45:47.186: pango_layout_set_attributes: assertion 'layout != NULL' failed
(x64:11625): Pango-CRITICAL **: 20:45:47.186: pango_layout_set_alignment: assertion 'layout != NULL' failed
(x64:11625): Pango-CRITICAL **: 20:45:47.186: pango_layout_set_ellipsize: assertion 'PANGO_IS_LAYOUT (layout)' failed
(x64:11625): Pango-CRITICAL **: 20:45:47.186: pango_layout_set_wrap: assertion 'PANGO_IS_LAYOUT (layout)' failed
(x64:11625): Pango-CRITICAL **: 20:45:47.186: pango_layout_set_single_paragraph_mode: assertion 'PANGO_IS_LAYOUT (layout)' failed
**
Gtk:ERROR:../../../../gtk/gtklabel.c:3396:gtk_label_update_layout_width: assertion failed: (priv->layout)
Aborted (core dumped)
This one is fixed in the Windows version, or worked around at least. I'll be making the latest fixes available for linux and mac soon. |
| |
dqh
Registered: Jun 2019
Posts: 46 |
Quoting iAN CooGThanks, much appreciated.
I tested vsid, but after playing a tune, alt-tab to write here, alt-tab to get back to it, and the window didn't redraw anymore, not responding, and after few seconds had to be closed forcefully.
Seems randomly crashing even selecting another tune. I can provide a .dmp if it helps.
What platform is this happening on? We'll update here when the latest fixes (developed on a Windows specific branch) have been merged back to the threaded-ui-exp for linux and macOS. |
| |
iAN CooG
Registered: May 2002
Posts: 3132 |
dqh: I'm on win7 32bit, 4Gb RAM |
| |
iAN CooG
Registered: May 2002
Posts: 3132 |
Just to add some vsid bugs, after loading a sid with alt-L, I exited via file menu->exit with mouse, audio got in a loop on the last emitted note before the window closed, and vsid.exe got stuck in memory and had to be killed manually. Doesn't happen with alt-q or alt-f4.
Sometimes crashes DURING loading, just tried from open file dialog to load some tunes from /DEMOS/UNKNOWN.
Too early stage for me to be actually using this. Back to 3.2 normal (but working) version. |
| |
dqh
Registered: Jun 2019
Posts: 46 |
Quoting iAN CooGJust to add some vsid bugs, after loading a sid with alt-L, I exited via file menu->exit with mouse, audio got in a loop on the last emitted note before the window closed, and vsid.exe got stuck in memory and had to be killed manually. Doesn't happen with alt-q or alt-f4.
Sometimes crashes DURING loading, just tried from open file dialog to load some tunes from /DEMOS/UNKNOWN.
Too early stage for me to be actually using this. Back to 3.2 normal (but working) version.
Were you testing the build from the first post in this thread or the updated one from May 29? The main focus is on the full emulators at the moment, but we'll circle back around to vsid at some point.
Anything involving a dialog that causes sound glitches is known and should be dealt with before the official release. Still a lot of work to do before then. That said, these latest windows builds fix a LOT of issues that all older GTK builds have had. In particular, scrolling should now be as smooth as it can be for a given host display. |
| |
iAN CooG
Registered: May 2002
Posts: 3132 |
dqh: the 32bit version posted by groepaz, as it's the ONLY 32bit build available to my knowledge. So far I couldn't try any version, I can't run 64bit exes =) |
| |
hedning
Registered: Mar 2009
Posts: 4595 |
Quote: dqh: the 32bit version posted by groepaz, as it's the ONLY 32bit build available to my knowledge. So far I couldn't try any version, I can't run 64bit exes =)
Someone send ian coog a new laptop. He is worth it. |
| |
iAN CooG
Registered: May 2002
Posts: 3132 |
I don't want a freaking laptop, you can keep it =)
I just don't change PC when they work, when I have to, I'll do it =) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
New windows build: https://sourceforge.net/projects/vice-emu/files/experimental%20.. (64bit) and https://sourceforge.net/projects/vice-emu/files/experimental%20.. (32bit)
Linux and Macos users that can build it really also want to try the latest version from the repo mentioned in the first post (yes, you will need GL). You'll get absolutely gorgeous scrolling and the lowest sound latency ever. |
| |
dqh
Registered: Jun 2019
Posts: 46 |
FYI these builds fix various issues such as the 'chis' problem, and 'Pango' problem and the deadlock on File->Exit shutdown. LOTS of improvement since the last builds, and a new 50/60/custom FPS target mode. |
| |
dqh
Registered: Jun 2019
Posts: 46 |
macOS binaries:
https://sourceforge.net/projects/vice-emu/files/experimental%20.. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: macOS binaries:
https://sourceforge.net/projects/vice-emu/files/experimental%20..
Alot better now and with substantially less CPU power used. Great work. (Full screen and window scaling still is a mess though, but that's not important in comparison to the fixes you've made so far).
Great work, keep it up! Feels like the GTK-build is getting quite usable now finally. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
did you reset the settings? scaling and fullscreen should work, afaik :) |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: did you reset the settings? scaling and fullscreen should work, afaik :)
Hmm, no I didn't. :) But now when I did the main window is just gray. I can see one raster line of graphics at the very bottom but nothing more. Resizing window etc doesn't make it work. So now the emulator is in a hopelessly unusable state. :D
(I removed ~/.config/vice/vicerc and the emulator recreated that file when I manually saved the settings)
[C64SC]
Window0Height=621
Window0Width=720
Window0Ypos=23
SoundDeviceName="coreaudio"
SoundBufferSize=100
VICIIVideoCache=0
SidEngine=1
SidModel=1
Acia1Base=56832
Manually adding Window0Xpos=23 to the config makes it work again so I suspect it has a missing default value there that needs to be fixed.
Scaling still doesn't work. Messing with Hardware scaling, Keep aspect ratio and True aspect ratio gives different (wrong) results. |
| |
dqh
Registered: Jun 2019
Posts: 46 |
Hm that's extremely weird. These are the first macOS GTK builds where the resizing problem is fixed (and macOS is my primary dev / test case)
What version of macOS are you running? What hardware? |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Hm that's extremely weird. These are the first macOS GTK builds where the resizing problem is fixed (and macOS is my primary dev / test case)
What version of macOS are you running? What hardware?
macOS Catalina (10.15.4), 2.9 GHz 6-Core Intel i9, 16GB, Intel UHD Graphics 630.
The vice.log reveals nothing suspicious. |
| |
dqh
Registered: Jun 2019
Posts: 46 |
Yes - i've just replicated the issue on a Catalina mac, sorry. Will look into it tomorrow. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Yes - i've just replicated the issue on a Catalina mac, sorry. Will look into it tomorrow.
No need to be sorry. I'm just happy that you can replicate it! :D |
| |
Dano
Registered: Jul 2004
Posts: 226 |
WOW! That 64bit version runs so so butter smooth on my system. 50fps fluently without any drops and shizz. And it even runs without me having to switch to cairo or use "start with nvidia".
Can't wait until this is avaiable in the normal trunk! |
| |
Flavioweb
Registered: Nov 2011
Posts: 447 |
Runs just smooth now...
Chapeaux. |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
Seems to work fine on my MacBook Pro running High Sierra, 10.13.6. The model is a late 2011, with 13" screen, 2.4 GHz Intel Core i5, 16 GB 1333 MHz DDR3, Intel HD Graphics 3000 512 MB.
One thing I noticed is that the window contents flashes in a quite disturbing way when warp mode is on, e.g. when loading programs and such. Doesn't affect usability really, but perhaps that's good to know in case it indicates something. |
| |
dqh
Registered: Jun 2019
Posts: 46 |
Here's an updated mac build: https://sourceforge.net/projects/vice-emu/files/experimental%20..
@JackAsser - I have fixed rendering on macOS 10.15, at least for my own test case.
@Frantic - any chance you also test this build? If the flashing problem is still there would you be able to describe it in more detail, or ideally take a slo-mo video of it on your phone and put the video on youtube or somewhere? |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Confirmed, works fine now with scaling and fullscreen, even on multiple screens. Good work! |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
VICE on your videowall? :) |
| |
dqh
Registered: Jun 2019
Posts: 46 |
Great! It was a weird one - if i built it directly on 10.15 it was fine, but not if i built on 10.14 and then ran on 10.15. But I found that by calling glViewport(...) each frame everything worked again when built on 10.14, so i'm guessing they made a change to OpenGL in the latest SDK. Which is a bit weird given that it's deprecated now. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
Break it before you put it in the bin? I do that sometimes with stuff i dont want others to use anymore :=) |
| |
dqh
Registered: Jun 2019
Posts: 46 |
haha it did occur to me :) It would be very weird of them to drop the runtime altogether though, a lot of games will just stop working and never get updated.
It's plausible they reimplemented it as a wrapper over Metal or something .. |
| |
MagerValp
Registered: Dec 2001
Posts: 1055 |
Apple doesn't care about cross-platform gaming and probably never will, it's pretty clear it's Metal or gtfo. They rarely break stuff intentionally at least, but neglect and death from a thousand cuts does the job just as well.
Anyway, I gave the latest Mac build a spin and it's the first one that I feel approaches something that can be used. Frame rate is smooth and stable, no obvious glitches and no crashes during (light) testing on a 2014 MacBook Pro running 10.15.5.
The only display related issue is that the cpu/fps counter updates in realtime and thus jumps around between 99.9% and 100.0% in a rather distracting manner. Nothing a smoothed out average wouldn't fix though.
The only major issue I can find is that I can't seem to get the positional keyboard layout (the only sane option) to work. Is a keymap required for that — GTK3 doesn't do keycodes? The symbolic (ew) keymap for Swedish can't type $, and the positional option is grayed out if you select it. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Break it before you put it in the bin? I do that sometimes with stuff i dont want others to use anymore :=)
Apple are experts on this, especilly on the iOS-SDKs. :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
you do, of course, need a keymap. when it is greyed out it means it doesnt exist (which is true for swedish keyboard). Locate the gtk3_pos.vkm (or gtk3_pos_de.vkm, start with the one that gives you least wrong mapped keys) in the datadir, make a copy named gtk3_pos_se.vkm, select that one as user defined positional map, enable keyboard debugging in the settings (that will show the keycodes in the statusbar when you press keys), and start hacking away. you need to reload the keymap to apply changes, it can be a bit fiddly too. and last not least: please provide the result so we can include it :) |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Apple doesn't care about cross-platform gaming and probably never will, it's pretty clear it's Metal or gtfo. They rarely break stuff intentionally at least, but neglect and death from a thousand cuts does the job just as well.
Anyway, I gave the latest Mac build a spin and it's the first one that I feel approaches something that can be used. Frame rate is smooth and stable, no obvious glitches and no crashes during (light) testing on a 2014 MacBook Pro running 10.15.5.
The only display related issue is that the cpu/fps counter updates in realtime and thus jumps around between 99.9% and 100.0% in a rather distracting manner. Nothing a smoothed out average wouldn't fix though.
The only major issue I can find is that I can't seem to get the positional keyboard layout (the only sane option) to work. Is a keymap required for that — GTK3 doesn't do keycodes? The symbolic (ew) keymap for Swedish can't type $, and the positional option is grayed out if you select it.
Yep, for me personally (which you shouldn't use as a priority of any sort) are:
* Positional keyboard working
* Proper 1351 mouse emulation (mouse capture it totally borked now on my setup)
When this is done, I can drop SDL and move to GTK for EotB related tasks.
But I'm in no way in actual need of a GTK port, it would just be a nice thing to have. And also, if it's on par and up to date with the SDL port you guys can drop the SDL port also. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
Regarding the keyboard, see above. I couldnt fix it even if i wanted (because my system is using german locale, and i dont have a swedish keyboard either in the first place) :) So thats something one of you has to provide :=)
Mouse emulation will be fixed properly later. We already talked about polling the inputs more often than once per frame - which is absolutely required for perfect 1351 emulation (the POT inputs sample period is 512 cycles). It shouldnt work significantly worse than in the SDL port however.
(and the SDL port will always be kept around for "lesser" systems, mobile, game cabinets, etc) |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Regarding the keyboard, see above. I couldnt fix it even if i wanted (because my system is using german locale, and i dont have a swedish keyboard either in the first place) :) So thats something one of you has to provide :=)
Mouse emulation will be fixed properly later. We already talked about polling the inputs more often than once per frame - which is absolutely required for perfect 1351 emulation (the POT inputs sample period is 512 cycles). It shouldnt work significantly worse than in the SDL port however.
(and the SDL port will always be kept around for "lesser" systems, mobile, game cabinets, etc)
Ahh it’s not the polling per se but rather how it grabs the pointer from the OS |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
THAT can be probably be fixed soonish :) Probably a side effect of the UI updates :) |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: THAT can be probably be fixed soonish :) Probably a side effect of the UI updates :)
Highly likely |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quoting GroepazRegarding the keyboard, see above. I couldnt fix it even if i wanted (because my system is using german locale, and i dont have a swedish keyboard either in the first place) :) So thats something one of you has to provide :=)
Should we be reading that as: you want a Swedish keyboard sent to you? ;) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
NO :) |
| |
dqh
Registered: Jun 2019
Posts: 46 |
JackAsser - btw you should be able to build it directly in 10.15 now. |
| |
MagerValp
Registered: Dec 2001
Posts: 1055 |
Positional keyboard layout for Swedish added here, please test: https://sourceforge.net/p/vice-emu/patches/231/ |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: JackAsser - btw you should be able to build it directly in 10.15 now.
Ossom!! I might even have a go on fixing the mouse myself so you can focus on the important stuff. :) |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
@dqh: I tried the updated version and the flashing in warp mode that I mentioned was gone now. Good work!
(I agree with Magervalp btw, that the super frequently updated cpu/fps information is somewhat disturbing as well as it keeps changing and therefore captures attention.) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
I am fixing the broken mapping mode (that noone should use) in AR and RR atm - thats important enough for you? =P |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: I am fixing the broken mapping mode (that noone should use) in AR and RR atm - thats important enough for you? =P
:) Not the slightest! The only carts I use in VICE are those I wrote myself. :D |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quote: I am fixing the broken mapping mode (that noone should use) in AR and RR atm - thats important enough for you? =P
The one that is different in Atomic/NR? What was wrong in the AR and RR implementation in vice? I might have known but don't remember anymore unfortunately. |
| |
Burglar
Registered: Dec 2004
Posts: 1031 |
just recompiled latest threaded-ui-exp (commit f381f0f8d32df215f11005c53f1b49c8ac4de364) on linux.
runs pretty great! but two minor bugs got introduced (longer ago, also my prev builds have the bug): the drive led doesnt work and track/sector display only shows "18.5".
must say, I truly appreciate all the recent work you guys are doing, improvements are huge, keep it up! :)
and feel free to reach out if you need someone to test something on linux, happy to pull 'n build whenever. |
| |
dqh
Registered: Jun 2019
Posts: 46 |
Thanks Burglar, you're the first to mention the drive LED and related not being updated :) They're disabled on purpose at the moment because of needing a non-trivial change to make it safe to update those from the non-UI thread. But they'll be sorted out soon. |
| |
Burglar
Registered: Dec 2004
Posts: 1031 |
good to hear it's a known thing :) thanks for the quick response! |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
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...) |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
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: 11108 |
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: 1153 |
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: 1989 |
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: 1989 |
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: 1989 |
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: 11108 |
aaaaarg. another thing we need to solve with archdep code? SATAN! |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: aaaaarg. another thing we need to solve with archdep code? SATAN!
Yup.. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
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: 11108 |
i already hate that idea :) |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: i already hate that idea :)
Not keen either tbh, but it actually offers a thin HID-wrapper which means that joysticks, keypads and relative mouse could be handled in a uniform way. Keyboard and light pen could and should still be handled by gtk.
But the rewrite would be massive and nobody will do it. :) |
| |
dqh
Registered: Jun 2019
Posts: 46 |
cadaver - thanks for the report. Once I’m finished playing with rendering performance I’m going to shift my focus to audio (all platforms). I think audio is the last major source of performance glitches, depending on the sync method and driver. |
| |
dqh
Registered: Jun 2019
Posts: 46 |
JackAsser - btw, have you tried the Xcode support via the —enable-cmake feature? I find it very useful for debugging. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
and why am i compiling in windows AND ITS SO FUCKING SLOW I WANT TO KILL SOMEONE |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: and why am i compiling in windows AND ITS SO FUCKING SLOW I WANT TO KILL SOMEONE
I do make -j12 on the cmdline, takes about 10s.
Havn’t tried xcode yet? New or legacy build system? |
| |
dqh
Registered: Jun 2019
Posts: 46 |
Just configure in-tree normally, but add --enable-cmake to the configure line to generate a cmake build system from the autoconf makefiles. Or just run cmake-bootstrap.sh on a configured tree.
From there it's usual cmake stuff, i.e. create a build folder, cd to it, then cmake -G Xcode <path to vice folder> to generate an Xcode project. Or even just cmake <path to vice folder> to generate regular makefiles that work faster with make -j than the autoconf ones. And also, the cmake projects let you build a single emu rather than all of them if you want. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Just configure in-tree normally, but add --enable-cmake to the configure line to generate a cmake build system from the autoconf makefiles. Or just run cmake-bootstrap.sh on a configured tree.
From there it's usual cmake stuff, i.e. create a build folder, cd to it, then cmake -G Xcode <path to vice folder> to generate an Xcode project. Or even just cmake <path to vice folder> to generate regular makefiles that work faster with make -j than the autoconf ones. And also, the cmake projects let you build a single emu rather than all of them if you want.
Oh thanks! Will definetly try!
Edit: Building in XCode is sooo much faster and nicer than the Make-command-line system. Thanks for that hint! |
| |
dqh
Registered: Jun 2019
Posts: 46 |
No worries, and debugging is a lot nicer than using the command line debugger directly.
FYI if you pull the latest from my threaded-ui-exp branch you’ll get proper retina support, makes a big difference when the CRT filter is enabled. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: No worries, and debugging is a lot nicer than using the command line debugger directly.
FYI if you pull the latest from my threaded-ui-exp branch you’ll get proper retina support, makes a big difference when the CRT filter is enabled.
Ossom!! |
| |
Burglar
Registered: Dec 2004
Posts: 1031 |
Bug report for latest threaded-ui-exp (commit a4f8366237bdbd39c8ff9384d4aa46297f887669) on linux (Ubuntu 18.04.4 LTS).
I compiled with --enable-new8580filter --enable-native-gtk3ui
x64sc hangs when starting vice with a d64 like /opt/vice-threaded-ui-exp-20200615/bin/x64sc demo.d64
No errors are logged, last vice output: AUTOSTART: Autodetecting image type of `demo.d64'.
Vice is running, window is allocated on screen but completely invisible. I can "focus" on it by clicking the area where it should've been, or by clicking the icon. alt-f4 will then crash the process with the following message:
gnome-shell[30250]: JS ERROR: TypeError: windowActor is null
_removeWindowEffect@resource:///org/gnome/shell/ui/closeDialog.js:90:13
wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
vfunc_hide@resource:///org/gnome/shell/ui/closeDialog.js:184:9
wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
Now, the interesting thing is, vice works fine if I just open it directly without a file specified. Selecting a d64 works and emu runs great. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
....and i can reproduce this here :) smells like a locking issue to me :) |
| |
dqh
Registered: Jun 2019
Posts: 46 |
Yep, it was, related to a recent lock refactoring I did. I have pushed a fix. |
| |
dqh
Registered: Jun 2019
Posts: 46 |
Really appreciating the testing people are doing btw :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
works for me :) |
| |
Burglar
Registered: Dec 2004
Posts: 1031 |
wth, this is too quick guys :) will test as well now (done, works:)
for future testing, just do as you guys do now, post in this thread and I'll do another build, but I'm not as fast as you lol ;) |
| |
Burglar
Registered: Dec 2004
Posts: 1031 |
got some stability issues on linux, only when toggling warpmode, especially when toggling fullscreen too.
some logs:
no backbuffer to render to
no backbuffer to render to
lock count now 2, (already locked)
new frame ticks: 19950306.000000)
lock count now 1, (still locked)
lock count now 2, (already locked)
locking: "unrealize"[G_CALLBACK (on_widget_unrealized)]
lock count now 3, (already locked)
lock count now 2, (still locked)
locking: "destroy"[G_CALLBACK(ui_main_window_destroy_callback)]
lock count now 3, (already locked)
locking: "destroy"[G_CALLBACK(destroy_statusbar_cb)]
lock count now 4, (already locked)
lock count now 3, (still locked)
lock count now 2, (still locked)
locking: "destroy"[G_CALLBACK(on_window_grid_destroy)]
lock count now 3, (already locked)
lock count now 2, (still locked)
lock count now 1, (still locked)
Exiting...
lock count now 2, (already locked)
lock count now 1, (still locked)
VIC-II: VSP Bug: safe channels are: 027. Emulation of memory corruption is disabled.
VIC-II: VSP Bug: safe channels are: 134. Emulation of memory corruption is disabled.
DESTROY
Sound: Closing device `alsa'
ui_shutdown |
| |
dqh
Registered: Jun 2019
Posts: 46 |
What method do you use to trigger warp mode / full screen?
What happens exactly ? Locks up? |
| |
Burglar
Registered: Dec 2004
Posts: 1031 |
just regular alt-W and alt-D. but especially when I got back from fullscreen to windowed, while warpspeed is enabled.
and yup it locks up sometimes, not always |
| |
dqh
Registered: Jun 2019
Posts: 46 |
Damn, I can’t replicate this on Ubuntu 20.04 (mainline kernel 5.7.1) and AMD gpu.
What OS are you using? What are your sound settings? Does the UI still respond or does everything lock up? |
| |
Burglar
Registered: Dec 2004
Posts: 1031 |
using Ubuntu 18.04.4 LTS (Linux 4.15.0-106-generic #107-Ubuntu SMP Thu Jun 4 11:27:52 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux)
I have to add though, my sound is sorta fucked, device driver compatibility issues I'm sure.
Will test on my linux laptop soon too, to make sure it's not caused by my machine itself. |
| |
dqh
Registered: Jun 2019
Posts: 46 |
Are you able to replicate with sound disabled? I ask because a while ago I took at our linux sound code and it's very basic (at least one of the drivers is, can't remember which). Can you also try ALSA vs Pulse etc |
| |
Burglar
Registered: Dec 2004
Posts: 1031 |
with sound disabled, there are no issues it seems.
now I gotta go to work, so won't be able to respond until much later :/ |
| |
dqh
Registered: Jun 2019
Posts: 46 |
The strange thing is that sound is disabled during warp :/ When you get a change, i'd appreciate an ALSA vs Pulse replication test if you can |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
I compiled the 32-bit version on Fedora LXDE and after "sudo x64sc" the outlines of the Vice window appear, but then this is aborted because:
No provider of glGetShaderiv found. Requires one of:
Desktop OpenGL 2.0
OpenGL ES 2.0
glxinfo | grep "version" shows:
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
Max core profile version: 0.0
Max compat profile version: 1.4
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 2.0
OpenGL version string: 1.4 Mesa 19.1.8
OpenGL ES profile version string: OpenGL ES 2.0 Mesa 19.1.8
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16
Is there some package containing glGetShaderiv I should install? |
| |
dqh
Registered: Jun 2019
Posts: 46 |
This branch currently requires OpenGL 3.2 - but i'll be backporting the previous VICE support for 'legacy' OpenGL sometime in the next few weeks. Mostly I just need an environment to test this in, will probably have to set up a VM. Thanks for the detailed info! |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
You are welcome. Thanks for your efforts! |
| |
Burglar
Registered: Dec 2004
Posts: 1031 |
Quote: The strange thing is that sound is disabled during warp :/ When you get a change, i'd appreciate an ALSA vs Pulse replication test if you can
When I switch to pulse, everything works fine.
I really think this is an issue with my machine, still need to test on my laptop.
please don't treat this as a bug-report :) first need to see if I can reproduce it on another machine, which I think I won't... |
| |
dqh
Registered: Jun 2019
Posts: 46 |
Thanks for letting me know, regardless of the state of your system it shouldn't be possible for the emulation to lock up like that, so I do see this as a bug. I believe our ALSA sound code operates in a simple blocking mode, which almost certainly is related to what you're seeing. I almost always test with pulse so i'll switch to ALSA now.
I don't suppose you're familiar with gdb? If I could replicate it, i'd run it in gdb then break into the debugger when the deadlock occurs. Then i'd get gdb to dump a stack trace for each thread to see what it's currently doing. My guess is that the UI/main thread is stuck inside mainlock_obtain() whilst the vice thread is blocking on snd_pcm_writei(...). |
| |
dqh
Registered: Jun 2019
Posts: 46 |
actually I have discovered a bug that could explain this, i'll let you know when there's a fix. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Hmms. did a git pull and when making now I get:
make[5]: *** No rule to make target `cairo_renderer.c', needed by `cairo_renderer.o'. Stop.
Any ideas? |
| |
dqh
Registered: Jun 2019
Posts: 46 |
Yep - autogen + configure again
Probably just configure actually, I changed makefiles but not configure.proto |
| |
dqh
Registered: Jun 2019
Posts: 46 |
Burglar - I pushed a fix earlier but I can’t see how it could be directly responsible for the problem you described. But nonetheless it would be good to know if the problem persists with the latest code if you get a chance? |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Yep - autogen + configure again
Probably just configure actually, I changed makefiles but not configure.proto
Great, thanks! |
| |
Burglar
Registered: Dec 2004
Posts: 1031 |
Quote: Burglar - I pushed a fix earlier but I can’t see how it could be directly responsible for the problem you described. But nonetheless it would be good to know if the problem persists with the latest code if you get a chance?
tried it out, problem persists on my linux desktop with alsa.
now I also compiled latest version on my linux laptop, and it really runs great. no issues so far :D |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
Ladies and Gentlemen: it has been merged! |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quote: Ladies and Gentlemen: it has been merged!
Works extremely well here on Ubuntu 20.04 LTS (64 bit), good work!
Q: Is there a way to make the fps display update a bit less frequently (lowpass/average perhaps)?
(or turn it off) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
Fixing the statusbar is next (also making drive status work again). |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Ladies and Gentlemen: it has been merged!
Great! |
| |
MagerValp
Registered: Dec 2001
Posts: 1055 |
Is it just me or is autostart/drag&drop of .prg broken? |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Is it just me or is autostart/drag&drop of .prg broken?
Broken / not implemented yet, hard to tell. :) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Works on my Debian 10.4 box with the Cinnamon desktop.
What OS/WM are you using? Also what filemanager? Gtk/GDK can be difficult with drag-n-drop, some OS's/WM's provide their data in a single newline-terminated string, some provide them in GLib structure with strings for each item, etc.
So to support drag-n-drop I need to specify multiple "drop-targets" and figure out which one to use. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
It should generally work, indeed :) (also does on windows AFAIK). |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Works on Windows 7 and 10, last time I checked, that's one of those 'special cases'.
If latest trunk still doesn't work, please recompile with --enable-debug-gtk3ui, that will spit out debug messages about what is being dragged and if the 'drag-target' accepts it.
Do note I cannot check MacOS, I don't have that either as a VM or on bare metal. That might be something for dqh to check. |
| |
MagerValp
Registered: Dec 2001
Posts: 1055 |
Mac, but I haven't looked into setting up a build env yet, only testing the builds posted here. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Ladies and Gentlemen: it has been merged!
Btw, when did you drop svn in favour of git? :D |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Works on Windows 7 and 10, last time I checked, that's one of those 'special cases'.
If latest trunk still doesn't work, please recompile with --enable-debug-gtk3ui, that will spit out debug messages about what is being dragged and if the 'drag-target' accepts it.
Do note I cannot check MacOS, I don't have that either as a VM or on bare metal. That might be something for dqh to check.
Did exactly this but don't get any debug info. The window simply don't accept dropped files and the file just bounces back from where it was dragged. Nothing on stdout. |
| |
Nutfreak
Registered: Apr 2009
Posts: 9 |
So ... umm ... a bit late to the party here.
Is the newest code-for-testing already in the vice-emu trunk, or should we continue to test the github code?
Currently on Void Linux (Poettering-free). |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
Quote:when did you drop svn in favour of git?
when will your nightly builds be ready? :) |
| |
Nutfreak
Registered: Apr 2009
Posts: 9 |
Got an error while linking: (github source)
/bin/ld: ../src/arch/gtk3/libarch.a(opengl_renderer_unix.o): undefined reference to symbol 'XSync'
/bin/ld: /lib64/libX11.so.6: error adding symbols: DSO missing from command line
I fixed it by manually adding -lX11 to the Makefile(s). Seems to be working fine at first sight. Watching the Lockdown 2020 entries as test :) |
| |
dqh
Registered: Jun 2019
Posts: 46 |
It’s all in SVN trunk now. You will definitely need to autogen and configure before it will build properly, if you already have a checkout. |
| |
Nutfreak
Registered: Apr 2009
Posts: 9 |
Ok, updated to the vice-emu svn trunk, but same problem;
$ svn up
[..]
$ ./autogen.sh
[..]
$ ./configure --disable-pulse --enable-native-gtk3ui
[..]
$ make -j10
[..]
/bin/ld: ../src/arch/gtk3/libarch.a(opengl_renderer_unix.o): undefined reference to symbol 'XSync'
/bin/ld: /lib64/libX11.so.6: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
[..]
Manually adding -lX11 to the Makefiles fixed this linker error. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Quote:when did you drop svn in favour of git?
when will your nightly builds be ready? :)
I hoped you forgot! |
| |
MagerValp
Registered: Dec 2001
Posts: 1055 |
I tried setting up a build env on my Mac, but all it ended up doing was rekindling my hatred for homebrew. I'll stick to testing binaries. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Quoting JackAsserDid exactly this but don't get any debug info. The window simply don't accept dropped files and the file just bounces back from where it was dragged. Nothing on stdout.
If nothing appears on stdout with --enable-debug-gtk3ui, that means the drop target (ie the emu) doesn't accept the drop-data. So it's safe to say drag-n-drop is currently broken for MacOS.
Until dqh is kind enough to have a look, you lazy MacOS bums with your fancy drag-n-drop will have to use 'Smart attach', for now =) |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Quoting JackAsserDid exactly this but don't get any debug info. The window simply don't accept dropped files and the file just bounces back from where it was dragged. Nothing on stdout.
If nothing appears on stdout with --enable-debug-gtk3ui, that means the drop target (ie the emu) doesn't accept the drop-data. So it's safe to say drag-n-drop is currently broken for MacOS.
Until dqh is kind enough to have a look, you lazy MacOS bums with your fancy drag-n-drop will have to use 'Smart attach', for now =)
:D |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: I tried setting up a build env on my Mac, but all it ended up doing was rekindling my hatred for homebrew. I'll stick to testing binaries.
It's actually easier now than it ever was. :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
unless you must do it every night :o) |
| |
dqh
Registered: Jun 2019
Posts: 46 |
MagerValp - have you followed the macOS-Howto.txt in the doc? Building on Mac using Macports or homebrew is simple now. |
| |
MagerValp
Registered: Dec 2001
Posts: 1055 |
Yeah the problem is with homebrew, GLEW is refusing to work. I'm also getting a bunch of useless dependencies pulled in — I need this laptop for work, I can't litter it with too much crap. Package management is great on Linux servers, but it's garbage on macOS. |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
I've done it with macports and had no problems with that. |
| |
dqh
Registered: Jun 2019
Posts: 46 |
Yeah, things have deps. Not much we can do about that :)
I’ll make new MacOS binaries soon, been busy with work last few days and also waiting for bug reports etc. |
| |
iAN CooG
Registered: May 2002
Posts: 3132 |
I have to admit that watching demos in 3.4 (GTK3VICE-3.4-win32-threaded-ui-20200609) is way smoother than ever, despite not being used to the new keyboard shortcuts and menus, and the plethora of annoyances, but I'll keep checking it for further improvements. |
