Hey All, I made a header only C++ library where it's 1 line of code to init, then you can start writing to pixels on the screen.

[thisarray@mastodon.gamedev.place]

@demofox This is so cool. Well done!

[ashalah@mastodon.gamedev.place]

@demofox excellent! Very reminiscent of the minifb Rust crate by @daniel_collin

[ruenahcmohr@infosec.exchange]

@demofox mmm windows, I wonder, what about a linux framebuffer version.. hmmm...

[demofox@mastodon.gamedev.place]

@RueNahcMohr @lisyarus is thinking about making a Linux friendly backend!

[sol_hsa@mastodon.gamedev.place]

@demofox I find it a bit funny that like myself, everybody else seems to have checked the platform compatibility first

[root42@chaos.social]

@demofox now we need this with a Vulkan and Metal backend.

[root42@chaos.social]

@sol_hsa you can’t post a Windows only solution to the demoscene without people starting to port it all over the place. Fingers crossed!

[sol_hsa@mastodon.gamedev.place]

@root42 SDL backend ought to be pretty easy to make. Would defeat the purpose though, but at least would make things portable

I love the concept. Keeping it simple will be a struggle, though.

[kojack@mastodon.gamedev.place]

@bnut @demofox Good old PixelToaster. I used to use its predecessor PTC (Prometheus Truecolor) too. My university final project ray tracer used it for the rendering display.

[jalict@mastodon.gamedev.place]

@demofox Years since I saw Three.js, but so cool to see them grow up to be Thirteen.h

[lunaticdancer@mastodon.gamedev.place]

@demofox oh this is marvelous, great work!

How's the performance overhead? I imagine it's not too bad since this seems to mostly be a fancy data serialization wrapper for DX12 so probably the heaviest part of this is the user iterating over the pixel array (I'm pretty new to graphics programming myself so I might be off-base here).
Also any plans to port the library to C?

[demofox@mastodon.gamedev.place]

@LunaticDancer its real fast, no overhead in the library.
The pixel values persist across frames, so you could do "dirty rectangles" instead of updating every pixels every frame. If you knew which pixels were updated each frame, you could copy just those regions.
The examples run like pixel shaders as well and iterate overall pixels, but you could blit rectangles instead.
But its real fast. These demos are like 0.3ms per frame on my machine in release.

[lunaticdancer@mastodon.gamedev.place]

@demofox okay yeah, that is one sexy frame budget. I guess it's really on library's user not to squander the performance lol

[termoose@snabelen.no]

@demofox ohhhh love this, was just looking for something similar and found good old tinyptc dead in the water. This looks great!

[sonnybonds@mastodon.gamedev.place]

@demofox Looks great, love the name.

I was going to say wouldn't this make sense to have as just a single .h _and_ a single .cpp, but I guess a huge use case is just getting up and running very quickly and then you might not have a build system anyway.

[fell@ma.fellr.net]

@demofox It's super cool, but appears to be Windows-only. If anyone knows an alternative that works on Linux let me know.

[radgerayden@mstdn.social]

@sol_hsa @root42 where it matters it's easy to get SDL installed or you already have it, and the library can dlopen it if you want to keep it at exactly zero compiler flags needed. Probably not worth it but keeping it pure is possible!

[sol_hsa@mastodon.gamedev.place]

@radgeRayden @root42 Not a problem for someone who can use SDL, but a problem for a newbie using it to learn things.

[oblomov@sociale.network]

@demofox thank you very much.

[kafumanto@mastodon.gamedev.place]

@demofox Kudos! Wonderful idea. And great API