graphitemaster

Working around offsetof limitations in C++:

There is sometimes a situation in which one needs to get the relative offset of a structure field, common examples of this include serialization frameworks which aid to serialize objects, vertex attributes for rendering (D3D, GL.), etc.

The most common technique for getting this information is through the offsetof macro defined in stddef.h. Unfortunately using the macro in C++ comes with a new set of restrictions that prevent some (subjectively valid) uses of it.

bkaradzic

Orthodox C++

What is Orthodox C++?

Orthodox C++ (sometimes referred as C+) is minimal subset of C++ that improves C, but avoids all unnecessary things from so called Modern C++. It's exactly opposite of what Modern C++ suppose to be.

Why not Modern C++?

zeux

// This file is designed to be included in D3D9-dependent code instead of d3d9.h, while adding minimal amount of junk
#pragma once
 
#include <BaseTyps.h>
#include <BaseTsd.h>
 
// stdlib.h
#ifndef _INC_STDLIB
#define _INC_STDLIB
#endif

Fraktality

local LerpCIELUV do

	-- Combines two colors in CIELUV space.
	-- function<function<Color3 result>(float t)>(Color3 fromColor, Color3 toColor)

	-- https://www.w3.org/Graphics/Color/srgb
	
	local clamp = math.clamp
	local C3 = Color3.new
	local black = C3(0, 0, 0)

bkaradzic

Notes on header files

After over 20 years working with C/C++ I finally got clear idea how header files need to be organized. Most of the projects in C++ world simply dump everything in .h file, and most of my C++ code was organized this way. Lately I started to separate function declaration from implementation as it was done in C. Now .h headers are exclusevely intended for function and class declaration with doxygen documentation style comments. Inline implementation of functions, class method implementation, etc. goes into .inl headers or .cpp files.

For example .h file would contain only declaration and doxygen style documentation comment:

	/// Convert size in bytes to human readable string.
	void prettify(char* _out, int32_t _max, uint64_t _value)

zeux

// g++ -O3 -o uniquevalues uniquevalues.cpp  -std=c++11 -Wall -Wextra -DNDEBUG
// results for N = 10000000:
// distinct_count_stdhash(values,N)  :  1340.096 cycles per operation (best) 1340.096 cycles per operation (avg)
// distinct_count_goodhash(values,N) :  137.917 cycles per operation (best)   137.917 cycles per operation (avg)
// distinct_count_sort(values,N)     :  258.619 cycles per operation (best)   258.619 cycles per operation (avg)

#include <iostream>
#include <algorithm>
#include <unordered_set>
#include <vector>

vurtun

sebbbi

Setup:
1. Index buffer containing N quads (each 2 triangles), where N is the max amount of spheres. Repeating pattern of {0,1,2,1,3,2} + K*4.
2. No vertex buffer.

Render N*2 triangles, where N is the number of spheres you have.

Vertex shader:
1. Sphere index = N/4 (N = SV_VertexId)
2. Quad coord: Q = float2(N%2, (N%4)/2) * 2.0 - 1.0
3. Transform sphere center -> pos

vurtun

Gilbert–Johnson–Keerthi (GJK) 3D distance algorithm

The Gilbert–Johnson–Keerthi (GJK) distance algorithm is a method of determining the minimum distance between two convex sets. The algorithm's stability, speed which operates in near-constant time, and small storage footprint make it popular for realtime collision detection.

Unlike many other distance algorithms, it has no requirments on geometry data to be stored in any specific format, but instead relies solely on a support function to iteratively generate closer simplices to the correct answer using the Minkowski sum (CSO) of two convex shapes.

rygorous

why doesn't radfft support AVX on PC?

So there's two separate issues here: using instructions added in AVX and using 256-bit wide vectors. The former turns out to be much easier than the latter for our use case.

Problem number 1 was that you positively need to put AVX code in a separate file with different compiler settings (/arch:AVX for VC++, -mavx for GCC/Clang) that make all SSE code emitted also use VEX encoding, and at the time radfft was written there was no way in CDep to set compiler flags for just one file, just for the overall build.

[There's the GCC "target" annotations on individual funcs, which in principle fix this, but I ran into nasty problems with this for several compiler versions, and VC++ has no equivalent, so we're not currently using that and just sticking with different compilation units.]

The other issue is to do with CPU power management.