Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hagl_put_char / hagl_put_text always drawn on black background #42

Open
ivmarkov opened this issue May 17, 2021 · 4 comments
Open

hagl_put_char / hagl_put_text always drawn on black background #42

ivmarkov opened this issue May 17, 2021 · 4 comments

Comments

@ivmarkov
Copy link

ivmarkov commented May 17, 2021

Offending line:
https://github.com/tuupola/hagl/blob/master/src/hagl.c#L364

The easiest fix would be for hagl_put_text / hagl_put_char to take a second color parameter which would represent the "background" color in the rasterized bitmap.

A completely different approach would be for HAGL to be reworked to have a notion of "state", which would include the current foreground color (used by draw* and text functions), current background color (used by fill* and text functions) and current font (used by text functions).

But that might be too big of a change.

@tuupola
Copy link
Owner

tuupola commented May 17, 2021

Yeah it is a known issue atm and also related to #39. I have not decided yet which way go. One option would be what you described:

hagl_set_color(rand() % 0xffff);
hagl_set_background(0x0000);

hagl_put_char(code, x0, y0);

Another way is to pass around style objects.

font_style_t style;

style.font = font8x8;
style.scale = 2;
style.color = rand() % 0xffff;
style.background = 0x0000;

hagl_put_char(code, x0, y0, style);

I am currently leaning towards style objects since it offers the easiest way to expand while still maintaining bc.

@ivmarkov
Copy link
Author

Which way you would like to go is I guess also related to #43. I like the simplicity and the "pure "C"" approach of the library, yet I'm finding the current API a bit lacking in terms of abstractions, even if considering that the C language is used. Even in embedded space, I would find valuable the option to abstract the rendering operations over the concrete drawing surface. Here's one more example: why can't I load the jpeg image in an offscreen surface and then scale-blit it wherever I want on the actual screen? Or even fuse the loading and blitting process together and this way visualize the whole or portions of the image in a smaller part of the screen?

So I guess if you would like to mostly keep the current API, your styled font approach is the way to go. If you are introducing an abstraction over drawing surfaces, you might just as well introduce a 'context' abstraction too and that would then be your first approach from above.

@tuupola
Copy link
Owner

tuupola commented May 21, 2022

The reason has been mostly my skills. This started as my project to learn the C language. That said I just tagged current version as 0.5.0 so I can break BC going to 0.6.0. I also have been sketching how the API would look when introducing surfaces. I like it a lot so far. Something like:

backend_t backend = hagl_hal_init();
surface_t display = hagl_init(backend);

while (1) {
    hagl_clear(display);
    hagl_load_image(display, 0, 0, "/sdcard/hello.jpg");
    hagl_flush(backend);
};

hagl_close(backend);
backend_t backend = hagl_hal_init();
surface_t display = hagl_init(backend);

int16_t x0 = rand() % display->width;
int16_t y0 = rand() % display->height;

color_t pixel = hagl_get_pixel(display, x0, y0);

@oclyke
Copy link

oclyke commented Oct 9, 2022

@tuupola I would be interested in helping with the addition of this feature. Please let us know how we can best assist. IN the meantime I will get started on a PR to best describe my own approach.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants