| f :: Integer -> Integer | |
| f n = n + 1 | |
| b :: Integer -> Integer -> Integer | |
| b m n | |
| | m == 0 && n > 0 = f n | |
| | m > 0 && n == 0 = b (m - 1) 1 | |
| | otherwise = b (m - 1) (b m (n - 1)) | |
| g :: Integer -> Integer |
| // | |
| // _oo0oo_ | |
| // o8888888o | |
| // 88" . "88 | |
| // (| -_- |) | |
| // 0\ = /0 | |
| // ___/`---'\___ | |
| // .' \\| |// '. | |
| // / \\||| : |||// \ | |
| // / _||||| -:- |||||- \ |
Please consider using http://lygia.xyz instead of copy/pasting this functions. It expand suport for voronoi, voronoise, fbm, noise, worley, noise, derivatives and much more, through simple file dependencies. Take a look to https://github.com/patriciogonzalezvivo/lygia/tree/main/generative
float rand(float n){return fract(sin(n) * 43758.5453123);}
float noise(float p){
float fl = floor(p);
float fc = fract(p);
| For advanced users, a syntax highlighter for sublime text and | |
| textmate which makes reading the list easier can be found here: | |
| https://gist.github.com/jocopa3/e4a35921e4f978572e7f45360d231f37 | |
| ============ Blocks ============ | |
| All blocks as found in the 1.1.0.0 Block::initBlocks function. | |
| Block names are the same names used in the /give command. | |
| Name Id Data |
テトリス Advent Calendar 2017 17日目の記事になります。
こんにちは。newjade と申します。普段はパフェ用のツールを作りつつ、理論値を調べているパフェ屋さんです。だいたい twitter に出没しています。
今日はタイトルにもある通りプログラミングネタ、アルゴリズムの話です。
まず最初に断っておきたいのは、
今回の記事、テトリスのゲームをプレイする上で役に立つことは全く書いてありません。
Paletted chunks & removing BlockIDs brings a few big changes to how blocks are represented. In Bedrock, Blocks used to be represented by their 8 bit ID and 4 bit data; this means that we can only represent 256 blocks and 16 variants for each block. As it happens we ran out of IDs in Update Aquatic, so we had to do something about it :)
After this change, we can represent infinite types of Blocks and infinite BlockStates, just like in Java. BlockStates are what is sent over the network as they are roughly equivalent to the old ID+data information, eg. they're all the information attached to a block.
BlockStates are serialized in two ways:
PersistentID: a PersistentID is a NBT tag containing the BlockState name and its variant number; for example
| [ | |
| { | |
| "data": 0, | |
| "id": 0, | |
| "name": "minecraft:air", | |
| "runtimeID": 0 | |
| }, | |
| { | |
| "data": 0, | |
| "id": 1, |
tmux, like other great software, is deceptive. On the one hand, it's fairly easy to get set up and start using right away. On the other hand, it's difficult to take advantage of tmux's adanced features without spending some quality alone time with the manual. But the problem with manuals is that they aren't geared toward beginners. They are geared toward helping seasoned developers and computer enthusiasts quickly obtain the
The Client Blob Cache is a new Bedrock optimization - it allows blocks and biomes to be cached on Clients to avoid resending identical chunks over and over. Chunks and biomes make up the vast majority of network traffic in a lot of common cases (eg. login, teleport or dimension switches) but at the same time, they rarely change. Allowing the Client to reuse chunks it has seen in the past can save a ton of traffic and latency!
The Client Cache is a Content Addressed Storage (a bit like git) that stores Blobs and retrieves them based on their full hashes (BlobIds). This means that the cache doesn't actually know about Chunks - in the future, we might start using it for more types of data, like skins or data driven entities.
A nice thing we get from the CAS approach is that the cache is persistent: returning players will be able to reuse content that was sent them in previous sessions or even previous sessions in different servers as long as tha
I've commented a few times about some issues I see with the scalability of ActivityPub - the protocol behind the Fediverse and its best-known implementation Mastodon. A couple of folks have asked for more elaboration, so ... here it is.
First, let me add some disclaimers and warnings. I haven't devoted a lot of time to looking at ActivityPub, so there might be some things I've misunderstood about it. On the other hand, I've brought bigger systems - similar node counts and orders of magnitude more activity per node - from broken to working well based on less study of the protocols involved. So if you want to correct particular misconceptions, that's great. Thank you in advance. If you want to turn this into an appeal to authority and say that I'm wrong only because I haven't developed a full ActivityPub implementation or worked on it for X years ... GTFO.
What is ActivityPub? It's an HTTP- and JSON-based protocol for exchanging information about "activities". An activity could be many things.