0-tick blog

Welcome

I'm Tobiáš. As programmer, I don't like wasting the user's time.
As a goal, It involves knowing many things that I hope to write about on this site. From internal hardware architecture details, to interface design. I also care about security.
Specifically I care about:
Learning parallelized programming like SIMD, CUDA/PTX & OpenCL/GCNasm, and Multithreading, the Demoscene, Modding, Privacy, Cybersecurity, CTFs, Internet infrastructure, Mathematics, Tooling, and especially, Videogames and Game Engine development.
I take my work seriously. I don't want to put out crap, so for the forseable future I'll be spending my time improving, and working for others instead of rushing to release my bigger personal projects.

Currently working on:

A text renderer for a text editor & terminal combo.
A .h264 video player.

Currently Learning from:

Casey Muratori's Performance Aware Substack
Intel CPU manuals
Fabian Giesen's Blog

Some of my work

Most of my personal projects to date have been made as learning experiences, built largely from scratch. here is a short rundown of the better ones, more details in upcoming articles I hope to write soon in the projects section.

• I've built programs for showing several media file formats: .png, .bmp, .wav, currently working on .h264, a video codec for container formats like .mp4.
• A basic forward pass renderer as well as an improved deferred multi pass renderer using OpenGL.
  
• 3D Tetris-like game based on the deferred renderer, using cut up furniture geometry for the pieces. Failed due to lack of experience. Hoping to revisit.
• A ray tracer, fractal geometry demo built on a university supplied framework also using OpenGL.
  
• A fluid simulation and shading demo on the same framework.
  
• Capture The Flag solver for common challenges. (Mostly superceeded by switching to Cyberchef)
• An i8086-like CPU emulator.
• I've also built some specific timing, debugging and visualisation tools for these projects.

Name of this website

In short, I believe computers are fast enough for most things to take no time at all.

The long winded explanation - The concept of gameplay 'tics' was introduced, or at least highly popularised in Quake III Arena by id Software, for the purpose of netcode syncing.
Another game, decades later, Minecraft did the same, and runs on 20 'ticks' every second. It uses interpolation to appear smoother, making it's visuals decoupled from it's discrete gameplay states.
The game features many gameplay systems, one of them, Minecraft's version of real life electronics called Redstone, is designed such that on each tick, any blocks that underwent power signal changes propagate this update into neighboring blocks instantly, and begin animating the change for the user. So. The wires propagate seemingly instantaneously, however, there is a strict order in which things happen, and this order is preserved when the signal reaches any kind of receiver. Knowing that fact is considered niche knowledge not many people playing the game know. Pistons, blocks capable of pushing or pulling blocks, can, due to the many quirks of their implementation and the aforementioned wire propagation order, be both powered and unpowered within the same game tick. This causes an attached block to be pushed instantaneously and skipping the extension animation.
As players explored this and related phenomena, they became colloquially known as 0-tick mechanics. This effect can be chained and ordered to create large interoperating mechanisms running at half the time usually required, and enabling certain otherwise completely impossible constructions. Yet It's not really any more difficult to learn than any of the other advanced mainstream redstone knowledge that the community came up with. The first time I saw this in action was a video called Block teleportation, because the machine was built to, within 0.00 in game seconds, push a block thousands of tiles away.
I was in awe.

Knowing 0-ticks is like knowing how to make good software

In many respects I view software the same way. There are certain low level concepts that pay large dividends to know, that don't take much more effort to learn than any of the higher level, situational knowledge like what to do with specific APIs in certain situations, or what checkboxes to tick when using bespoke tools. Knowing a few things about batching, about efficient data layout, about allocating large blocks of memory up-front instead of dynamically, and using memory arenas or pools instead of garbage collection or manual small individual element allocation can, in my opinion, go a long way to make making fast software far easier than it would be to make complex and slow software.