chart appears overly enlarged in Overview

[sleeptightAnsiC]

Demo > Overview > Chart, one of the charts appears overly enlarged. It draws as far upwards as possible.

This does NOT reproduce under demo/sdl3_renderer for some reason, but every other backend that I tested seems affected.

This must be regression. I'm fairly sure it worked few weeks ago. I haven't git bisect'ed yet.

[sleeptightAnsiC]

/tmp/Nuklear/demo/sdl_renderer $ git bisect bad
07941526ccb9d4197f00ea92967ca68cfb1fc36e is the first bad commit
commit 07941526ccb9d4197f00ea92967ca68cfb1fc36e (HEAD)
Author: Rob Loach <robloach@gmail.com>
Date:   Sun Apr 19 23:14:29 2026 -0400

    demo: Use Nuklear math functions for examples

 demo/common/overview.c | 36 ++++++++++++++++++------------------
 example/extended.c     |  8 ++++----
 example/skinning.c     |  6 +++---
 3 files changed, 25 insertions(+), 25 deletions(-)

[sleeptightAnsiC]

@RobLoach This seems to be caused by your change from #942

I'm scratching my head unable to tell what's going on. My blind guess is that Nuklear's math primitives have way too low precision and cause float to go inf/nan. Might be a bug in some of those primitives. Hard to tell.

I will take a look into this later, but maybe it's wiser to simply revert that commit? AFAIK, every demo/example already depends on libC and every Makefile uses -lm, so I'm not sure what is the benefit of replacing libm symbols?

[RobLoach]

That's huge! Good find. Something is definitely up with those math functions. Does it happen when linking -lm for math.h?

You don't happen to know a better sin/cos do you?

[TomJGooding]

Is the column chart meant to work on the value range 0...2PI? A possible fix might be simply this?

diff --git a/demo/common/overview.c b/demo/common/overview.c
index 5fca8d3..fbd59d2 100644
--- a/demo/common/overview.c
+++ b/demo/common/overview.c
@@ -687,8 +687,6 @@ overview(struct nk_context *ctx)
             int index = -1;
 
             /* line chart */
-            id = 0;
-            index = -1;
             nk_layout_row_dynamic(ctx, 15, 1);
             nk_checkbox_label(ctx, "Show markers", &show_markers);
             nk_layout_row_dynamic(ctx, 100, 1);
@@ -713,6 +711,8 @@ overview(struct nk_context *ctx)
             }
 
             /* column chart */
+            id = 0;
+            index = -1;
             nk_layout_row_dynamic(ctx, 100, 1);
             if (nk_chart_begin(ctx, NK_CHART_COLUMN, 32, 0.0f, 1.0f)) {
                 for (i = 0; i < 32; ++i) {

[sleeptightAnsiC]

Is the column chart meant to work on the value range 0...2PI? A possible fix might be simply this?

It makes sense there, in this one specific place, but AFAIK standard sin/cos are supposed to handle such cases.

I'm afraid that Chart is just a very first obvious place I was able to find. A lot of code in Overview probably assumed values higher than 2PI

[TomJGooding]

Fair enough. It just looked like all the other charts in overview.c were 0...2PI which are the only places that consine/sine are used. It looks like just a similar chart in skinning.c, and from a quick look at extended.c that's working with circles which presumably should be fine?

[TomJGooding]

From nuklear_math.c:

///  Sine/Cosine
///  -----------
///  All constants inside both function are generated Remez's minimax
///  approximations for value range 0...2*PI. The reason why I decided to
///  approximate exactly that range is that nuklear only needs sine and
///  cosine to generate circles which only requires that exact range.

[sleeptightAnsiC]

Another place where it breaks: demo/common/overview.c#L862-L871

I wrote this snippet with standard sin/cos, but I wasn't the one who got it merged. It got resubmitted and patched with NK_SIN/NK_COS - here

My old version with standard primitives worked fine. The new one runs away :D

2026-05-15_15-37-34.mp4

[sleeptightAnsiC]

presumably should be fine?

What I'm trying to say is: Nuklear's math functions were never meant to be reused/exported outside of library. It should never happen in the first place.

These are tailored for internal usage only, and the definitions are kept private in src/nuklear_internal.h. It's a coincidence the demo can even compile tbh

We can try fixing it one-by-one but I don't think we should. New code may break it again later. If it went unnoticed during #942 and #911, it's about to happen again.

[sleeptightAnsiC]

@RobLoach

I hoped we would discuss this first before moving forward, but since Tom already started something at #960, I'm just gonna quickly reply here:

Does it happen when linking -lm for math.h?

No. It works fine when symbols come from standard libm (see previous comments)

You don't happen to know a better sin/cos do you?

I'm not aware of any. Sorry :(

Most of the implementations I've seen either: use bunch of hacks, use inline assembly, or are incompatible with Public Domain.

I will try to look for some alternatives in the future, but I would suggest to not mess with those symbols for now. Trying to reuse nuklear_math.c for general purpose math is hard without breaking something in the process.

[TomJGooding]

I hoped we would discuss this first before moving forward, but since Tom already started something at #960, I'm just gonna quickly reply here:

Sorry I didn't mean to jump the gun (again) - I took your comments as definitive (since the examples are clearly broken). I wanted to contribute and save you the trouble after your work tacking the X11 image stuff!