Homebrew Status Monitor Deux - Customizable successor of Status Monitor Overlay

  • Thread starter Thread starter masagrator
  • Start date Start date
  • Views Views 846
  • Replies Replies 9
  • Likes Likes 13

masagrator

The patches guy
Developer
Joined
Oct 14, 2018
Messages
7,248
Solutions
1
Reaction score
7,448
Trophies
3
XP
14,650
Country
Poland

Status Monitor Deux​


I released first version of Status Monitor Overlay almost 6 years ago. With advancements in tech i decided to take upon challenge of making something I wanted to do but in normal circumstances was too time consuming to be a viable option for me.

Status Monitor Deux is a structural revision of how Status Monitor Overlay works. Now each mode is a separate .smd file that you can modify however you want. Overlay is just a manager responsible for listing and interpreting .smd files and changing its settings. On top of that you can add extensions adding support for custom services via .smse files, by default you have included extensions for sys:clk and hoc:clk stable struct.

Decided to release it separately from Status Monitor Overlay because its changes were breaking too much in terms of how configuration works now.

Supports everything what Status Monitor Overlay supports, adds on top of that multiple new options. Utilizes heavily modified libtesla to improve performance and rendering capabilities.

2026053022121400.jpg2026053022122200.jpg2026053022122500.jpg

2026053022123500.jpg2026053022124100.jpg2026053022124500.jpg

2026053022125100.jpg2026053022143000.jpg

2026053022140800.jpg2026053022501700.jpg

Repository: https://github.com/masagrator/Status-Monitor-Deux
Releases: https://github.com/masagrator/Status-Monitor-Deux/releases
 
Last edited by masagrator,
Here is an example of something i did in 90 minutes
2026053115024500.jpg

Video from unfinished version, only difference are used symbols

You can download it from here
https://github.com/masagrator/SMD-Files/blob/main/Compact/Compact.smd

Requires sys-clk or hoc-clk to show all data properly

R - RAM load (white - CPU related, red - everything else which means basically GPU)
G - GPU load
F - fan rotation level
B - battery charge level
 
Last edited by masagrator,
  • Like
Reactions: DarkKRPG and Tyvar1
I noticed some vertical screen tearing on 0.2.0 while scrolling around in the menu, presumably an artifact of the "heavily modified libtesla". Is this something you plan to fix, or not important enough to bother?

Also I noticed that on the original status monitor, in Micro the arrows/inequality sign after frequencies would change when the frequencies changed. Now on Deux I always see ≠. The README says that either sys-clk or Horizon-OC is supported, and I have installed sys-clk v2.0.1-fix from Homebrew App Store (all files are identical to the GitHub release except metadata), is something wrong here?

Given that "Show RAM load" is checked but the overlay only shows used memory capacity, it seems like you're failing to fetch data from sys-clk? (The real clocks *are* visible in sys-clk's Ultrahand/Tesla panel.)
 
Is this something you plan to fix, or not important enough to bother?
I was considering not worth it until someone points out. I tested if my assumption was correct just now and it turned out it was, so just fixed the issue.

is something wrong here?
Issue existed because i compared kHz instead of mHz. Fixed.

Given that "Show RAM load" is checked but the overlay only shows used memory capacity, it seems like you're failing to fetch data from sys-clk? (The real clocks *are* visible in sys-clk's Ultrahand/Tesla panel.)
This happens because i assumed that sys-clk like hoc-clk uses buffer for retrieving its context, but it turns out it uses simple Out pointer. I fixed that too.

https://github.com/masagrator/Status-Monitor-Deux/releases/tag/0.2.1
 
Last edited by masagrator,
  • Like
Reactions: hippy dave
Not particularly a bug report, but I keep misreading the option descriptions as belonging to the option above them, even though the L-shaped line indicates they belong to the option above them. Would it be better to move them below the corresponding options (but make sure they're visible when you scroll to the option), or you don't plan to change this?
 
Not particularly a bug report, but I keep misreading the option descriptions as belonging to the option above them, even though the L-shaped line indicates they belong to the option above them. Would it be better to move them below the corresponding options (but make sure they're visible when you scroll to the option), or you don't plan to change this?
How it corresponds to option above them? This hook exists explicitly to show that it doesn't belong above

_____
|^Roof

This is technical reason. Doing it below will result in descriptions not being rendered for any option that is at the bottom of list, that's the cost of descriptions not being a part of focus list.
 
Oh yeah I noticed the SMD menu doesn't support touch input? This tripped me up and made me think my Switch was hung when I didn't have my Joy-Cons attached while the console was half-disassembled (I had to heat up the CPU to melt the thermal putty to get the back case to fit).
 
How it corresponds to option above them? This hook exists explicitly to show that it doesn't belong above

_____
|^Roof

I know the hook is there, but I still visually/implicitly match it with the wrong item until I intentionally pay attention.

I did notice another reason I visually grouped descriptions with the item above: there's a gray separating line between a description and its corresponding item, but no line between a description and its *unattached* item. IMO it's clearer to put a separating line between a description and the item it *doesn't* belong to (regardless of where you place the description)?

20260623_152322.png


This is technical reason. Doing it below will result in descriptions not being rendered for any option that is at the bottom of list, that's the cost of descriptions not being a part of focus list.

I found that many other menus (Ultrahand, some but not all overlays' config menus, unsure about Tesla) keep the selected item *centered* in the screen, with the exception of not scrolling the list above the top, or (unless it would show empty space above the list) below the bottom. I have some ideas for possible fixes:
  • Always keep the current item centered, except at the beginning and end of a list.
  • Always scroll the entire description into view, rather than only an item's clickable area.
  • Keep {the bounding box of the current item *and* description} centered, so the maximum visible description is a full page instead of half a page!
Your current code already has a scrolling issue: when you scroll a config's "Toggle settings" menu down, then move back up, the *first* description cannot be read again until you exit and reenter the menu! Fixing this would require the same changes as I mentioned above.
 
Lately I am changing priorities. As this tool is doing what I wanted it to do, I guess I will stop focusing on making mainly frontend tools from now on. Maybe I will fix some issues you pointed out at some point of time.

I want to focus more now on playing games and doing backend stuff related to other projects. Thanks to Claude some of those got much easier to do (even though it still will take many weeks/months to accomplish, but normally it would take years), so I want to push that further as long as Claude has good models available for free at reasonable limits.

I want to end other projects i started years ago but never finished beforehand - but that's related to VN translations. Because I have 3 projects that went radio silent, i will finish them by using LLM for translation and put them up to download. I don't care about their quality, it's more about publishing properly working toolset to translate those games if someone would want at some point translate them properly. Though at least one of them has promising translation quality, second one has very weird sentences but story is still understandable. Just finished translating third one, but i didn't start playing it yet.

For other project i will not mention its details because someone could make this faster if they had money to pay for tokens. :D It's something that may be interesting for some game modders and will solve an issue that game modding scene had for years, existing solutions are partially bugged or rely on tools under NDA.
 
Last edited by masagrator,
  • Like
Reactions: Tyvar1
Lately I am changing priorities. As this tool is doing what I wanted it to do, I guess I will stop focusing on making mainly frontend tools from now on. Maybe I will fix some issues you pointed out at some point of time.

I want to focus more now on playing games and doing backend stuff related to other projects.
I just want to say thank you for all the switch stuff you have given us 🎉
 

Site & Scene News

Popular threads in this forum