Fbgl version 0.1.0 Initial Release

[lvntky]

At this point fbgl is mature enough to create simple games on framebuffer.

Supproted Functionalities:

• Keyboard management
• Texture rendering
• Builtin fps counter
• Text rendering
• basic shapes

Upcoming features:
in the next minor version update mostly we are going to focus on performance optimizations.

Happy hacking!

What's Changed

• Fixed example code in README.md by @dario-loi in Fixed example code in README.md #5
• [FIX] Move all implementation under include guard by @dario-loi in [FIX] Move all implementation under include guard #6
• Bugfixes by @dario-loi in Bugfixes #8
• [FEATURE] Filled and Outlined Circle by @dario-loi in [FEATURE] Filled and Outlined Circle #9
• Code quality and warning removal by @dario-loi in Code quality and warning removal #12

New Contributors

• @dario-loi made their first contribution in Fixed example code in README.md #5

Full Changelog: https://github.com/lvntky/fbgl/commits/v0.1.0

---

This discussion was created from the release Fbgl version 0.1.0 Initial Release.

[dario-loi]

Any practical suggestions on where we could achieve performance gains?

Usage of memset in functions or simd intrinsics to write to the buffer seems to be the only way to provide some utility to the users, any resources that tell how to batch pixels together in a generalized way?

[lvntky]

https://rxi.github.io/cached_software_rendering.html

i think this would be a great resource, i didnt read the entire thing but looks good, also even if i dont like to, we can advice users to work with texture atlases instead of single textures, so this way we can render the entire scene with very few cpu clocks (hopefully)

[dario-loi]

Yeah I ran into this too and it seems ok. It might be a great optimization for GUI-like applications, however, it might be redundant for game-like workloads (where each pixel is redrawn at each frame always) so we'd need to decide what the library is going to be focused on(?)