mmozeiko

#pragma once

#define MEOW_HASH_VERSION 5
#define MEOW_HASH_VERSION_NAME "0.5/calico"

// Meow hash v0.5 with ARMv8 Crypto Extension instructions
// Ported from https://github.com/cmuratori/meow_hash

// Performance on Pine A64 (Cortex-A53, 1.2GHz)
// (compiled with clang v10.0 with -O3 -mcpu=cortex-a53)

mmozeiko

#pragma once

#define MEOW_HASH_VERSION 5
#define MEOW_HASH_VERSION_NAME "0.5/calico"

// Meow hash v0.5 in C without dependency on special CPU instructions
// Ported from https://github.com/cmuratori/meow_hash

// Performance on Ryzen 9 3950X
// AESNI code = ~16 bytes/cycle

meshula

This document has a more accessible location, here:

http://nickporcino.com/posts/last_mile_interchange.html

I'll maintain a copy here too, this is a nice place to support discussion.

Introduction

zeux

Algorithms used for Cone* preprocess the mesh in some way, then split sequentially into 64-triangle clusters:
ConeBase: optimize mesh for transform cache
ConeSort: split mesh into large planar connected clusters, bin clusters into 6 buckets by cardinal axes, optimize each bucket for transform cache
ConeAcmr: optimize mesh for transform cache, split sequentially into variable length clusters that are relatively planar, sort clusters by avg normal
ConeCash: optimize mesh for transform cache, picking triangles that reduce ACMR but prioritizing those that keep current cluster planar
MaskBase: split sequentially into 64-triangle clusters, store a 64-bit conservative triangle mask for 6 frustums (cube faces)
ManyConeN: split sequentially into 64-triangle clusters, store N (up to 4) cones for each cluster and a cone id per triangle (2 bit)

Note that all Cone* solutions get significantly worse results with 128 or 256 triangle clusters; it doesn't matter much for Mask.
The biggest challenge with Cone* algorithms is t

dwilliamson

//
// TinyCRT, revamp and TinyWin support by Don Williamson, 2011
// Based on http://www.codeproject.com/KB/library/tlibc.aspx and LIBCTINY by Matt Pietrek
//

#pragma once


#ifdef USE_DEFAULT_CRT

jdryg

#include <stdint.h>
#include <inttypes.h>
#include <math.h>
#include <malloc.h>
#include <memory.h>
#include <Windows.h>
#include <stdio.h>
#include <xmmintrin.h>
#include <immintrin.h>

AveYo

windows_update_toggle.bat v10.1 final
~ one script to rule them all!
~ block build upgrades and/or automatic updates without breawking Store downloads and Defender protection updates
~ there is a lot of focus on Defender updates working independently, unlike any other updates "management" solution
~ ifeo safe blocking with no destructive changes of ownership, deleting files, removing tasks, or over-blocking
~ toggle everything from the Desktop right-click context menu!
but wait, there is more:
~ hide/unhide/install update lists with counter at the Desktop right-click context menu!

Previous update toggle batch suite scripts have been overwritten on pastebin, but will still be available here:

vurtun

pervognsen

#!/bin/bash
#
# This is a sketch of an experimental design for a build system where project definitions are written in C.
# The build system is packaged as a single shell script which contains the C library code as a heredoc string.
# The shell script creates a concatenation from the library code and the file specified as the first command line argument.
# Then that is compiled and the result is run, which takes any required build-related actions; for this toy implementation,
# the only build action is running the C compiler directly, but it could also generate makefiles or VS solutions like premake.
#
# Note that using some tricks you can write a single file that is both a valid Unix shell script and Windows batch file,
# which combined with cross-platform code for the C library would allow a portable single-file build system solution.

vurtun

Graphical User Interfaces

For the last few weeks I spend some time coding, writing and cleaning up my notes from almost a year since I published nuklear.

Basically this is a possible implementation for a graphical user interface builder backend with support for an immediate mode style API. So it provides a way to define non-mutating UI state, an immediate mode style API for dynamic UI components (lists,trees,...) and a combination of both.

The core implementation is ~800 LOC without any kind of default widgets or extensions. At first this seems quite counter intuitive. However since the inherent design allows for lots of different ways to define any widget like buttons it does not make sense to provide a specific default implementation. The way this code was architectured furthermore removes the need for style/skinning configurations used in Nuklear since widget painting is just calling a small