A traditional table-based DFA implementation looks like this:
uint8_t table[NUM_STATES][256]
uint8_t run(const uint8_t *start, const uint8_t *end, uint8_t state) {
for (const uint8_t *s = start; s != end; s++)
state = table[state][*s];
return state;
}
| // 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 |
WARNING: Article moved to separate repo to allow users contributions: https://github.com/raysan5/custom_game_engines
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](https:
| // 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, |
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
| 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 |
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.
| // 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) |
