stonesense
stonesense copied to clipboard
DFHack
Support PRINT_MODE: FRAME_BUFFER instead of just 2D
PRINT_MODE:2D uses over 100% CPU on macOS, which is not optimal compared to PRINT_MODE:FRAME_BUFFER, which uses <7% CPU on average. It would be nice if stonesense supported modes that didn't melt my CPU.
Edit: STANDARD or VBO would also work. I've just found FRAME_BUFFER uses the least CPU.
STANDARD is unsupported because of numerous opengl issues, ranging from crashes to kernel panics (but not including anything useful). I didn't try testing FRAME_BUFFER but i imagine it would be similar.
Why is stonesense even tied to what PRINT_MODE df is using at all? Doesn't Allegro handle stonesense's window?
I think the issue is two things using opengl in the same process in unsafe ways.
IMHO somebody with more knowledge about curses should look into this: https://github.com/Baughn/Dwarf-Fortress--libgraphics-/blob/master/g_src/renderer_curses.cpp And try to fix it at the source
@lethosor Are the opengl issues from Allegro? I've never had an opengl crash in DF outside of the SDL/fullscreen button one.
I don't know for sure what the issue is, just that a combination of DF and Stonesense both using OpenGL is very unstable. My guess is that at least one (possibly both) of DF and Stonesense is doing something unsafe that causes these crashes when both are active, but I don't know how to narrow it down further.
Anyway, upgrading Allegro (from 5.0.9 to 5.0.11) has not fixed the issue in the past. I don't want to try it again on my own machine with Allegro 5.2, but feel free to if you want. I don't know if the issue is on the Stonesense/Allegro or DF/SDL side (or both), though.
Definitely possible it's both. I've seen processes with multiple OpenGL contexts before, so it's theoretically fixable. You're right that SDL 1.2 is old though, so I could see it using OpenGL incorrectly.
I'm also curious what happens for other modes, like FRAME_BUFFER, VBO, & TEXT. Surely TEXT won't have an OpenGL conflict?