Add basic OSD support #188

rapha-tech · 2025-03-13T15:41:00Z

The PR aims to add support for simple OSDs on retro-go during game emulation

…ats available

ducalex · 2025-03-17T18:34:07Z

Can you add back rg_display_get_width/height? For a long time I've tried to convince myself that doing rg_display_get_info()->screen.width is fine, but in reality it's just annoying... That's why I've recently added rg_display_get_width/height.

Inside rg_display.c you can access display.screen.width directly, that's no problem and you can leave those changes if you want.

Edit: I've also fixed the printf in snes on the dev branch, you can remove this unrelated change.

rapha-tech · 2025-03-18T07:43:48Z

Okay,
Also I forgot to answer your older message : I'd like to make things the right way even if it means spending a lot of time. If it can improve the rendering system it will be worth!
You also made me realise that font shadow will be an absolute need even if it is a bit costly since it is usually unreadable.

On the other hand I'm wondering if it still a good Idea to add transparency? But I can't think of an other way to have my battery icon without a rectangle "behind" it.

ducalex · 2025-03-31T19:48:51Z

launcher/main/gui.c

-        .width        = rg_display_get_width(),
-        .height       = rg_display_get_height(),
+        .width        = rg_display_get_info()->screen.width,
+        .height       = rg_display_get_info()->screen.height,


Should be undone

ducalex · 2025-03-31T19:49:23Z

retro-core/components/snes9x/src/memmap.c

-   printf("Rom loaded: name: %s, id: %s, company: %s, size: %dKB\n", Memory.ROMName, Memory.ROMId, Memory.CompanyId, Memory.CalculatedSize / 1024);
-   Settings.ForceHeader = Settings.ForceHiROM = Settings.ForceLoROM = Settings.ForceInterleaved = Settings.ForceNoHeader = Settings.ForceNotInterleaved = Settings.ForceInterleaved2 = false;
+   Settings.ForceHeader = false;
+   Settings.ForceHiROM = false;
+   Settings.ForceLoROM = false;
+   Settings.ForceInterleaved = false;
+   Settings.ForceNoHeader = false;
+   Settings.ForceNotInterleaved = false;
+   Settings.ForceInterleaved2 = false;
+
+   printf("Rom loaded: name: %s, id: %s, company: %s, size: %dKB\n",
+      Memory.ROMName, Memory.ROMId, Memory.CompanyId, (int)(Memory.CalculatedSize / 1024));


Should be undone.

ducalex · 2025-03-31T19:53:07Z

components/retro-go/rg_display.c

+        uint16_t *buffer = osd.surface->data; // Treat the buffer as 16-bit values
+        for (int i = 0; i < osd.surface->width * osd.surface->height; i++)
+            buffer[i] = C_TRANSPARENT; // Assign the C_TRANSPARENT color directly to the background


I have finally implemented rg_surface_fill, you should now be able to do rg_surface_fill(osd.surface, NULL, C_TRANSPARENT);

Although I'm not able to test my own code right now so maybe best don't waste your time...

ducalex · 2025-03-31T20:47:26Z

If we go ahead with transparency then I think we should reconsider how we handle things. Currently you rerender the background pixels which works fine but it bypasses the filtering system and it also makes the code more repetitive.

Bypassing the filtering for a few pixels in the case of a battery icon doesn't really matter, the pixels will be close enough. But it might cause visible weirdness if the OSD is bigger with more transparent zones.

One possibility I can think of is that in the for (int y = 0; y < draw_height;) { ... } loop we check if the lines we've just rendered intersect the OSD. if so, we draw the concerned OSD portion over it and set need_update to true.

The other option I can think of is to just ignore the filter problem. We keep your current code but I clean it up a bit to reuse more code and improve correctness.

On the other hand I'm wondering if it still a good Idea to add transparency? But I can't think of an other way to have my battery icon without a rectangle "behind" it.

If the goal is limited to drawing a battery icon then drawing the few rectangles of the icon directly to the screen with rg_display_clear_rect (or just manually setting pixels in the aforementioned draw loop) might be a lot simpler and more effective than building a flexible OSD system with transparency. I think it would be a reasonable option and I would accept such PR, because the low battery icon is probably the only OSD that will be needed by users anyway.

But if so, I suggest that we keep this current PR open for when one of us, or someone else, wants to finish the full-fledged OSD :) (or at least transfer your changes to a branch in my repo before you delete them on your side).

rapha-tech · 2025-07-19T21:52:12Z

Hi, sorry for the really late reply! I haven't worked on retro-go for a long time but I'm getting back to it.

Anyway, about the OSD, first thanks for your review but I feel like it would be relatively hard for me to make good clean code for now, I'm relatively new to C programming and I don't want to waste your time so yes I think we should left this PR open for when the full implementation of the OSD will be necessary and someone will want to work on it.

I will create a new PR soon with just the battery icon!

ducalex · 2025-08-14T05:41:27Z

I've been experimenting with on-screen indicators: https://github.com/ducalex/retro-go/commits/on-screen-indicators/

