Problem description: Does anyone know what causes a players screen/map to freeze? their chat box still updates and they can still control their character/chat but the screen does not update
No but it does look like the memory usage is excessively high, like hovering at 1.1k-1.6k MB
| |
I just noticed when the screen/map freeze happens the CPU drops from being 8-10% to 0-0.2%
| |
Happens very frequently... i guess byond can't handle multiplayer pixel movement games
| |
It can handle them just fine, the memory usage indicates something very, very wrong in your code. You'll want to look at things like how many atoms exist at any given time, how many lists you have initialized, how many images are in use.
I know Linux DD has options for displaying memory statistics but I'm unsure if the Windows version does. On Linux you can enter "DreamDaemon" with no arguments to get a list of helpful commands and whatnot you can send to the process to get extra information. | |
How many images would you consider too many
| |
Over a hundred thousand. Usually when you do a memory trace from Linux the numbers make the problem super apparent because you'll see things at just absurd numbers.
| |
Apologies, been a while since I used Windows DD (as noted by the fact that I forgot it could send topic messages directly), there's an option under the 'World' menu that'll show you the memory stats I was talking about.
Wait until the game gets clunky and run that, should show the problem. | |
I'm hosting with linux, thanks for the help. Just waiting for my friend, who's hosting for me, to get back from work so he can send the information.
The map/screen freeze only happens to certain clients at certain times, i'm just not sure what triggers it yet. | |
Poor programming is likely the problem. Let's see some debugging information.
| |
Nadrew wrote:
Over a hundred thousand. Usually when you do a memory trace from Linux the numbers make the problem super apparent because you'll see things at just absurd numbers. How would you do this? Also I'd like to clarify that the numbers I gave were client side and that the freezes happen to indiviudals and not everyone. The servers CPU is not an issue and never rises past 40 | |
What about the memory usage on the server? The client should definitely not be hitting those numbers either. If the memory usage is excessive and the CPU isn't, and it only happens to certain users it would indicate something specific to their system.
Is your interface doing anything fancy like window transparency or putting labels on top of the map element? The first will force the game into software rendering mode, causing it to be dramatically less efficient and the second will cause performance drops on the client's end as it tries to deal with nonsense you shouldn't be doing in the first place. To spit out memory stats and a backtrace you can send the SIGUSR2 signal to the Linux process, your host should know how to do that. | |
Host here, brought game up with the -core, -trace, and -unsafe_diag, for gathering as much information as possible. Trace only had about 600 lines at first (mainly calling and exiting), and i was able to run/get the SIGUSR2 for the PID of the game.
However when people were really starting to have the issue again of client freezes/crashes with high client side memory i tried again, and it crashed/terminated DreamDaemon which then had written about 148k lines to the trace.txt, all looking somewhat like this: ../libdung/server/sfile.cpp:1217 Also before attempting to get the memory stats and a backtrace from SIGUSR2, i decided to check server through htop it showed DreamDaemon was not even at 300mb, as shown below (the top left of this screenshot, is the bottom of my task manager, i was at around 1200mb for Dream Seeker):  After leaving the server up for a short while, not letting it get to the point where getting the memory stats and backtrace for SIGUSR2 would crash the server, and actually spit out "stuff", this is what is printed on the command line: ************************************* | |
I had 2 invisible labels on top of the players map, ill take those out and see what happens. buuut im convinced it's also something else as at times the memory is stable at 300-400 but others its 1.1k-1.6k despite the player count remaining the same
| |
yea i moved those labels and put the map over everything memory is still spiking to the 1ks
| |
server mem usage:
Prototypes: obj: 251152 (1867) mob: 252176 (64) proc: 802024 (1350) str: 901634 (14462) appearance: 10118570 (42671) id array: 838864 (3840) map: 17435632 (300,300,20) objects: mobs: 1203520 (1075) objs: 13695888 (90514) datums: 14080 (455) lists: 3734496 (115356) I'm not sure if these numbers are high or not | |
That's a loooot of lists, appearances and objs. However, since your host mentioned that the server's memory isn't all that high and not everyone is experiencing the issue it would indicate it's a client-side issue.
This could be caused by a lot of things, the one I'm thinking is at fault is graphic card drivers and/or having multiple cards on one system and the wrong one is being selected by BYOND. This could cause the game to drop into software rendering mode which will cause a dramatic increase in memory usage and drop in performance. The fact it's not happening to all clients is proof enough it has something to do with the system setup those clients are running. | |
I dont think its the graphics card issue because it will happen randomly to anyone at any random time. I also checked to see if graphics hardware was enabled when my memory spiked and it was.
I also had cases where my memory was stable at 300-500 but others were stable at 1.2k | |
where the game at
| |
Sorry if that's too obvious, just wanted to cover the basics first.