Been sitting on this for a while as i couldn't decide on what sprite sheet to bundle with it, but here goes . . .

Minimal D3D11 sprite renderer NEO:
Ultra-compact sprite rendering code with example frame animation logic
This release contains tech bits from the upcoming SuperNeo™ 2D game engine and includes rotation, anchor/pivot point, color filtering, alpha blending and built-in antialiased point sampling. As usual: complete, runnable single-function app. ~150 LOC. No modern C++, OOP or (other) obscuring cruft.

proof-of-concept prototype of bheader: a zero-dependency c/c++ framework distribution format where the "engine" is embedded in a regular source file as a pre-compiled binary payload (in the form of a byte array). https://gist.github.com/d7samurai/a7ffc8090cf4b38b934b0fd7dd2df86f (rough first draft of a somewhat explanatory gist around the source code from years ago). zip file containing a complete coding environment here: https://discord.com/channels/239737791225790464/436306224930226187/1138929719501402232

as i was putting together the sprite renderer demo above, i updated my little texture conversion utility texprep to version 1.1.5 1.1.6. this release brings a new output format flag, -txt, which will save the converted image to a text file with the pixel data encoded as an argb 32-bit int array[] (a quick and easy way to get textures into projects during prototyping & testing, without having to implement file loading and image decoding), like this: https://gist.github.com/d7samurai/8f91f0343c411286373161202c199b5c#file-xtra-h

texprep 1.1.6 can be downloaded from https://gist.github.com/d7samurai/9f17966ba6130a75d1bfb0f1894ed377#texprep

minimal d3d11 sprite renderer: basic sprite rendering reference code with example sprite sheet animation logic. as usual: complete, runnable single-function app. no modern c++ / oop / obscuring cruft https://cdn.discordapp.com/attachments/942527065780027392/1070073913398272030/adventurer.gif https://gist.github.com/d7samurai/8f91f0343c411286373161202c199b5c

lightweight float_to_string routine https://gist.github.com/d7samurai/c3e85e08f2a32d2fb3bc9d157c066be9 (now including its evil twin, string_to_float)
admit it, 100% of the time it's all you need 99% of the time!

visual rubberducking https://cdn.discordapp.com/attachments/942527065780027392/1062805914433896569/image.png

https://discord.com/channels/239737791225790464/436306224930226187/1058096919127281766
earlier today @hikari asked about a tool for converting images to premultiplied alpha and it made me think that i occasionally wish i had something simple for that, too, so i made a little commandline utility..

texprep | d7samurai 2022
converts most common image formats to 32 bit png, bmp or bin (raw bgra bytes), optionally with premultiplied alpha

usage: texprep.exe [-png|bmp|bin] [-pma|pm0] <filename>

crude demonstration of using shadow mapping techniques for rainfall occlusion https://youtu.be/x47CUqgnVCw?t=66 https://youtu.be/2Vd8avL7sOQ

as alluded to earlier, here's a properly minimal d3d11 implementation (note: video is zoomed in to combat downsampling/compression artifacts and make antialiasing effect more apparent) https://gist.github.com/d7samurai/9f17966ba6130a75d1bfb0f1894ed377

after revisiting the subject in the context of recent d3d11 2d example implementations i went back and cleaned up the original shadertoy a bit: https://www.shadertoy.com/view/MlB3D3 slight caveat: this simplification only works as long as fract(pixel) stays positive (which it might not, given that fract is calculated as x - floor(x)), but for typical sprite rendering it shouldn't be an issue

a quick-and-dirty shadertoy example doing smooth subpixel aa parallax scrolling for pixel art ("fat pixel" aesthetics) https://www.shadertoy.com/view/ds2XWy https://youtu.be/pBLZFEh1Suw

