Andrey Penechko MrSmith33

ELF Format Cheatsheet

Introduction

Executable and Linkable Format (ELF), is the default binary format on Linux-based systems.

Compilation

CUSTOM GAME ENGINES: A Small Study

A couple of weeks ago I played (and finished) A Plague Tale, a game by Asobo Studio. I was really captivated by the game, not only by the beautiful graphics but also by the story and the locations in the game. I decided to investigate a bit about the game tech and I was surprised to see it was developed with a custom engine by a relatively small studio. I know there are some companies using custom engines but it's very difficult to find a detailed market study with that kind of information curated and updated. So this article.

Nowadays lots of companies choose engines like Unreal or Unity for their games (or that's what lot of people think) because d

Volumetric Clouds Resources List

A. Schneider, "Real-Time Volumetric Cloudscapes," in GPU Pro 7: Advanced Rendering Techniques, 2016, pp. 97-127. (Follow up presentations here, and here.)
S. Hillaire, "Physically Based Sky, Atmosphere and Cloud Rendering in Frostbite" in Physically Based Shading in Theory and Practice course, SIGGRAPH 2016. [video] [course notes] [scatter integral shadertoy]
[R. Högfeldt, "Convincing Cloud Rendering – An Implementation of Real-Time Dynamic Volumetric Clouds in Frostbite"](https://odr.chalmers.se/hand

Porting Druntime to WebAssembly

WebAssembly

WebAssembly is born out of asm.js, which was a backend for llvm that compiles C/C++ to JavaScript. As a consequence WebAssembly has many of its features in line with C, and consequently with D as well.

The MVP version of WebAssembly is widely supported across browsers. Work continues to implement additional features, see the proposal tracking page.

Approach

Foreward

This document was originally written several years ago. At the time I was working as an execution core verification engineer at Arm. The following points are coloured heavily by working in and around the execution cores of various processors. Apply a pinch of salt; points contain varying degrees of opinion.

It is still my opinion that RISC-V could be much better designed; though I will also say that if I was building a 32 or 64-bit CPU today I'd likely implement the architecture to benefit from the existing tooling.

Mostly based upon the RISC-V ISA spec v2.0. Some updates have been made for v2.2

Original Foreword: Some Opinion

The RISC-V ISA has pursued minimalism to a fault. There is a large emphasis on minimizing instruction count, normalizing encoding, etc. This pursuit of minimalism has resulted in false orthogonalities (such as reusing the same instruction for branches, calls and returns) and a requirement for superfluous instructions which impacts code density both in terms of size and

	// Length-segregated string tables for length < 16. You use a separate overflow table for length >= 16.
	// By segregating like this you can pack the string data in the table itself tightly without any padding. The datapath
	// is uniform and efficient for all lengths < 16 by using unaligned 16-byte SIMD loads/compares and masking off the length prefix.

	// One of the benefits of packing string data tightly for each length table is that you can afford to reduce the load factor
	// on shorter length tables without hurting space utilization too much. This can push hole-in-one rates into the 95% range without
	// too much of a negative impact on cache utilization.

	// Since get() takes a vector register as an argument with the key, you want to shape the upstream code so the string to be queried
	// is naturally in a vector. For example, in an optimized identifier lexer you should already have a SIMD fast path for length < 16

	// x64 encoding

	enum Reg {
	RAX, RCX, RDX, RBX, RSP, RBP, RSI, RDI,
	R8, R9, R10, R11, R12, R13, R14, R15,
	};

	enum XmmReg {
	XMM0, XMM1, XMM2, XMM3, XMM4, XMM5, XMM6, XMM7,
	XMM8, XMM9, XMM10, XMM11, XMM12, XMM13, XMM14, XMM15,

	module widget.attempt5.curved;
	import widget.attempt5.model;

	void drawCurvedBorder(DrawContext)(ref DrawContext context) {
	if (!context.model.dropShadow.isNull)
	dropShadow!DrawContext(context);

	// four buffers that store the current locations for each horizontal side (to be built upon)

	// lets setup the initial indexes into the first of buffers with respective to horizontal side

	using System.Collections;
	using System.Collections.Generic;
	using UnityEngine;
	using System.IO;

	[System.Serializable]
	public class MagicaVoxelModel_PACK : MagicaVoxelChunk
	{
	public int numModels; // num of SIZE and SYZI chunks

	// Code ported from https://0fps.net/2012/06/30/meshing-in-a-minecraft-game/

	// Note this implementation does not support different block types or block normals
	// The original author describes how to do this here: https://0fps.net/2012/07/07/meshing-minecraft-part-2/



	const int CHUNK_SIZE = 32;

	// These variables store the location of the chunk in the world, e.g. (0,0,0), (32,0,0), (64,0,0)