Closed ghost closed 1 year ago
if this helps here is a video of strong dmm crashing https://www.youtube.com/watch?v=R7Kri5Udrzk
The log I've provided is irrelevant. Please send a log text where u're opening the map, not the latest log file.
I am experiencing this exact same issue, it crashes after "preparing tools".
Things I tried:
It seems to trigger the crash when I move my mouse. It opens a blank window and then when I move my mouse it immediately crashes.
oh i got it working just now today after messing with it again if you have amd drivers that are up to date you have to down grade them to an older version and it just works perfectly
(should i close this?)
What version did you downgrade to? Of course this would be yet another thing AMD broke... cough Apex Legends cough
What version did you downgrade to? Of course this would be yet another thing AMD broke... cough Apex Legends cough
22.5.1
oh i got it working just now today after messing with it again if you have amd drivers that are up to date you have to down grade them to an older version and it just works perfectly
(should i close this?)
@scottpalmer04 You can keep it open, so other will find the same problem easier.
So if it no longer works on current AMD drivers, do we just have to cross our fingers that a random AMD update fixes it even though they probably have no idea this thing exists?
Just wanted to update and confirm that rolling back to (in my case) 22.5.2 was a workaround for me.
So if it no longer works on current AMD drivers, do we just have to cross our fingers that a random AMD update fixes it even though they probably have no idea this thing exists?
Hard to say. I'm not an AMD user, so I can't test the problem. It's more likely someone with AMD will come and debug/fix the issue. Since the app is working, but crashing on a specific case - it's something specific to that place, not to the whole OpenGL stuff the app is using.
I'm willing to help how I can, I'm not much more than a dabbling coder but I'm an experienced troubleshooter who fixes or works directly with developers on issues like this for a living. Is there a more verbose log that can be enabled which would tell exactly what was happening when it crashed beyond just "loading tools"?
This still happens with the newest 22.8.2 drivers. What can I do to help resolve this?
Occurs with 22.10.1 AMD drivers on latest version.
I don't see it mentioned here yet, this does not affect version 1.x, only 2.x.
It no longer crashes upon opening a map on AMD driver version 22.11.1 . Sadly now environment assets don't load.
Same, I tried to reinstall AMD driver and now can click on things, but it still looks weird. Also the context menu works (displaying icons), probably not asset, but driver issue.
Yep, this is happening for me too. 22.5.2 are still the most recent drivers that allow SDMM to be functional.
Confirming latest AMD driver v22.11.2 also has the white screen issue.
Confirming latest AMD driver v22.11.2 also has the white screen issue. Bumping white issue
Experiencing distorted splotchy colors issue as well, AMD driver v22.11.2
I get a white featureless map on Win10/AMD 22.11.2. Rolling back to 22.5.1 resolves the issue.
This is still an issue on win10 22.11.2
Still an issue on the 13/02/2023 on Skyrat Codebases, does not occur on Baycode.
EDIT: Reconfirming, after rollback baystation appears to be affected too? Odd.
This may be hardware dependent and not neccessarily driver dependent, as this only occurred after upgrading my system on the 14/01/2023, where the CPU + RAM was upgraded; while the GPU stayed the same.
Could be a potential Windows 10 Driver problem in general for AMD systems.
Holds true on /vg/station code, AMD Software 22.11.2 on Windows 10 with an RX570.
Because OpenGL drivers are so buggy google implemented this: https://en.wikipedia.org/wiki/ANGLE_(software). Might be worth using it for StrongDMM too.
Confirming latest drivers released today, v23.2.2, still experience the issue.
Issue is still being experienced on 23.2.2
As of 3/15/2023 the newest driver (23.3.1) isn't compatible with strongDMM
FYI, this issue is most likely due to a rework of AMD's OpenGL driver on version 22.7.1 which improved performance for many applications, while also breaking a couple applications like Blender, SolveSpace among others.
@SpaiR here's a crashlog output from running 54bd092 through delve's dlv debug
, and going through the reproduction steps.
The log above the cutoff is very similar as the ones already posted, the rest of the program works fine, up until parts of the map have to be rendered.
Environment information:
22621.1325
go1.19.5 windows/amd64
1.20.1
gcc.exe (Rev10, Built by MSYS2 project) 12.2.0
22.10.3
Note: I should/will test this again on a newer driver soonish with delve, as some users in here reported that the editor at least does not crash. Maybe theres more usable output from that there.
But for now, here's what I got.Meanwhile, certain users might be interested in a workaround..
Since I've finally been able to test this: no issues running under Linux + Radeon, kernel 6.1.21 and a 6700 XT. StrongDMM performs significantly better than on Windows with the same hardware. The tgstation dme opens in under 2 seconds and maps are instant.
Tried getting any useful output on AMD driver 23.3.2
, but no dice.
There's definitely something wonky going on with rendering the sprites to the workspace. Although I doubt it's actually the sprites, but rather a shader? - assumption is based on the fact that the sprites still render in Dear ImGui perfectly fine (context menu and tree view), but maybe imgui just has a more robust way to do so than what the workspace does? I'm really not sure at the current moment. That's as far as I can help with any further isolation of the issue I'm afraid.
Also for context, as I wasn't aware until now from the above screenshots alone:
The full-white display happens simply because of the /area
s view being active.
If those get disabled on the newer (non crashing) drivers, then the objects and turfs are visible as colored rectangles of varying sizes. The color depends on the instance/prefab's color
property.
@Maurukas That is not a surprise, most filesystems on linux can work with the dme and dmm format much quicker. This is the same case with, for example, Stellaris, and any other game or application that depends on text-file I/O (but is also not solely attributed to it). There's more to it but I'll refrain from derailing this thread - this is about a Windows+AMD driver+Current implementation issue.
@atakiya Thank you for the investigation. Very detailed, found some new things. Specifically, an AMD clusterthing 🙃
but maybe imgui just has a more robust way to do so than what the workspace does
They have different rendering pipelines and shaders. I'm not a "hardcore GPU-based rendering master", so anything can be the cause 😅
Here is the source code for the ref:
Speaking about the issue itself - that is the reason why I don't like to work with GL directly. I have an idea to re-write rendering backend to use Ebiten game engine. It has renderers for OpenGL, Metal and DirectX. And, most importantly, an abstraction layer around the rendering routine. (Also, will open up the possibility to make StrongDMM a webapp, since ebiten supports wasm, but it's very small possibility for that.)
It remains to find time for this. 😞
@atakiya I'm unable to replicate your WSL success with either the debian or ubuntu images available for WSL. The base debian and ubuntu images are < glibc 2.32 which StrongDMM requires. The ubuntu 22.0.4 image has a compatible glibc, and I'm able to launch simple x11 apps (xcalc etc), but strongdmm segfaults in a profoundly unhelpful way.
Are you able to share the WSL distro and dependencies you used to get it working?
They have different rendering pipelines and shaders. I'm not a "hardcore GPU-based rendering master", so anything can be the cause 😅
Definitely know more than I do on that though 😄
Speaking about the issue itself - that is the reason why I don't like to work with GL directly. I have an idea to re-write rendering backend to use Ebiten game engine. It has renderers for OpenGL, Metal and DirectX. And, most importantly, an abstraction layer around the rendering routine. (Also, will open up the possibility to make StrongDMM a webapp, since ebiten supports wasm, but it's very small possibility for that.)
It remains to find time for this. 😞
That seems pretty promising; abstracting that away should definitely make things easier in the long term. SDMM as a Webapp via WASM sounds also quite intriguing. 👀
But yeah, I totally can get behind the time restraint, best wishes there!
@atakiya I'm unable to replicate your WSL success with either the debian or ubuntu images available for WSL. The base debian and ubuntu images are < glibc 2.32 which StrongDMM requires. The ubuntu 22.0.4 image has a compatible glibc, and I'm able to launch simple x11 apps (xcalc etc), but strongdmm segfaults in a profoundly unhelpful way.
Are you able to share the WSL distro and dependencies you used to get it working?
I've used the Fedora 37 Container Image, packaged by a third party, available here: https://www.microsoft.com/store/productId/9NPCP8DRCHSN (source available here: https://github.com/VSWSL/Fedora-WSL)
The only dependencies that were installed were libgtk3
, libx11
, and some more basic ones - I basically just ran down the missing linked dynamic libraries list from ldd ./StrongDMM
via dnf provides
until everything was satisfied, then it just worked.
The image might already contain a dependency or some tweak to make this work better, I'm unsure, but making my own WSL distro and such to test is a bit too much of a time sink right now :/
I tried to reproduce the same in the Debian store image, which, just as you mentioned, failed due the the GLIBC requirement.
The Ubuntu image from the store is on 22.04.2 LTS
, which has a compatible version.
I was able to get all shared libraries satisfied, but, while it didn't segfault, I just get a blank Window/broken buffer (I'm assuming).
Sadly I cannot help further there, my graphical linux & debian knowledge ends there as I use it more in the terminal and on Fedora / RHEL 😔 If you do get it working (on Ubuntu) though, do let me know! Would be very interested to know what breaks on there versus Fedora.
For transparency of the progress: I've tried to integrate ebiten. Unfortunately, it is not acceptable solution. It has its own pros, but major problems are overwhelming. The most critical is that Ebiten doesn't provide low level abstraction to handle application input events. Like for the correct work of the UI we need to handle input constantly, no matter in which tick or frame we are. Ebiten relies on the model, where you can handle inputs only in the fixed moments of the app lifecycle. Issue which should resolve the problem (https://github.com/hajimehoshi/ebiten/issues/1704) is still in the milestone and there is no information when it will be ready.
There are still some options, I'll continue the investigation...
Still same issue on the 23.4.3 version of driver.
Hello.
I just learned how to do this today. I finally, after getting my new AMD 6700 XT GPU a month ago, am able to use StrongDMM again. I'd like to thank Marv from Bee for teaching me a bit about how Linux worked, so I could put this together and get it working! The rest of the legwork was me banging my head against the wall haha.
This will be a Step-by-step guide in which you will:
Find and open Windows Powershell in Administrator mode
In powershell, type the command wsl --install
. Type Y if it gives you a prompt.
Restart your computer to let changes apply.
A new program will appear in your Windows Search after the restart, This will be the program you will be utilizing for the rest of this guide when running StrongDMM.
Windows Subsystem for Linux, or WSL for short, is a very cool tool putting Linux in an easy-to-access interface without you having to download some VM program or boot to Linux yourself. By default WSL uses Ubuntu, so we will stick to that.
You probably want to get right into downloading the necessary tools for WSL, but first you have to make a username and password! I'll let you decide on those. You will need to reenter your password everytime you close WSL or restart your computer, so choose wisely! The prompt will show as soon as you log in!
Right now, your WSL is rather limited, so let's get to downloading some additions for it! We specifically are looking for supporting the Linux GUI application, so that's what we are aiming for. A lot of these will be taking the mantle of what normal Win11 default programs do, cause they don't exist in this new environment you've created. Follow along here.
Execute sudo apt update
. This will update packages in your distro.
Execute sudo apt install gedit -y
. A text-editing tool
Execute sudo apt install gimp -y
. A image-editing, and more importantly, transcoding tool.
Execute sudo apt install nautilus -y
. A file explorer tool. Necessary, for obvious reasons.
Execute sudo apt install vlc -y
. A Multimedia player.
Execute sudo apt install x11-apps -y
. Fills in the gaps.
Your environment is complete and ready!
Go grab the Linux Download link! Extract if needed.
Put it in a recognizable location. I nested it one folder down from my C: drive. The file is the Linux version, the Application is the Windows version.
Time to Start it up! In this case, the directory to reach the file would be /mnt/c/SS13-Mapping/
. So we will type the command cd /mnt/c/SS13-Mapping/
. Looking something like this.
Now type ./StrongDMM
and Execute! It should begin! The app should launch and look a little like this!
So thats it! Thats how to get it working. You also taught yourself a little linux while doing it, and have an opportunity to learn a little more if you wanna delve into it!
Note that Linux will be using software rendering, which is really not efficient! I suggest downloading the Ubuntu Drivers from AMD(if you have the specific card listed there, of course)! https://www.amd.com/en/support/linux-drivers
Have fun, ping me if you have specific questions.
@Tsar-Salat Good stuff! I've put the link to it in the main issue message.
Just downgrade to 1.9.1, for simplicity. No need to go hoops around wsl
Just downgrade to 1.9.1, for simplicity. No need to go hoops around wsl
Limiting yourself to having no game optimizations or performance increases from updates by kneecapping yourself, all for a single program, makes "simplicity" rather subjective.
if you use your graphics card only for SS13, perhaps WSL is just hoops. Otherwise, its a very real concern.
Just downgrade to 1.9.1, for simplicity. No need to go hoops around wsl
Limiting yourself to having no game optimizations or performance increases from updates by kneecapping yourself, all for a single program, makes "simplicity" rather subjective.
if you use your graphics card only for SS13, perhaps WSL is just hoops. Otherwise, its a very real concern.
Not all mappers is willing to go through all that trouble just to map, plus they may have limited experience with wsl as well. How about you fix this issue?
Not all mappers is willing to go through all that trouble just to map, plus they may have limited experience with wsl as well.
Yes, as I said, it's entirely subjective to the user. The hostility is unnecessary.
How about you fix this issue?
I don't have the ear of the AMD execs, that's likely the only route to a fix at this point.
Then why does 1.9.1 work just fine. It's obviously something wrong with your implementation
Right
Still an issue on 23.7.2, I have had nothing but headaches with AMD products holy shit.
One day it will be fixed. How is strongdmm2 even better than strongdmm1?
I think at this point we can probably conclude that the maintainers just run nvidia cards and don't care because the issue doesn't affect them, and when people complain they'll just push it off on AMD, who is not going to change their drivers just for one extremely niche application (strongDMM is literally the only program I have issues with. I've heard reports of blender having issues but I also use blender and have had zero issues with it). Also the fact that pre v2 works fine shows it is fixable in StrongDMM's code. They just need to compare the openGL rendering in pre v2 to v2 and investigate why the prior renders fine. But since none of them likely run AMD cards they likely have no interest.
They just need to compare the openGL rendering in pre v2 to v2 and investigate why the prior renders fine. But since none of them likely run AMD cards they likely have no interest.
To clarify things: the problem was already discussed in details. And it's not like "compare how it was and find the difference". The diff is understandable, since the code between v1 and v2 is absolutely different. For example v1 was using OpenGL2 and v2 uses OpenGL3.
I think at this point we can probably conclude that the maintainers just run nvidia cards and don't care because the issue doesn't affect them, and when people complain they'll just push it off on AMD, who is not going to change their drivers just for one extremely niche application
I'm the only maintainer of the project. StrongDMM was done in my spare time for the unique experience of developing an app like this. But now my focuses have changed and I'm not willing to contribute time I've contributed before. So it's not like I don't care for AMD users - it's just not in my priority list at the moment. The problem itself is pretty obvious for me, but to resolve it I need to put away my daily things for 1-2 weeks of work. I'm not motivated to do that.
Speaking of motivation, there is a page to support me and the project: https://ko-fi.com/spair There was like 3-4 donations from StrongDMM users, which was very pleasant to see. It is not about the money, but about sincere gratitude. And from download stats I see that it was around 1500 downloads of the program. Numbers speak for themselves. I'm ready to move StrongDMM higher in my TODO list, but with support like that it won't happen in mean time for sure.
So to avoid future insinuations I'll close discussions. Everything was already discussed. If someone willing to fix the bug - welcome to the PR page. I'll merge it and make the new release.
I've managed to find AMD powered hardware, fix already available in v2.9.0.alpha release.
Workaround using WSL: https://github.com/SpaiR/StrongDMM/issues/161#issuecomment-1590465907
Version
v2.6.2.alpha
What happened?
When ever i try to load any map StrongDMM just crashes. (this happens when i use any codebase)
Reproduction
how i solved it
https://github.com/SpaiR/StrongDMM/issues/161#issuecomment-1232378939
Relevant log output