Open OBenjaminT opened 2 years ago
indeed, this is a bug--good eyes! the question is whether it's a bug in documentation or code. anyone who's been relying on the number of pixels being returned has been broken, and it's possible someone was (probably mistakenly) relying on the 0 return...
i think most everything else blittish returns the pixel count, so that's probably the way to go.
Yea, I'm creating a zig wrapper and was checking if I could safely cast to u32
/u64
and suddenly realised I could just cast to bool
... (I'm actually spending a lot of time trying to see if I can make the types in the wrapper tighter than the c types and exploring the code to double check if I'm not limiting myself. Which includes trying to find out what could cause errors and describing them better than return -1
).
I don't know what you mean by "blittish" but ncblit_rgb_packed
, ncblit_rgb_loose
, and ncblit_bgrx
all return either -1 or the result of ncblit_rgba
(the buggy one). Their doc comments refer you to ncblit_rgba
's so I assume they're faulty by association?
Yea, I'm creating a zig wrapper and was checking if I could safely cast to
u32
/u64
and suddenly realised I could just cast tobool
... (I'm actually spending a lot of time trying to see if I can make the types in the wrapper tighter than the c types and exploring the code to double check if I'm not limiting myself).
sweet. do know that someone else has already worked on this:
| Zig | Jakub Dundalek | dundalek/notcurses-zig-example |
I don't know what you mean by "blittish" but
ncblit_rgb_packed
,ncblit_rgb_loose
, andncblit_bgrx
all return either -1 or the result ofncblit_rgba
(the buggy one). Their doc comments refer you toncblit_rgba
's so I assume they're faulty by association?
yep, i'll fix this there and the correct behavior will propagate out.
In
USAGE.md
andimport/notcurses.h
the comment claims that the number of pixels that are blitted are returned:(emphasis mine)
Yet the source only returns
-1
or0
?