fired up the old slow-ass brute force motion blur renderer from 4-5 years ago on the new laptop.. starting to approach realtime now (from hardware getting faster, that is. i haven't touched the code yet). getting hopeful that some optimization can actually make this usable in-game https://youtu.be/dZBX-VHFqIM

a little side exercise to see how little code one can get away with to put that rgb triangle on screen in d3d11 (without bending over backwards with trickery). this is a complete app in less than 50 loc (including #pragmas, #includes and hlsl code): https://gist.github.com/d7samurai/1e9a1f1a366740f7d8a3a20397fcfa6b

old experiments in string concatenation https://gist.github.com/d7samurai/1d778693ba33bbd2b9d709b209cc0aba

void main()
{
    char* name = "slim shady";
    int   line = 1337;
    float temp = 98.567f;

    // attention, slim shady! there's an error in line 1337 : the error code is 666 and the temperature is 98.6 degrees
    OutputDebugString(concat("attention, ")(name)("! there's an error in line ")(line)(" : the error code is ")(666)(" and the temperature is ")(temp, 1)(" degrees\n"));
}

minimal d3d11 pt3 https://twitter.com/d7samurai/status/1584005864188366849
an elaboration on minimal d3d11 pt2, adding shadowmapping and incorporating various improvements and alternative approaches to the rendering setup, such as manual vertex fetching, samplerless texture lookup, null shader depth map rendering and procedurally generated texture and instance data. as before, this is meant to be an "api familiarizer" series - an uncluttered direct3d 11 setup & basic rendering primer for reference, in the form of a complete, runnable windows application contained in a single function and laid out in a linear, step-by-step fashion. no modern c++ / oop / obscuring cruft. and even with the added overhead of the shadowmapping, this is the most compact incarnation so far, clocking in at < 190 loc (+ about 66 for the hlsl).. being able to ditch vertex & instance buffers, input layout, texture, sampler etc helps

Minimal D3D11 pt3, added shadowmapping + including a number of "tricks" and alternative techniques to shake things up a bit. source out soon. ~180 loc (+70 loc hlsl) https://youtu.be/Oj_umRjZ7NU

it always annoyed me that there's no built-in mechanism for automatic build versioning in visual studio, so here's my little "build number incrementor". usage:

buildno++.exe <filename>

i have it set up to run as a pre-build event in vs. a text file (called buildno.debug in the screenshot) contains a single #define:

#define BUILDNO 0

and every time the buildno++.exe runs it increments that number in the file, whatever it happens to be. you then #include that file and can use the BUILDNO macro to access the updated, current build number in your code. this is how i use it:

#ifdef DEBUG
#include "buildno.debug"
#define BUILD "debug build " STR(BUILDNO)
#else
#include "buildno.release"
#define BUILD "build " STR(BUILDNO)
#endif

note: the original filename is actually buildno++.exe but the ++ part seems to have been stripped by discord. so rename accordingly.

as an apropos to the gui framework discussion earlier; a little peek at a selection of widgets in my own lightweight gui system (wip, been in stasis for the last 2-3 years, as all my other projects. hope to pick them all up again this year) https://i.imgur.com/BDpqVNf.png screenshot attached to show actual ui crispness, to balance out the muddy video compression..

i guess such small code samples are rarely sent here hold my beer.. (i always liked this piece of code, although it never seemed to appeal much to anyone else whenever it was brought up. maybe it's because i actually needed it for a project: storing argb color in various compact forms, either as uint32 or packed into an __m128i, where i had to multply alpha values from nested containers and it was beneficial to do it in-place, as bytes, without extracting to float and repacking etc..) https://gist.github.com/d7samurai/f98cb2aa30a6d73e62a65a376d24c6da

nothing new, really, but better quality (i now upscale to 4k, as youtube seems to respect that more.. so it has less compression artifacts and shows off the fidelity better).. also this version has the slight line shimmering enabled, as well as a more visible faux monitor reflection (if the movements look awkward it's because the prototype runs slower than realtime when recording frames to disk - while capturing video from the webcam.. so when played back, the video effectively plays faster. it's real-time during gameplay) https://youtu.be/Nptlhm7OYfE