Replies: 4 comments 4 replies
-
Perhaps to avoid some of the duplicate definition problems, we have a similar approach that was done with void rl_imagedrawpixel(void* data, int format, int width, int height,
int posX, int posY,
unsigned char colorR,
unsigned char colorG,
unsigned char colorB,
unsigned char colorA);
void ImageDrawPixel(Image* dst, int posX, int posY, Color color) {
rl_imagedrawpixel(dst->data, dst->format, dst->width, dst->height,
posX, posY,
color.r, color.g, color.b, color.a);
} Avoiding the structs could make the function definitions extremely long in the library, but the benefit of not having to deal with the duplicate structs could be worth it. |
Beta Was this translation helpful? Give feedback.
-
I'm not sure I'd call it a software rendering module. I'd call it Image Drawing, Software rendering makes it sound like it's a full blown 3d renderer on par with OpenGL, and it is not. |
Beta Was this translation helpful? Give feedback.
-
I think this idea is great. Drawing stuff on the screen is a bit complicated in libretro without this, but very familiar & easy with it. |
Beta Was this translation helpful? Give feedback.
-
@RobLoach Definitely I want to do something on that line for a 2d-software-rendered or image-drawing functionality but I'm still thinking the best approach for it. My first idea was just keeping Moving the image functionality to a separate I need to think about the best solution but definetly I want to allow it; I've got a side project to run raylib on RP2040 microcontroller (no-GPU, 264KB RAM) and I need the 2d-software-rendering option. |
Beta Was this translation helpful? Give feedback.
-
Been wanting to use raylib's Image API outside of raylib. One use case is in a libretro core that would allow using parts of raylib on devices that Lakka supports. This would allow compiling once, and rendering in multiple different frontends that use libretro, like RetroArch.
Proof of Concept
I forked raylib's rtextures.c to its own single-header library over at rimage. Following that, I created libretro-rimage, which allows you to use the Image API in a libretro core. Using the framebuffer and raylib's Image API makes it so much easier to render things to the screen.
This fork is a big hack, and I would like a cleaner design around it so that a full fork isn't needed.
Proposed Solution
I would love to move the Image API that's done in
rtextures.c
into its own single-header library, similar to what was done withrl_gputex.h
. This would allow using raylib's Image API outside of raylib, without requiring a complete fork.Challenges
There are a few problems that we can run into when taking this approach....
Would love all of your thoughts. Introducing more modularity to raylib is great, but I don't want to over-complicate the code base.
Beta Was this translation helpful? Give feedback.
All reactions