Graphics implementation that writes to a pixel buffer

[marshallpierce]

I needed this for getting turtle.rs running in the browser via webassembly, so I wrote up a partial implementation here: https://github.com/sunjay/turtle/pull/53/files#diff-1f72391b08b32f9b933c3e078f485e4d. It only does plain colors (not textures) because that's all Turtle needed.

Is this of interest? Maybe to #1070?

[bvssvni]

Yes, a software rasterizer backend is interesting.

[marshallpierce]

OK. What would be a good way to contribute this? Are there conventions around testing, etc, that I should know about?

[bvssvni]

Can you separate it as a library?

[marshallpierce]

It will be simple to pull out; it's just a single struct really, so that's no problem. Should I just PR that struct more or less as-is, or are there tests you'd like me to build as part of it?

[ischeinkman]

Any update on this? This would be really helpful for the Nintendo Homebrew community.

If not I can try making this myself, but if a crate already exists it would probably be easier to port than starting from scratch.

[marshallpierce]

I haven't had time to touch it, but you could probably just hoist the implementation as-is out of that PR linked above and at least use it as a starting point.

[ischeinkman]

I have an implementation working at https://github.com/ischeinkman/framebuffer_graphics . It's basically just the code from the PR rearranged into multiple files and with some slight cleanups. It still doesn't have any texture support yet, but at the moment I am not sure what a texture would even mean in the context of a framebuffer; just a raw block of memory that acts as a sub-framebuffer for pasting into the true framebuffer?