kprotty

const assert = @import("std").debug.assert;

fn compressBlock(writer: anytype, src: []const u8) !void {
    var table = [_]u32{0} ** 4096; // size is pow2. bump to match more. ideal = (0xffff+1) / sizeof(u32)
    var anchor: u32 = 0;
    
    if (src.len > 12) { // LZ4 spec restriction: last match must start 12b before end of block.
        var pos: u32 = 0;
        while (pos + 4 < src.len - 5) { // LZ4 spec restriction: last 5b are always literal.
            const blk: u32 = @bitCast(src[pos..][0..4].*);

cipharius

const std = @import("std");

fn mergeInPlace(comptime T: type, s: []T, midpoint: usize) void {
    std.debug.assert(midpoint <= s.len);
    if (midpoint == 0 or midpoint == s.len) return;

    var a: usize = 0;
    var b: usize = midpoint;
    var c: usize = midpoint;

mlarouche

So you want to handle save games ?

Most games once reaced a certain size will need to persist data between game sessions. In our game dev jargon, we call this data a Save Game.

Your first reflex would be to think: oh this is easy, we only need to find the user's documents or data folder and use simple file read and write operations to handle the save data.

Assumming we are using the Zig programming language, our favorite here at Cold Bytes Games, and the library known-folders, a naive save game serialization code could look like this (this code has not been tested).

const known_folders = @import("known-folders");

kprotty

partial ordering: time/events are related to each other as graphs of dependencies
total ordering: time/events are related to each other as a sequence of steps

atomic op: op which is observed to either happen fully or not at all (no in-between)
atomic variable: memory location which atomic ops happen to
data race: non-atomic ops from 2+ threads on same memory location where one op is a write

load: an atomic read to observe a value
store: an atomic write to publish a value
read-modify-write (rmw): a read, updating the value, then a write, all atomically

emidoots

Because cross-compiling binaries for Windows is easier than building natively

I want Microsoft to do better, want Windows to be a decent development platform-and yet, I constantly see Microsoft playing the open source game: advertising how open-source and developer friendly they are - only to crush developers under the heel of the corporate behemoth's boot.

The people who work at Microsoft are amazing, kind, talented individuals. This is aimed at the company's leadership, who I feel has on many occassions crushed myself and other developers under. It's a plea for help.

The source of truth for the 'open source' C#, C++, Rust, and other Windows SDKs is proprietary

You probably haven't heard of it before, but if you've ever used win32 API bindings in C#, C++, Rust, or other languages, odds are they were generated from a repository called microsoft/win32metadata.

andrewrk

import string
import random
vowels = "aoeuiy"
def m():
    c1 = vowels[random.randint(0,len(vowels)-1)]
    c2 = string.ascii_lowercase[random.randint(0,len(string.ascii_lowercase)-1)]
    c3 = string.ascii_lowercase[random.randint(0,len(string.ascii_lowercase)-1)]
    print('z' + c1 + c2 + c3)

m()

jboner

Latency Comparison Numbers (~2012)
----------------------------------
L1 cache reference                           0.5 ns
Branch mispredict                            5   ns
L2 cache reference                           7   ns                      14x L1 cache
Mutex lock/unlock                           25   ns
Main memory reference                      100   ns                      20x L2 cache, 200x L1 cache
Compress 1K bytes with Zippy             3,000   ns        3 us
Send 1K bytes over 1 Gbps network       10,000   ns       10 us
Read 4K randomly from SSD*             150,000   ns      150 us          ~1GB/sec SSD