In on_screen_indicators you can select a virtual LED that does what a real LED would do (except it's only updated when the game screen is updated...). Or just have a low battery icon.

With this current code the icon can only be drawn at the bottom (you can experiment, but you'll see there's too much flicker if moved elsewhere).

To have it on top we possibly could call on_screen_indicators from within write_update, right after we've drawn the top 10 lines or something. This will flicker somewhat, but might be tolerable.

Of course the real way of putting it anywhere we want without flicker is compositing the part that intersects with the game screen. I've also experimented with that but the added complexity doesn't seen worth it.

So let me know if you have thoughts about placement and style and blinking and all that!

rapha-tech · 2025-08-31T12:38:02Z

Hey, sorry for the late answer!

First thanks for taking the time to do the implementation ;)

I tested the battery icon and your implementation is great, I also noticed the blinking, but I feel like it's not an issue worth the effort for an icon that is only meant to let people know the device is going to die soon.

I agree that the placement isn't the best since it doesn't correspond to the usual icon but it's a minor detail considering the added blinking when placed correctly.

So I'm happy with the current code!

Edit: if merged, maybe you should let the user choose wether they want this option or not in the settings (some might find it annoying)

ducalex · 2025-08-31T23:01:12Z

I've merged the battery icon on low power.

Best way to test it is to disconnect the battery or in rg_display.c replace rg_system_get_indicator(RG_INDICATOR_POWER_LOW) with true.

It was impossible to find colors that work well on all backgrounds, but making it flash seems to work around that by still drawing some attention. Let me know how you feel about the styling and behavior!

Edit: if merged, maybe you should let the user choose wether they want this option or not in the settings (some might find it annoying)

It only appears at 2% which is usually a few minutes left, so I think it's fair to say that the user would prefer to see it than lose state. But I agree giving control to the user is important and I intend to add a toggle!

#188) As of now there is no way to disable it, but I will add a toggle later, likely in the LED menu (and rename the menu to Indicators or something)..

rapha-tech · 2025-09-01T22:13:24Z

Yes, the blinking really helps it stand out from the game. Personally, I think the icon is great as it is!

rapha-tech added 6 commits February 6, 2025 14:00

add basic OSD

5ed83e7

adding some comments

48b9619

rg_display: update osd init function to use corners

417ab3d

rg_display: osd support transparent background

7a11bde

rg_gui: small tweaks for transparency support

33e814f

rg_display: improved rendering compatibility with the differents form…

2498a89

…ats available

ducalex reviewed Mar 31, 2025

View reviewed changes

ducalex force-pushed the dev branch 4 times, most recently from c72c92e to 3dbe19b Compare June 25, 2025 08:04

rapha-tech force-pushed the osd branch from bbf1d45 to f20527d Compare July 19, 2025 22:02

rg_display: reverse some changes

af50705

rapha-tech force-pushed the osd branch from f20527d to af50705 Compare July 19, 2025 22:09

ducalex force-pushed the dev branch 2 times, most recently from 35ca41d to 832b20d Compare July 27, 2025 01:43

ducalex force-pushed the dev branch from 566e4f9 to 4ef4132 Compare August 24, 2025 08:29

ducalex force-pushed the dev branch from e299c9d to a94c983 Compare September 7, 2025 03:59

ducalex force-pushed the dev branch from 26df565 to a67f5eb Compare September 15, 2025 21:03

ducalex force-pushed the dev branch from 2b5f9ac to c545943 Compare September 15, 2025 23:44

ducalex force-pushed the dev branch from ee326fa to 82a1a78 Compare September 24, 2025 01:04

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Add basic OSD support #188

Add basic OSD support #188

rapha-tech commented Mar 13, 2025

Uh oh!

ducalex commented Mar 17, 2025 •

edited

Loading

Uh oh!

rapha-tech commented Mar 18, 2025 •

edited

Loading

Uh oh!

ducalex Mar 31, 2025

Uh oh!

ducalex Mar 31, 2025

Uh oh!

ducalex Mar 31, 2025

Uh oh!

ducalex Mar 31, 2025

Uh oh!

ducalex commented Mar 31, 2025 •

edited

Loading

Uh oh!

rapha-tech commented Jul 19, 2025

Uh oh!

ducalex commented Aug 14, 2025 •

edited

Loading

Uh oh!

rapha-tech commented Aug 31, 2025 •

edited

Loading

Uh oh!

ducalex commented Aug 31, 2025 •

edited

Loading

Uh oh!

rapha-tech commented Sep 1, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Add basic OSD support #188

Are you sure you want to change the base?

Add basic OSD support #188

Conversation

rapha-tech commented Mar 13, 2025

Uh oh!

ducalex commented Mar 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rapha-tech commented Mar 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ducalex Mar 31, 2025

Choose a reason for hiding this comment

Uh oh!

ducalex Mar 31, 2025

Choose a reason for hiding this comment

Uh oh!

ducalex Mar 31, 2025

Choose a reason for hiding this comment

Uh oh!

ducalex Mar 31, 2025

Choose a reason for hiding this comment

Uh oh!

ducalex commented Mar 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rapha-tech commented Jul 19, 2025

Uh oh!

ducalex commented Aug 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rapha-tech commented Aug 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ducalex commented Aug 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rapha-tech commented Sep 1, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

ducalex commented Mar 17, 2025 •

edited

Loading

rapha-tech commented Mar 18, 2025 •

edited

Loading

ducalex commented Mar 31, 2025 •

edited

Loading

ducalex commented Aug 14, 2025 •

edited

Loading

rapha-tech commented Aug 31, 2025 •

edited

Loading

ducalex commented Aug 31, 2025 •

edited

Loading