rygorous

// float->half variants.
// by Fabian "ryg" Giesen.
//
// I hereby place this code in the public domain, as per the terms of the
// CC0 license:
//
//   https://creativecommons.org/publicdomain/zero/1.0/
//
// float_to_half_full: This is basically the ISPC stdlib code, except
// I preserve the sign of NaNs (any good reason not to?)

jcdickinson

/*-----------------------------------------------------------.   
/                     ColorBlind correction                   /
'-----------------------------------------------------------*/
// Daltonize (source http://www.daltonize.org/search/label/Daltonize)
// Modified to simulate color blindness.
float4 Daltonize( float4 input, float2 tex )
{
	// RGB to LMS matrix conversion
	float3 L = (17.8824f * input.r) + (43.5161f * input.g) + (4.11935f * input.b);
	float3 M = (3.45565f * input.r) + (27.1554f * input.g) + (3.86714f * input.b);

ocornut

// Mini memory editor for Dear ImGui (to embed in your game/tools)
// Animated GIF: https://twitter.com/ocornut/status/894242704317530112

// THE MEMORY EDITOR CODE HAS MOVED TO GIT: 
//   https://github.com/ocornut/imgui_club/tree/master/imgui_memory_editor
// Click "Revisions" on the Gist to see old version.

ocornut

Last updated 2020/03/04

Some links from twitter on the topic of parsing PSD files (haven't looked into them in details). PSD include a flattened rasterized image so this is easy to load if that's the only thing you need. Most software / librairies have support for extracting this flattened data (e.g. stb_image.h does).

However if you want access to individual layers, render non-rasterized layers, emulate every photoshop features, extract or apply effects with more granularity, more code is needed. May range from easy to lots-of-work depending on what exactly you need.

As far as I know there isn't a trivial stb-like ready-to-use C++ library to do that sort of things. Posting all links here. Some are probably bloated or hard to use into your project, some lacking features.

TODO: Actually look into the pros/cons of all those.

dwilliamson

This is my little Christmas-break experiment trying to (among other things) reduce the amount of generated code for containers.

THIS CODE WILL CONTAIN BUGS AND IS ONLY PRESENTED AS AN EXAMPLE.

The C++ STL is still an undesirable library for many reasons I have extolled in the past. But it's also a good library. Demons lie in this here debate and I have no interest in revisiting it right now.

The goals that I have achieved with this approach are:

dougbinks

#pragma once

#include "IconsFontAwesome.h" // from https://github.com/juliettef/IconFontCppHeaders

namespace ImGui
{

    
    inline void SetupImGuiStyle( bool bStyleDark_, float alpha_  )
    {

pervognsen

enum {
    PAGE_SIZE = 4096,
    MINIMUM_RANGE_SIZE = 1024 * PAGE_SIZE
};

void *AllocateRange(uint32_t *size) {
    *size = (*size + PAGE_SIZE - 1) & ~(PAGE_SIZE - 1);
    if (*size < MINIMUM_RANGE_SIZE) {
        *size = MINIMUM_RANGE_SIZE;
    }

pervognsen

// This was mostly done as a fun experiment to see how much I could minimize LUT count and combinational delays.
// Vivado synthesizes this to 17-18 LUTs for the default parameters (32-bit addresses, 8 KB cache, 32-byte cachelines).
// About half those LUTs are for the tag comparator. Note that the LUT count is carefully designed to be independent
// of the cacheline width by avoiding any output muxes (e.g. rather than forwarding the fill response, which would
// create an output mux between the fill response and the cache array, it just repeats the cache lookup). The downside
// of this general kind of design is that it takes 3 cycles to report a hit. You could easily do a design with combinational
// outputs that produces a result in 1 cycle, albeit with very restrictive setup times and combinational output delays.
//
// See if you can reduce the LUT count further! (Yes, it's silly, since the cacheline-to-word shifter is going to dominate.)

pervognsen

// Single process, registered outputs.

// Version 1 uses a blocking assignment to a flip-flop in a clocked block. This goes against almost all
// best-practices guidelines, even among single-process folks, but it's interesting that it directly expresses
// the intention of the design. Not an endorsement, mind you, but I'm definitely finding that with single-process
// registered-output designs, this kind of thing is tempting...

module srl_fifo#(
    parameter                       DATA_WIDTH = 32,
    parameter                       DEPTH = 16

vurtun

/* ===============================================================
 *                              SDEFL
 * ===============================================================
 * public domain - no warranty implied; use at your own risk
 * References:
    https://bitbucket.org/rmitton/tigr/src/be3832bee7fb2f274fe5823e38f8ec7fa94e0ce9/src/tigr_inflate.c?at=default&fileviewer=file-view-default
    https://github.com/github/putty/blob/49fb598b0e78d09d6a2a42679ee0649df482090e/sshzlib.c
    https://www.ietf.org/rfc/rfc1951.txt
*/
#include <stdlib.h>