update issues
This commit is contained in:
parent
04a346d851
commit
2a68cfbf63
44 changed files with 1201 additions and 318 deletions
|
|
@ -5,6 +5,7 @@
|
|||
|
||||
% id = "01HY5R1ZV9G92SVA0XP7CG1X6K"
|
||||
- as in this case:
|
||||
|
||||
```c
|
||||
void example(int *x) {
|
||||
int y = *x; // (1)
|
||||
|
|
@ -19,10 +20,10 @@
|
|||
- doesn't `*x` mean "read the value pointed to by `x`?"
|
||||
|
||||
% id = "01HY5R1ZV9WJM9DMW5QGK04DCR"
|
||||
- TL;DR: the deal with this example is that `*x` *does not mean* "read from the location pointed to by `x`", but _just_ "the location pointed to by `x`".
|
||||
- TL;DR: the deal with this example is that `*x` _does not mean_ "read from the location pointed to by `x`", but _just_ "the location pointed to by `x`".
|
||||
|
||||
% id = "01HY5R1ZV9JN9GZ8BECJ0KV1FC"
|
||||
- **`*x` is not a _value_, it's a _memory location_, or _place_ in Rust parlance**
|
||||
- *`*x` is not a _value_, it's a _memory location_, or _place_ in Rust parlance*
|
||||
|
||||
% id = "01HY5R1ZV9QVH3W5BRS16V6EPG"
|
||||
- same thing with `x`
|
||||
|
|
@ -154,6 +155,7 @@ for starters, it is impossible to write the type down in C code, so we're always
|
|||
|
||||
% id = "01HY5R1ZV9VZFHRKY4QWBDTFJ7"
|
||||
- example:
|
||||
|
||||
```c.types
|
||||
void example(void) {
|
||||
struct S { int x; } s;
|
||||
|
|
@ -168,6 +170,7 @@ for starters, it is impossible to write the type down in C code, so we're always
|
|||
the function signature is therefore `T* -> ptrdiff_t -> place(T)`.
|
||||
|
||||
example:
|
||||
|
||||
```c.types
|
||||
void example(int* array) {
|
||||
int* p = &((array /*: int* */)[123] /*: place(int) */);
|
||||
|
|
@ -184,7 +187,7 @@ for starters, it is impossible to write the type down in C code, so we're always
|
|||
|
||||
% id = "01HY5R1ZV9MQWK5VQZQG8JJ03J"
|
||||
- I do wonder though why it doesn't produce a warning.
|
||||
I'm no standards lawyer, but I *believe* this may have something to do with implicit type conversions - the `0` gets promoted to a
|
||||
I'm no standards lawyer, but I _believe_ this may have something to do with implicit type conversions - the `0` gets promoted to a
|
||||
pointer as part of the desugared addition.
|
||||
I really need to read up about C's type promotion rules.
|
||||
|
||||
|
|
@ -193,8 +196,8 @@ for starters, it is impossible to write the type down in C code, so we're always
|
|||
there are no places in C.
|
||||
|
||||
% id = "01HY5R1ZV9PAD1XRS29YV64GV2"
|
||||
- the C standard actually calls this concept "lvalues", which comes from the fact that they are **values** which are valid
|
||||
**l**eft-hand sides of assignment.
|
||||
- the C standard actually calls this concept "lvalues", which comes from the fact that they are *values* which are valid
|
||||
*l*eft-hand sides of assignment.
|
||||
|
||||
% id = "01HY5R1ZV9BNZM45RK2AW8BF5N"
|
||||
+ however, I don't like that name since it's quite esoteric - if you tell a beginner "`x` is not an lvalue," they will look at you confused.
|
||||
|
|
@ -223,7 +226,8 @@ there are no places in C.
|
|||
in layman's terms, C++ makes it impossible to rebind references to something else.
|
||||
you can't make this variable point to `y`:
|
||||
|
||||
<!-- NOTE: using `c` syntax here instead of `cpp` because I don't have a working C++ syntax at the moment! -->
|
||||
{% NOTE: using `c` syntax here instead of `cpp` because I don't have a working C++ syntax at the moment! %}
|
||||
|
||||
```c
|
||||
int x = 0;
|
||||
int y = 1;
|
||||
|
|
@ -253,10 +257,11 @@ there are no places in C.
|
|||
- I actually kind of wish references were more like they are in Rust - basically just pointers but non-null and guaranteed to be aligne
|
||||
|
||||
% id = "01HY5R1ZV9QWHZRJ5V53CVYG5V"
|
||||
- anyways, as a final ~~boss~~ bonus of this blog post, I'd like to introduce you to the `x->y` operator (the C one)
|
||||
- anyways, as a final {-boss-} bonus of this blog post, I'd like to introduce you to the `x->y` operator (the C one)
|
||||
|
||||
% id = "01HY5R1ZV9AYFWV96FC07WX68G"
|
||||
- if you've been programmming C or C++ for a while, you'll know that it's pretty dangerous to just go pointer-[walkin'](https://www.youtube.com/watch?v=d_dLIy2gQGU) with the `->` operator
|
||||
|
||||
```c
|
||||
int* third(struct list* first) {
|
||||
return &list->next->next->value;
|
||||
|
|
@ -278,6 +283,7 @@ there are no places in C.
|
|||
|
||||
% id = "01HY5R1ZV9X8M5T64BD0MZ2WN2"
|
||||
- let's start by dismantling the entire pointer access chain into separate expressions:
|
||||
|
||||
```c
|
||||
int* third(struct list* first) {
|
||||
struct list* second = first->next;
|
||||
|
|
@ -288,6 +294,7 @@ there are no places in C.
|
|||
|
||||
% id = "01HY5R1ZV9PGQMS2A6H5XTWYZX"
|
||||
- now let's desugar the `->` operator:
|
||||
|
||||
```c
|
||||
int* third(struct list* first) {
|
||||
struct list* second = (*first).next;
|
||||
|
|
@ -298,6 +305,7 @@ there are no places in C.
|
|||
|
||||
% id = "01HY5R1ZV92CZAV13P4KFABTR1"
|
||||
- and add some type annotations:
|
||||
|
||||
```c.types
|
||||
int* third(struct list* first) {
|
||||
struct list* second = (*first).next /*: place(struct list*) */;
|
||||
|
|
|
|||
|
|
@ -1,21 +1,20 @@
|
|||
%% title = "OR-types"
|
||||
scripts = ["components/literate-programming.js"]
|
||||
|
||||
% id = "01HTWN4XAD7C41X8XKRBFZMHJ8"
|
||||
- last night I couldn't fall asleep because I was thinking how sites like [Anilist](https://anilist.co) implement their tag-based search systems.
|
||||
|
||||
% id = "01HTWN4XAD4CPDR36P4XNYZAE3"
|
||||
- my mind was racing, and with enough thinking about scores and weights and sums and products… I arrived at the topic of *sum types* and *product types.*
|
||||
- my mind was racing, and with enough thinking about scores and weights and sums and products… I arrived at the topic of _sum types_ and _product types._
|
||||
|
||||
% id = "01HTWN4XAD4NK5TRFVPCC4EHJ2"
|
||||
- I was thinking, "*this is actually really interesting - why do we call them sum types and product types?*" -
|
||||
- I was thinking, "_this is actually really interesting - why do we call them sum types and product types?_" -
|
||||
I had some intuitive understanding as to where these names come from, but I wanted to write down my thoughts for future me, and future generations.
|
||||
|
||||
% id = "01HTWN4XADR3SARMFCF6PB8T7D"
|
||||
- so I set down an alarm for today, and went to sleep.
|
||||
|
||||
% id = "01HTWN4XADJ9NAWKY8G4BDS9E0"
|
||||
- recall that I was faced with the question of "why do we call product types *product types*, and why do we call sum types *sum types*?"
|
||||
- recall that I was faced with the question of "why do we call product types _product types_, and why do we call sum types _sum types_?"
|
||||
my intuitive understanding was this:
|
||||
|
||||
% id = "01HTWN4XADVCMHQCGDM4RM6YBN"
|
||||
|
|
@ -168,7 +167,7 @@ my intuitive understanding was this:
|
|||
- `U` is a subtype of `T | U`, because `T` is not present (`0`) and `U` is (`1`), therefore `has(T) XOR has(U)` is true.
|
||||
|
||||
% id = "01HTWN4XAD15CWASNFEQRTP0H7"
|
||||
- *but* unlike our previous hypothetical `T + U`, `T * U` is not a subtype of `T | U`, because if `T` is present (`1`) and `U` is also present (`1`), `has(T) XOR has(U)` will be false -
|
||||
- _but_ unlike our previous hypothetical `T + U`, `T * U` is not a subtype of `T | U`, because if `T` is present (`1`) and `U` is also present (`1`), `has(T) XOR has(U)` will be false -
|
||||
which matches more typical sum types.
|
||||
|
||||
% id = "01HTWN4XADJC8ZHBHNTSDW8EQP"
|
||||
|
|
@ -181,7 +180,7 @@ my intuitive understanding was this:
|
|||
- this confused me a lot because, from my limited understanding of them, set-theoretic types represents types as sets of possible values - and mathematically any set `S` can be represented by a function `S(x)`, which is `true` if `x` is present in the set
|
||||
|
||||
% id = "01HTWN4XADSSASE388BBS79X7J"
|
||||
- but again, it is *not* the same, because the type system I described here is defined based on subtype relations rather than sets of values.
|
||||
- but again, it is _not_ the same, because the type system I described here is defined based on subtype relations rather than sets of values.
|
||||
|
||||
% id = "01HTWN4XADQ3F5CYBEN44J10D5"
|
||||
- in the world of set-theoretic types, we get sum types for free, because the type `T | U` represents the union of the set of all possible `T` values, and the set of all possible `U` values.
|
||||
|
|
@ -229,10 +228,10 @@ I'll add a note to this post summarizing what's wrong with my reasoning.
|
|||
- seem familiar? it's exactly the same as the truth table for `AND`ing two numbers!
|
||||
|
||||
% id = "01HTWN4XADB7K02JDWMJ5T3KN9"
|
||||
- except because we're working with _numbers_ here, we can take it a step further and multiply *any* two numbers, not just zero and one.
|
||||
- except because we're working with _numbers_ here, we can take it a step further and multiply _any_ two numbers, not just zero and one.
|
||||
|
||||
% id = "01HTWN4XAD9ESATEWPNC6Y72S3"
|
||||
- therefore we can search and rank our anime about crimes in space based on a *score* produced by multiplying the tag values.
|
||||
- therefore we can search and rank our anime about crimes in space based on a _score_ produced by multiplying the tag values.
|
||||
let's see [what Anilist tells us about crimes in space](https://anilist.co/search/anime?genres=Space&genres=Crime).
|
||||
|
||||
I wrote down the data of the first 10 anime it displayed to me on the day I'm writing this, so this data may become out of date with time. ignoring spoiler tags because noone likes those.
|
||||
|
|
|
|||
|
|
@ -35,9 +35,9 @@ or even where to go to customize it to my liking?
|
|||
code to see what happened.
|
||||
|
||||
% id = "01HV1DGFGNY3FGEKY70D6RMV22"
|
||||
- and then I could edit the source code and submit the patch *right where I'm standing* rather than having to go through complicated and lengthy processes of cloning repositories,
|
||||
- and then I could edit the source code and submit the patch _right where I'm standing_ rather than having to go through complicated and lengthy processes of cloning repositories,
|
||||
bootstrapping, reproducing, and such.
|
||||
*imagine fixing compiler bugs on real codebases rather than having to come up with isolated, reproducible examples first.*
|
||||
_imagine fixing compiler bugs on real codebases rather than having to come up with isolated, reproducible examples first._
|
||||
|
||||
% id = "01HV1DGFGNXJJX0BMMM3KQ42M0"
|
||||
- I know how hard this is to achieve in practice, which is precisely why I don't use Gentoo.
|
||||
|
|
@ -87,13 +87,13 @@ or even where to go to customize it to my liking?
|
|||
- have fun typing in that full path `/home/daknus/Repositories/cool-library`
|
||||
|
||||
% id = "01HV1DGFGN5X57Z807GMS3F07Q"
|
||||
+ *and* don't forget to revert the changes to `Cargo.toml` once you're done.
|
||||
+ _and_ don't forget to revert the changes to `Cargo.toml` once you're done.
|
||||
unlike editing a vendored dependency, which will appear under a very visible path in Git, it's pretty easy to forget to check your `Cargo.toml` diff before staging/committing changes.
|
||||
I mean, I edit my `Cargo.toml` all the time, adding in libaries and stuff.
|
||||
so why would I look at every single change?
|
||||
|
||||
% id = "01HV1DGFGN0DAMASGQD64XXTRK"
|
||||
- *and* before you go at me and say "bah you should be reviewing all changes that end up in your codebase"
|
||||
- _and_ before you go at me and say "bah you should be reviewing all changes that end up in your codebase"
|
||||
|
||||
sigh.
|
||||
|
||||
|
|
@ -123,17 +123,17 @@ or even where to go to customize it to my liking?
|
|||
it's all just code-generating syntax sugar!
|
||||
|
||||
% id = "01HV1DGFGNVRX5C3TST00V58DK"
|
||||
- **everything is code! *there is no magic*!**
|
||||
- *everything is code! _there is no magic_!*
|
||||
|
||||
% id = "01HV1DGFGN569R7MEE9FBXRF7H"
|
||||
- there are no walls blocking you from looking at the code. the grandiose noun phrases are misleading!
|
||||
|
||||
% id = "01HV1DGFGNE1CTAX01DE61GWC5"
|
||||
- UnrealBuildTool is just a bunch of C# files. and the *Gameplay Ability System™* is likewise just a bunch of C++ sources.
|
||||
- UnrealBuildTool is just a bunch of C# files. and the _Gameplay Ability System™_ is likewise just a bunch of C++ sources.
|
||||
why can't we come up with more inviting names?
|
||||
|
||||
% id = "01HV1DGFGN129VY5FHHF4GC4Z5"
|
||||
- grandiose noun phrases sound so hostile. *but it's all just code.*
|
||||
- grandiose noun phrases sound so hostile. _but it's all just code._
|
||||
|
||||
% id = "01HV1DGFGN96CPWYMJ14EWJJR2"
|
||||
- most of the time not knowing your software is largely fine - not everyone has the time to deeply inspect a piece of software, deciphering functions, consulting manuals, asking the authors (when possible.)
|
||||
|
|
|
|||
|
|
@ -29,14 +29,18 @@ styles = ["page/tairu.css"]
|
|||
% id = "01HQ162WWAMCPC5M88QAXHX4BT"
|
||||
- so to help us learn, I made a little tile editor so that we can experiment with rendering tiles! have a look:
|
||||
|
||||
<noscript>(…though you will need to enable JavaScript to try it out.
|
||||
{% this could probably be written with some clever generator magic, but I'm too lazy for that %}
|
||||
`<noscript>`{=html}
|
||||
(…though you will need to enable JavaScript to try it out.
|
||||
seriously, pinky promise I won't ever track you!
|
||||
inspect the source code if you wanna.
|
||||
if not, you will have to deal with static pictures.
|
||||
but just keep in mind this was supposed to be an <strong><em>interactive</em></strong> exploration of autotiling techniques.
|
||||
cheers!)</noscript>
|
||||
but just keep in mind this was supposed to be an _*interactive*_ exploration of autotiling techniques.
|
||||
cheers!)
|
||||
`</noscript>`{=html}
|
||||
|
||||
```javascript tairu
|
||||
{:program=tairu}
|
||||
```javascript
|
||||
import { Tilemap } from "tairu/tilemap.js";
|
||||
import { TileEditor } from "tairu/editor.js";
|
||||
|
||||
|
|
@ -54,22 +58,26 @@ styles = ["page/tairu.css"]
|
|||
});
|
||||
```
|
||||
|
||||
```output tairu 01HQ47ZX7520PJNPJ75M793R5G
|
||||
{:program=tairu :placeholder=01HQ47ZX7520PJNPJ75M793R5G}
|
||||
```output
|
||||
```
|
||||
|
||||
% id = "01HQ162WWAC3FN565QE3JAB87D"
|
||||
- `Tilemap` is a class wrapping a flat [`Uint8Array`] with a `width` and a `height`, so that we can index it using (x, y) coordinates.
|
||||
- `Tilemap` is a class wrapping a flat [`Uint8Array`][Uint8Array] with a `width` and a `height`, so that we can index it using (x, y) coordinates.
|
||||
|
||||
```javascript tairu
|
||||
{:program=tairu}
|
||||
```javascript
|
||||
console.log(tilemapSquare.at(0, 0));
|
||||
console.log(tilemapSquare.at(3, 1));
|
||||
```
|
||||
```output tairu
|
||||
|
||||
{:program=tairu}
|
||||
```output
|
||||
0
|
||||
1
|
||||
```
|
||||
|
||||
[`Uint8Array`]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Uint8Array
|
||||
[Uint8Array]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Uint8Array
|
||||
|
||||
% id = "01HQ162WWA090YW5BR1XW68XJN"
|
||||
- `at` has a `setAt` counterpart which sets tiles instead of getting them.
|
||||
|
|
@ -90,34 +98,35 @@ styles = ["page/tairu.css"]
|
|||
- let's break this down into smaller steps. drawing a border around the rectangle will involve:
|
||||
|
||||
% id = "01HQ162WWATV30HXGBQVWERP2M"
|
||||
- determining *on which tiles* to draw it,
|
||||
- determining _on which tiles_ to draw it,
|
||||
|
||||
% id = "01HQ162WWAA0V0SS0D1Y38BDS1"
|
||||
- determining *where in these tiles* to draw it,
|
||||
- determining _where in these tiles_ to draw it,
|
||||
|
||||
% id = "01HQ162WWAGBCBDYF4VH26MX1B"
|
||||
- and actually drawing it!
|
||||
|
||||
% id = "01HQ162WWA2PNGVV075HR3WMER"
|
||||
- so let's zoom in a bit and look at the tiles one by one. in particular, let's focus on *these* two tiles:
|
||||
- so let's zoom in a bit and look at the tiles one by one. in particular, let's focus on _these_ two tiles:
|
||||
|
||||
![the same red rectangle, now with a focus on the northern tile at its center][pic:01HPYWPJB1P0GK53BSJFJFRAGR]
|
||||
|
||||
% id = "01HQ162WWAYDS6CSD3T102NA9X"
|
||||
- notice how the two highlighted tiles are *different.* therefore, we can infer we should probably connect together any tiles that are *the same*.
|
||||
- notice how the two highlighted tiles are _different._ therefore, we can infer we should probably connect together any tiles that are _the same_.
|
||||
|
||||
% id = "01HQ162WWATDD86D4GY7RMT0BZ"
|
||||
- knowing that, we can extract the logic to a function:
|
||||
|
||||
```javascript tairu
|
||||
{:program=tairu}
|
||||
```javascript
|
||||
export function shouldConnect(a, b) {
|
||||
return a == b;
|
||||
}
|
||||
```
|
||||
|
||||
% id = "01HQ162WWA9M6801Q0RNRSF09H"
|
||||
+ now, also note that the border around this particular tile is only drawn on its *northern* edge -
|
||||
therefore we can infer that borders should only be drawn on edges for whom `shouldConnect(thisTile, adjacentTile)` is **`false`** (not `true`!).
|
||||
+ now, also note that the border around this particular tile is only drawn on its _northern_ edge -
|
||||
therefore we can infer that borders should only be drawn on edges for whom `shouldConnect(thisTile, adjacentTile)` is *`false`* (not `true`!).
|
||||
a tile generally has four edges - east, south, west, north - so we need to perform this check for all of them, and draw our border accordingly.
|
||||
|
||||
% id = "01HQ162WWAM5YYQCEXH791T0E9"
|
||||
|
|
@ -135,7 +144,8 @@ styles = ["page/tairu.css"]
|
|||
% id = "01HQ162WWA5W8NXSXVZY3BBQ0H"
|
||||
- to do that, I'm gonna override the tile editor's `drawTilemap` function - as this is where the actual tilemap rendering happens!
|
||||
|
||||
```javascript tairu
|
||||
{:program=tairu}
|
||||
```javascript
|
||||
import { TileEditor } from "tairu/editor.js";
|
||||
|
||||
export class TileEditorWithBorders extends TileEditor {
|
||||
|
|
@ -160,7 +170,7 @@ styles = ["page/tairu.css"]
|
|||
continue;
|
||||
}
|
||||
|
||||
// Check which of this tile's neighbors should *not* connect to it.
|
||||
// Check which of this tile's neighbors should _not_ connect to it.
|
||||
let disjointWithEast = !shouldConnect(tile, this.tilemap.at(x + 1, y));
|
||||
let disjointWithSouth = !shouldConnect(tile, this.tilemap.at(x, y + 1));
|
||||
let disjointWithWest = !shouldConnect(tile, this.tilemap.at(x - 1, y));
|
||||
|
|
@ -191,14 +201,17 @@ styles = ["page/tairu.css"]
|
|||
|
||||
and here's the result:
|
||||
|
||||
```javascript tairu
|
||||
{:program=tairu}
|
||||
```javascript
|
||||
new TileEditorWithBorders({
|
||||
tilemap: tilemapSquare,
|
||||
tileSize: 40,
|
||||
borderWidth: 4,
|
||||
});
|
||||
```
|
||||
```output tairu 01HQ49TJZFMK719KSE16SG3F7B
|
||||
|
||||
{:program=tairu :placeholder=01HQ49TJZFMK719KSE16SG3F7B}
|
||||
```output
|
||||
```
|
||||
|
||||
% id = "01HQ162WWAAEKW1ECV5G3ZEY47"
|
||||
|
|
@ -221,58 +234,58 @@ styles = ["page/tairu.css"]
|
|||
id = "01HQ162WWAS502000K8QZWVBDW"
|
||||
- we can split this tileset up into 16 individual tiles, each one 8 × 8 pixels; people choose various resolutions, I chose a fairly low one to hide my lack of artistic skill.
|
||||
|
||||
<div class="horizontal-tile-strip">
|
||||
<span class="metal x-0 y-0"></span>
|
||||
<span class="metal x-1 y-0"></span>
|
||||
<span class="metal x-2 y-0"></span>
|
||||
<span class="metal x-3 y-0"></span>
|
||||
<span class="metal x-0 y-1"></span>
|
||||
<span class="metal x-1 y-1"></span>
|
||||
<span class="metal x-2 y-1"></span>
|
||||
<span class="metal x-3 y-1"></span>
|
||||
<span class="metal x-0 y-2"></span>
|
||||
<span class="metal x-1 y-2"></span>
|
||||
<span class="metal x-2 y-2"></span>
|
||||
<span class="metal x-3 y-2"></span>
|
||||
<span class="metal x-0 y-3"></span>
|
||||
<span class="metal x-1 y-3"></span>
|
||||
<span class="metal x-2 y-3"></span>
|
||||
<span class="metal x-3 y-3"></span>
|
||||
</div>
|
||||
::: horizontal-tile-strip
|
||||
[]{.metal .x-0 .y-0}
|
||||
[]{.metal .x-1 .y-0}
|
||||
[]{.metal .x-2 .y-0}
|
||||
[]{.metal .x-3 .y-0}
|
||||
[]{.metal .x-0 .y-1}
|
||||
[]{.metal .x-1 .y-1}
|
||||
[]{.metal .x-2 .y-1}
|
||||
[]{.metal .x-3 .y-1}
|
||||
[]{.metal .x-0 .y-2}
|
||||
[]{.metal .x-1 .y-2}
|
||||
[]{.metal .x-2 .y-2}
|
||||
[]{.metal .x-3 .y-2}
|
||||
[]{.metal .x-0 .y-3}
|
||||
[]{.metal .x-1 .y-3}
|
||||
[]{.metal .x-2 .y-3}
|
||||
[]{.metal .x-3 .y-3}
|
||||
:::
|
||||
|
||||
% classes.branch = "tileset-cardinal-directions-demo"
|
||||
id = "01HQ162WWANBTYH1JJWCTZYYVN"
|
||||
- the keen eyed among you have probably noticed that this is very similar to the case we had before with drawing procedural borders -
|
||||
except that instead of determining which borders to draw based on a tile's neighbors, this time we'll determine which *whole tile* to draw based on its neighbors!
|
||||
except that instead of determining which borders to draw based on a tile's neighbors, this time we'll determine which _whole tile_ to draw based on its neighbors!
|
||||
|
||||
<div class="horizontal-tile-strip">
|
||||
<span class="metal x-0 y-0"><span class="east">E</span><span class="south">S</span></span>
|
||||
<span class="metal x-1 y-0"><span class="east">E</span><span class="south">S</span><span class="west">W</span></span>
|
||||
<span class="metal x-2 y-0"><span class="south">S</span><span class="west">W</span></span>
|
||||
<span class="metal x-3 y-0"><span class="south">S</span></span>
|
||||
<span class="metal x-0 y-1"><span class="east">E</span><span class="south">S</span><span class="north">N</span></span>
|
||||
<span class="metal x-1 y-1"><span class="east">E</span><span class="south">S</span><span class="west">W</span><span class="north">N</span></span>
|
||||
<span class="metal x-2 y-1"><span class="south">S</span><span class="west">W</span><span class="north">N</span></span>
|
||||
<span class="metal x-3 y-1"><span class="south">S</span><span class="north">N</span></span>
|
||||
<span class="metal x-0 y-2"><span class="east">E</span><span class="north">N</span></span>
|
||||
<span class="metal x-1 y-2"><span class="east">E</span><span class="west">W</span><span class="north">N</span></span>
|
||||
<span class="metal x-2 y-2"><span class="west">W</span><span class="north">N</span></span>
|
||||
<span class="metal x-3 y-2"><span class="north">N</span></span>
|
||||
<span class="metal x-0 y-3"><span class="east">E</span></span>
|
||||
<span class="metal x-1 y-3"><span class="east">E</span><span class="west">W</span></span>
|
||||
<span class="metal x-2 y-3"><span class="west">W</span></span>
|
||||
<span class="metal x-3 y-3"></span>
|
||||
</div>
|
||||
::: horizontal-tile-strip
|
||||
[[E]{.east} [S]{.south}]{.metal .x-0 .y-0}
|
||||
[[E]{.east} [S]{.south} [W]{.west}]{.metal .x-1 .y-0}
|
||||
[[S]{.south} [W]{.west}]{.metal .x-2 .y-0}
|
||||
[[S]{.south}]{.metal .x-3 .y-0}
|
||||
[[E]{.east} [S]{.south} [N]{.north}]{.metal .x-0 .y-1}
|
||||
[[E]{.east} [S]{.south} [W]{.west} [N]{.north}]{.metal .x-1 .y-1}
|
||||
[[S]{.south} [W]{.west} [N]{.north}]{.metal .x-2 .y-1}
|
||||
[[S]{.south} [N]{.north}]{.metal .x-3 .y-1}
|
||||
[[E]{.east} [N]{.north}]{.metal .x-0 .y-2}
|
||||
[[E]{.east} [W]{.west} [N]{.north}]{.metal .x-1 .y-2}
|
||||
[[W]{.west} [N]{.north}]{.metal .x-2 .y-2}
|
||||
[[N]{.north}]{.metal .x-3 .y-2}
|
||||
[[E]{.east}]{.metal .x-0 .y-3}
|
||||
[[E]{.east} [W]{.west}]{.metal .x-1 .y-3}
|
||||
[[W]{.west}]{.metal .x-2 .y-3}
|
||||
[]{.metal .x-3 .y-3}
|
||||
:::
|
||||
|
||||
% id = "01HQ162WWA4Z6KKWFV59BR4WD3"
|
||||
- previously we represented which single border to draw with a single boolean.
|
||||
now we will represent which single tile to draw with *four* booleans, because each tile can connect to four different directions.
|
||||
now we will represent which single tile to draw with _four_ booleans, because each tile can connect to four different directions.
|
||||
|
||||
% id = "01HQ162WWAQ9GZ6JD8KESW4N53"
|
||||
- four booleans like this can easily be packed into a single integer using some bitwise operations, hence we get ***bitwise autotiling*** - autotiling using bitwise operations!
|
||||
- four booleans like this can easily be packed into a single integer using some bitwise operations, hence we get _*bitwise autotiling*_ - autotiling using bitwise operations!
|
||||
|
||||
% id = "01HQ162WWAMBM8RXKQTN3D0XR2"
|
||||
- now the clever part of bitwise autotiling is that we can use this packed integer *as an array index* - therefore selecting which tile to draw can be determined using just a single lookup table! neat, huh?
|
||||
- now the clever part of bitwise autotiling is that we can use this packed integer _as an array index_ - therefore selecting which tile to draw can be determined using just a single lookup table! neat, huh?
|
||||
|
||||
% id = "01HQ162WWA0ZGZ97JZZBFS41TF"
|
||||
- but because I'm lazy, and CPU time is valuable, instead of using an array I'll just rearrange the tileset texture a bit to be able to slice it in place using this index.
|
||||
|
|
@ -280,7 +293,8 @@ styles = ["page/tairu.css"]
|
|||
% id = "01HQ162WWAQQ99TRBDY5DCSW3Z"
|
||||
- say we arrange our bits like this:
|
||||
|
||||
```javascript tairu
|
||||
{:program=tairu}
|
||||
```javascript
|
||||
export const E = 0b0001;
|
||||
export const S = 0b0010;
|
||||
export const W = 0b0100;
|
||||
|
|
@ -291,32 +305,32 @@ styles = ["page/tairu.css"]
|
|||
id = "01HQ162WWABANND0WGT933TBMV"
|
||||
- that means we'll need to arrange our tiles like so, where the leftmost tile is at index 0 (`0b0000`) and the rightmost tile is at index 15 (`0b1111`):
|
||||
|
||||
<div class="horizontal-tile-strip">
|
||||
<span class="metal x-3 y-3"></span>
|
||||
<span class="metal x-0 y-3"><span class="east">E</span></span>
|
||||
<span class="metal x-3 y-0"><span class="south">S</span></span>
|
||||
<span class="metal x-0 y-0"><span class="east">E</span><span class="south">S</span></span>
|
||||
<span class="metal x-2 y-3"><span class="west">W</span></span>
|
||||
<span class="metal x-1 y-3"><span class="east">E</span><span class="west">W</span></span>
|
||||
<span class="metal x-2 y-0"><span class="south">S</span><span class="west">W</span></span>
|
||||
<span class="metal x-1 y-0"><span class="east">E</span><span class="south">S</span><span class="west">W</span></span>
|
||||
<span class="metal x-3 y-2"><span class="north">N</span></span>
|
||||
<span class="metal x-0 y-2"><span class="east">E</span><span class="north">N</span></span>
|
||||
<span class="metal x-3 y-1"><span class="south">S</span><span class="north">N</span></span>
|
||||
<span class="metal x-0 y-1"><span class="east">E</span><span class="south">S</span><span class="north">N</span></span>
|
||||
<span class="metal x-2 y-2"><span class="west">W</span><span class="north">N</span></span>
|
||||
<span class="metal x-1 y-2"><span class="east">E</span><span class="west">W</span><span class="north">N</span></span>
|
||||
<span class="metal x-2 y-1"><span class="south">S</span><span class="west">W</span><span class="north">N</span></span>
|
||||
<span class="metal x-1 y-1"><span class="east">E</span><span class="south">S</span><span class="west">W</span><span class="north">N</span></span>
|
||||
</div>
|
||||
::: horizontal-tile-strip
|
||||
[]{.metal .x-3 .y-3}
|
||||
[[E]{.east}]{.metal .x-0 .y-3}
|
||||
[[S]{.south}]{.metal .x-3 .y-0}
|
||||
[[E]{.east} [S]{.south}]{.metal .x-0 .y-0}
|
||||
[[W]{.west}]{.metal .x-2 .y-3}
|
||||
[[W]{.west} [E]{.east}]{.metal .x-1 .y-3}
|
||||
[[W]{.west} [S]{.south}]{.metal .x-2 .y-0}
|
||||
[[W]{.west} [E]{.east} [S]{.south}]{.metal .x-1 .y-0}
|
||||
[[N]{.north}]{.metal .x-3 .y-2}
|
||||
[[E]{.east} [N]{.north}]{.metal .x-0 .y-2}
|
||||
[[S]{.south} [N]{.north}]{.metal .x-3 .y-1}
|
||||
[[E]{.east} [S]{.south} [N]{.north}]{.metal .x-0 .y-1}
|
||||
[[W]{.west} [N]{.north}]{.metal .x-2 .y-2}
|
||||
[[E]{.east} [W]{.west} [N]{.north}]{.metal .x-1 .y-2}
|
||||
[[S]{.south} [W]{.west} [N]{.north}]{.metal .x-2 .y-1}
|
||||
[[E]{.east} [S]{.south} [W]{.west} [N]{.north}]{.metal .x-1 .y-1}
|
||||
:::
|
||||
|
||||
% id = "01HQ162WWAJPW00XA25N0K6KS7"
|
||||
- packing that into a single tileset, or rather this time, a *tile strip*, we get this image:
|
||||
- packing that into a single tileset, or rather this time, a _tile strip_, we get this image:
|
||||
|
||||
![horizontal tile strip of 16 8x8 pixel metal tiles][pic:01HPMMR6DGKYTPZ9CK0WQWKNX5]
|
||||
|
||||
% id = "01HQ162WWAT2ZC7T2P9ATD6WG2"
|
||||
- now it's time to actually implement it as code! I'll start by defining a *tile index* function as a general way of looking up tiles in a tileset.
|
||||
- now it's time to actually implement it as code! I'll start by defining a _tile index_ function as a general way of looking up tiles in a tileset.
|
||||
|
||||
% id = "01HQ162WWA0NRHBB6HP2RERNBK"
|
||||
- I want to make the tile renderer a bit more general, so being able to attach a different tile lookup function to each tileset sounds like a great feature.
|
||||
|
|
@ -327,7 +341,8 @@ styles = ["page/tairu.css"]
|
|||
% id = "01HQ162WWAYJ4JCG3Z24SJR8S9"
|
||||
- …but anyways, here's the basic bitwise magic function:
|
||||
|
||||
```javascript tairu
|
||||
{:program=tairu}
|
||||
```javascript
|
||||
export function tileIndexInBitwiseTileset(tilemap, x, y) {
|
||||
let tile = tilemap.at(x, y);
|
||||
|
||||
|
|
@ -345,7 +360,8 @@ styles = ["page/tairu.css"]
|
|||
id = "01HQ162WWAS813ANMBG1PWDZHC"
|
||||
- we'll define our tilesets by their texture, tile size, and a tile indexing function. so let's create an object that will hold our tileset data:
|
||||
|
||||
```javascript tairu
|
||||
{:program=tairu}
|
||||
```javascript
|
||||
// You'll probably want to host the assets on your own website rather than
|
||||
// hotlinking to others. It helps longevity!
|
||||
let tilesetImage = new Image();
|
||||
|
|
@ -361,7 +377,8 @@ styles = ["page/tairu.css"]
|
|||
% id = "01HQ162WWA0SC2GA7Y3KJE0W5F"
|
||||
- with all that, we should now be able to write a tile renderer which can handle textures! so let's try it:
|
||||
|
||||
```javascript tairu
|
||||
{:program=tairu}
|
||||
```javascript
|
||||
import { TileEditor } from "tairu/editor.js";
|
||||
|
||||
export class TilesetTileEditor extends TileEditor {
|
||||
|
|
@ -409,20 +426,24 @@ styles = ["page/tairu.css"]
|
|||
% id = "01HQ162WWAS2HYF41MZNJ18BXC"
|
||||
- drum roll please…
|
||||
|
||||
```javascript tairu
|
||||
{:program=tairu}
|
||||
```javascript
|
||||
new TilesetTileEditor({
|
||||
tilemap: tilemapSquare,
|
||||
tileSize: 40,
|
||||
tilesets: [heavyMetalTileset],
|
||||
});
|
||||
```
|
||||
```output tairu 01HQ49X8Z57FNMN3E79FYF8CMG
|
||||
|
||||
{:program=tairu :placeholder=01HQ49X8Z57FNMN3E79FYF8CMG}
|
||||
```output
|
||||
```
|
||||
|
||||
% id = "01HQ162WWA03JAGJYCT0DRZP24"
|
||||
- it works! buuuut if you play around with it you'll quickly start noticing some problems:
|
||||
|
||||
```javascript tairu
|
||||
{:program=tairu}
|
||||
```javascript
|
||||
import { Tilemap } from "tairu/tilemap.js";
|
||||
|
||||
export const tilemapEdgeCase = Tilemap.parse(" x", [
|
||||
|
|
@ -438,7 +459,9 @@ styles = ["page/tairu.css"]
|
|||
tilesets: [heavyMetalTileset],
|
||||
});
|
||||
```
|
||||
```output tairu 01HQ49YDPQXYSAT5N6P241DG3C
|
||||
|
||||
{:program=tairu :placeholder=01HQ49YDPQXYSAT5N6P241DG3C}
|
||||
```output
|
||||
```
|
||||
|
||||
% id = "01HQ162WWAB0AYSPGB4AEVT03Z"
|
||||
|
|
@ -448,9 +471,10 @@ styles = ["page/tairu.css"]
|
|||
- ### thing is, it was never good in the first place
|
||||
|
||||
% id = "01HQ162WWARSVDRNHZE13ZF6W6"
|
||||
- I'll be blunt: we don't have enough tiles to represent *corners*! like in this case:
|
||||
- I'll be blunt: we don't have enough tiles to represent _corners_! like in this case:
|
||||
|
||||
```javacript tairu
|
||||
{:program=tairu}
|
||||
```javascript
|
||||
import { Tilemap } from "tairu/tilemap.js";
|
||||
|
||||
new TilesetTileEditor({
|
||||
|
|
@ -464,7 +488,9 @@ styles = ["page/tairu.css"]
|
|||
tilesets: [heavyMetalTileset],
|
||||
});
|
||||
```
|
||||
```output tairu 01HQ49Z8JWR75D85DGHCB34K8E
|
||||
|
||||
{:program=tairu :placeholder=01HQ49Z8JWR75D85DGHCB34K8E}
|
||||
```output
|
||||
```
|
||||
|
||||
% id = "01HQ1K39AS4VDW7DVTAGQ03WFM"
|
||||
|
|
@ -476,50 +502,60 @@ styles = ["page/tairu.css"]
|
|||
- it should kind of _"bend"_ to fit in with the tiles to the north and the south, but it doesn't :kamien:
|
||||
|
||||
% id = "01HQ1K39ASQQNF7B881SYJWRC7"
|
||||
- so what if we made the tile look like *this* instead:
|
||||
- so what if we made the tile look like _this_ instead:
|
||||
|
||||
![mockup showing that previous L-shape but with a real corner][pic:01HQ17GYEZSZCVRBFHP4HXAJV8]
|
||||
|
||||
% id = "01HQ1K39ASMKRMTXFV93FRHZTG"
|
||||
- that sure as heck looks a lot nicer! but there's a problem: that tile, let's zoom in on it…
|
||||
|
||||
![that bent tile, and just *it* alone][pic:01HQ183RANGH4S7VZSG1ZGH0S5]
|
||||
![that bent tile, and just _it_ alone][pic:01HQ183RANGH4S7VZSG1ZGH0S5]
|
||||
|
||||
% classes.branch = "tileset-four-to-eight-demo"
|
||||
id = "01HQ1K39ASR81NWMW8Q0MF8QMP"
|
||||
- enhance!
|
||||
|
||||
|
||||
{% NOTE djot: I don't there's a way to achieve this in Djot alone %}
|
||||
``` =html
|
||||
<ul class="directions-square bend">
|
||||
<li class="east">E</li>
|
||||
<li class="south">S</li>
|
||||
</ul>
|
||||
```
|
||||
|
||||
% classes.branch = "tileset-four-to-eight-demo"
|
||||
id = "01HQ1K39ASC5WTR2A2AJN85JK2"
|
||||
- huh. interesting. it connects to the east and the south. so what about this tile -
|
||||
|
||||
``` =html
|
||||
<ul class="directions-square e-s">
|
||||
<li class="east">E</li>
|
||||
<li class="south">S</li>
|
||||
</ul>
|
||||
```
|
||||
|
||||
% id = "01HQ1K39ASXYBH9QJH5Q0C45JZ"
|
||||
- because it *also* connects to the east and the south :thinking:
|
||||
- because it _also_ connects to the east and the south :thinking:
|
||||
|
||||
% id = "01HQ1K39ASW5PWS52NGA2X3M0P"
|
||||
- seems like we'll need something to disambiguate the two cases - and what better thing to disambiguate with than *more bits*!
|
||||
- seems like we'll need something to disambiguate the two cases - and what better thing to disambiguate with than _more bits_!
|
||||
|
||||
% classes.branch = "tileset-four-to-eight-demo"
|
||||
id = "01HPQCCV4R5N97FJ1GS36HZJZ7"
|
||||
- to represent the corners, we'll turn our four cardinal directions…
|
||||
|
||||
``` =html
|
||||
<ul class="directions-square">
|
||||
<li class="east">E</li>
|
||||
<li class="south">S</li>
|
||||
<li class="west">W</li>
|
||||
<li class="north">N</li>
|
||||
</ul>
|
||||
```
|
||||
|
||||
into eight *ordinal* directions:
|
||||
into eight _ordinal_ directions:
|
||||
|
||||
``` =html
|
||||
<ul class="directions-square">
|
||||
<li class="east">E</li>
|
||||
<li class="south-east">SE</li>
|
||||
|
|
@ -530,13 +566,14 @@ styles = ["page/tairu.css"]
|
|||
<li class="north">N</li>
|
||||
<li class="north-east"><a href="https://github.com/NoiseStudio/NoiseEngine/" title="NoiseEngine????">NE</a></li>
|
||||
</ul>
|
||||
```
|
||||
|
||||
% id = "01HQ1K39ASFN94YDY1RWQYS12K"
|
||||
- at this point with the four extra corners we'll need 8 bits to represent our tiles, and that would make…
|
||||
|
||||
***256 tiles!?***
|
||||
_*256 tiles!?*_
|
||||
|
||||
nobody in their right mind would actually draw 256 separate tiles, right? ***RIGHT???***
|
||||
nobody in their right mind would actually draw 256 separate tiles, right? _*RIGHT???*_
|
||||
|
||||
% template = true
|
||||
id = "01HQ1K39AS11M1M4GQQ60NXTY6"
|
||||
|
|
@ -544,7 +581,8 @@ styles = ["page/tairu.css"]
|
|||
if we arrange the tiles in a diagnonal cross like this, notice how the tile in the center would have the bits `SE | SW | NW | NE` set, which upon first glance would suggest us needing a different tile -
|
||||
but it looks correct!
|
||||
|
||||
```javascript tairu
|
||||
{:program=tairu}
|
||||
```javascript
|
||||
import { Tilemap } from "tairu/tilemap.js";
|
||||
|
||||
new TilesetTileEditor({
|
||||
|
|
@ -559,29 +597,35 @@ styles = ["page/tairu.css"]
|
|||
tilesets: [heavyMetalTileset],
|
||||
});
|
||||
```
|
||||
```output tairu 01HQ4A01MPE6JT5ZZFEN9S635W
|
||||
|
||||
{:program=tairu :placeholder=01HQ4A01MPE6JT5ZZFEN9S635W}
|
||||
```output
|
||||
```
|
||||
|
||||
% id = "01HQ1K39AS7CRBZ67N1VVHCVME"
|
||||
- therefore there must be *some* bit combinations that are redundant to others. let's find them!
|
||||
- therefore there must be _some_ bit combinations that are redundant to others. let's find them!
|
||||
|
||||
% classes.branch = "tileset-four-to-eight-demo"
|
||||
id = "01HQ1K39ASZPJ4E23EZ1XJ5J7K"
|
||||
- let's pick one corner first, then generalize to all the other ones. I pick southeast!
|
||||
|
||||
``` =html
|
||||
<ul class="directions-square e-s">
|
||||
<li class="east">E</li>
|
||||
<li class="south-east">SE</li>
|
||||
<li class="south">S</li>
|
||||
</ul>
|
||||
```
|
||||
|
||||
% id = "01HQ1K39ASQTR054W0VWEAV2FS"
|
||||
- in this case, if we remove the tile to the southeast, we get that bent tile from before:
|
||||
|
||||
``` =html
|
||||
<ul class="directions-square bend">
|
||||
<li class="east">E</li>
|
||||
<li class="south">S</li>
|
||||
</ul>
|
||||
```
|
||||
|
||||
% id = "01HQ1K39AS6RGE6Z83T8MH1R0M"
|
||||
- what we can learn from this is that for `E | S`, `ES` affects the result!
|
||||
|
|
@ -589,6 +633,7 @@ styles = ["page/tairu.css"]
|
|||
% id = "01HQ1K39ASVSAQ6F8ANEZE1WQ4"
|
||||
- but if we add any other corner, nothing changes. heck, let's add all of them:
|
||||
|
||||
``` =html
|
||||
<ul class="directions-square e-s">
|
||||
<li class="east">E</li>
|
||||
<li class="south-east">SE</li>
|
||||
|
|
@ -597,6 +642,7 @@ styles = ["page/tairu.css"]
|
|||
<li class="north-west">NW</li>
|
||||
<li class="north-east">NE</li>
|
||||
</ul>
|
||||
```
|
||||
|
||||
% id = "01HQ1K39AST8RQTVSCDV7FSH62"
|
||||
- this combination is definitely redundant!
|
||||
|
|
@ -612,7 +658,8 @@ styles = ["page/tairu.css"]
|
|||
+ we'll start off by redefining our bits to be ordinal directions instead. I still want to keep the [nice orderliness][branch:01HQ162WWAM5YYQCEXH791T0E9] that comes with
|
||||
arranging the bits clockwise starting from east, so if we want that we can't just extend the indices with an extra four bits at the top.
|
||||
|
||||
```javascript tairu
|
||||
{:program=tairu}
|
||||
```javascript
|
||||
export const E = 0b0000_0001;
|
||||
export const SE = 0b0000_0010;
|
||||
export const S = 0b0000_0100;
|
||||
|
|
@ -626,7 +673,8 @@ styles = ["page/tairu.css"]
|
|||
% id = "01HPSY4Y19HPNXC54VP6TFFHXN"
|
||||
- I don't know about you, but I find the usual C-style way of checking whether a bit is set extremely hard to read, so let's take care of that:
|
||||
|
||||
```javascript tairu
|
||||
{:program=tairu}
|
||||
```javascript
|
||||
export function isSet(integer, bit) {
|
||||
return (integer & bit) == bit;
|
||||
}
|
||||
|
|
@ -636,7 +684,8 @@ styles = ["page/tairu.css"]
|
|||
- now we can write a function that will remove the aforementioned redundancies.
|
||||
the logic is quite simple - for southeast, we only allow it to be set if both south and east are also set, and so on and so forth.
|
||||
|
||||
```javascript tairu
|
||||
{:program=tairu}
|
||||
```javascript
|
||||
// t is an existing tile index; variable name is short for brevity
|
||||
export function removeRedundancies(t) {
|
||||
if (isSet(t, SE) && (!isSet(t, S) || !isSet(t, E))) {
|
||||
|
|
@ -658,7 +707,8 @@ styles = ["page/tairu.css"]
|
|||
% id = "01HPSY4Y19HWQQ9XBW1DDGW68T"
|
||||
- with that, we can find a set of all unique non-redundant combinations:
|
||||
|
||||
```javascript tairu
|
||||
{:program=tairu}
|
||||
```javascript
|
||||
export function ordinalDirections() {
|
||||
let unique = new Set();
|
||||
for (let i = 0; i <= 0b1111_1111; ++i) {
|
||||
|
|
@ -669,20 +719,22 @@ styles = ["page/tairu.css"]
|
|||
```
|
||||
|
||||
% id = "01HPSY4Y19KG8DC4SYXR1DJJ5F"
|
||||
- by the way, I find it quite funny how JavaScript's [`Array.prototype.sort`] defaults to ASCII ordering *for all types.*
|
||||
- by the way, I find it quite funny how JavaScript's [`Array.prototype.sort`][sort] defaults to ASCII ordering _for all types._
|
||||
even numbers! ain't that silly?
|
||||
|
||||
[`Array.prototype.sort`]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort
|
||||
[sort]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort
|
||||
|
||||
% id = "01HPSY4Y19V62YKTGK3TTKEB38"
|
||||
- and with all the ingredients in the pot, we now _Let It Cook™_:
|
||||
|
||||
```javascript tairu
|
||||
{:program=tairu}
|
||||
```javascript
|
||||
let dirs = ordinalDirections();
|
||||
console.log(dirs.length);
|
||||
```
|
||||
|
||||
```output tairu
|
||||
{:program=tairu}
|
||||
```output
|
||||
47
|
||||
```
|
||||
|
||||
|
|
@ -690,7 +742,7 @@ styles = ["page/tairu.css"]
|
|||
- forty seven! that's how many unique tiles we actually need.
|
||||
|
||||
% id = "01HPSY4Y19C303Z595KNVXYYVS"
|
||||
- you may find pixel art tutorials saying you need forty *eight* and not forty *seven*, but that is not quite correct -
|
||||
- you may find pixel art tutorials saying you need forty _eight_ and not forty _seven_, but that is not quite correct -
|
||||
the forty eighth tile is actually just the empty tile! saying it's part of the tileset is quite misleading IMO.
|
||||
|
||||
% id = "01HPSY4Y19TM2K2WN06HHEM3D0"
|
||||
|
|
@ -707,13 +759,13 @@ styles = ["page/tairu.css"]
|
|||
- so we only need to draw 47 tiles, but to actually display them in a game we still need to pack them into an image.
|
||||
|
||||
% id = "01HPWJB4Y0QX6YR6TQKZ7T1C2E"
|
||||
- we *could* use a similar approach to the 16 tile version, but that would leave us with lots of wasted space!
|
||||
- we _could_ use a similar approach to the 16 tile version, but that would leave us with lots of wasted space!
|
||||
|
||||
% id = "01HPWJB4Y0HKGSDABB56CNFP9H"
|
||||
- think that with this redundancy elimination approach most of the tiles will never even be looked up by the renderer, because the bit combinations will be collapsed into a more canonical form before the lookup.
|
||||
|
||||
% id = "01HQ1K39ASM53P1E74HKRZ1T24"
|
||||
- so instead of wasting space, we can compress the tiles into a compact strip, and use a lookup table from sparse tile indices to dense tile *positions* within the strip.
|
||||
- so instead of wasting space, we can compress the tiles into a compact strip, and use a lookup table from sparse tile indices to dense tile _positions_ within the strip.
|
||||
|
||||
% id = "01HPWJB4Y0F9JGXQDAAVC3ERG1"
|
||||
- I don't want to write the lookup table by hand, so let's generate it!
|
||||
|
|
@ -721,7 +773,8 @@ styles = ["page/tairu.css"]
|
|||
% id = "01HPWJB4Y0HTV32T4WMKCKWTVA"
|
||||
- we'll start by obtaining our ordinal directions array again:
|
||||
|
||||
```javascript tairu
|
||||
{:program=tairu}
|
||||
```javascript
|
||||
export let xToConnectionBitSet = ordinalDirections();
|
||||
```
|
||||
|
||||
|
|
@ -730,7 +783,8 @@ styles = ["page/tairu.css"]
|
|||
|
||||
remember that our array has only 256 values, so it should be pretty cheap to represent using a [`Uint8Array`]:
|
||||
|
||||
```javascript tairu
|
||||
{:program=tairu}
|
||||
```javascript
|
||||
export let connectionBitSetToX = new Uint8Array(256);
|
||||
for (let i = 0; i < xToConnectionBitSet.length; ++i) {
|
||||
connectionBitSetToX[xToConnectionBitSet[i]] = i;
|
||||
|
|
@ -742,18 +796,22 @@ styles = ["page/tairu.css"]
|
|||
% id = "01HPWJB4Y0CWQB9EZG6C91A0H0"
|
||||
- and there we go! we now have a mapping from our bitset to positions within the tile strip. try to play around with the code example to see which bitsets correspond to which position!
|
||||
|
||||
```javascript tairu
|
||||
{:program=tairu}
|
||||
```javascript
|
||||
console.log(connectionBitSetToX[E | SE | S]);
|
||||
```
|
||||
```output tairu
|
||||
|
||||
{:program=tairu}
|
||||
```output
|
||||
4
|
||||
```
|
||||
|
||||
% id = "01HPWJB4Y09P9Q3NGN59XWX2X9"
|
||||
+ for my own (and your) convenience, here's a complete list of *all* the possible combinations in order.
|
||||
+ for my own (and your) convenience, here's a complete list of _all_ the possible combinations in order.
|
||||
|
||||
% id = "01HPWJB4Y01VJFMHYEC1WZ353W"
|
||||
- ```javascript tairu
|
||||
- {:program=tairu}
|
||||
```javascript
|
||||
function toString(bitset) {
|
||||
if (bitset == 0) return "0";
|
||||
|
||||
|
|
@ -773,7 +831,9 @@ styles = ["page/tairu.css"]
|
|||
console.log(`${x} => ${toString(xToConnectionBitSet[x])}`);
|
||||
}
|
||||
```
|
||||
```output tairu
|
||||
|
||||
{:program=tairu}
|
||||
```output
|
||||
0 => 0
|
||||
1 => E
|
||||
2 => S
|
||||
|
|
@ -836,7 +896,8 @@ styles = ["page/tairu.css"]
|
|||
% id = "01HQ1M84GS09M7PMXFYHDPRTMT"
|
||||
- since we already prepared the bulk of the framework before, it should be as simple as writing a new `tileIndex` function:
|
||||
|
||||
```javascript tairu
|
||||
{:program=tairu}
|
||||
```javascript
|
||||
export function tileIndexInBitwiseTileset47(tilemap, x, y) {
|
||||
let tile = tilemap.at(x, y);
|
||||
|
||||
|
|
@ -858,7 +919,8 @@ styles = ["page/tairu.css"]
|
|||
id = "01HQ1M84GS4C99VQZC4150CMDS"
|
||||
- now we can write a new tileset descriptor that uses this indexing function and the larger tile strip:
|
||||
|
||||
```javascript tairu
|
||||
{:program=tairu}
|
||||
```javascript
|
||||
// Once again, use your own link here!
|
||||
let tilesetImage = new Image();
|
||||
tilesetImage.src = "{% pic 01HPW47SHMSVAH7C0JR9HWXWCM %}";
|
||||
|
|
@ -873,7 +935,8 @@ styles = ["page/tairu.css"]
|
|||
% id = "01HQ1M84GS9CC8VR1BVDC15W50"
|
||||
- and Drum Roll 2: Return of the Snare please…
|
||||
|
||||
```javascript tairu
|
||||
{:program=tairu}
|
||||
```javascript
|
||||
import { Tilemap } from "tairu/tilemap.js";
|
||||
|
||||
new TilesetTileEditor({
|
||||
|
|
@ -888,14 +951,16 @@ styles = ["page/tairu.css"]
|
|||
tilesets: [heavyMetalTileset47],
|
||||
});
|
||||
```
|
||||
```output tairu 01HQ4A11RRXEQ850598GFBJN0B
|
||||
|
||||
{:program=tairu :placeholder=01HQ4A11RRXEQ850598GFBJN0B}
|
||||
```output
|
||||
```
|
||||
|
||||
% id = "01HQ1M84GSCXTPGVPXY840WCQ6"
|
||||
- it works perfectly!
|
||||
|
||||
% id = "01HQ1M84GSVBG9T94ZN9XTXX58"
|
||||
- but honestly, this is a bit *boring* if we're gonna build a game with procedural worlds.
|
||||
- but honestly, this is a bit _boring_ if we're gonna build a game with procedural worlds.
|
||||
|
||||
% id = "01HQ1M84GSH0KTFFZET6GZZ4V2"
|
||||
- heck, it's even boring for a level designer to have to lay out all the tiles manually -
|
||||
|
|
@ -907,7 +972,8 @@ styles = ["page/tairu.css"]
|
|||
% id = "01HQ1M84GS0KJ9NA6GPS62RC95"
|
||||
- for now, have a big editor to play around with. it's a lot of fun arranging the tiles in various shapes!
|
||||
|
||||
```javascript tairu
|
||||
{:program=tairu}
|
||||
```javascript
|
||||
import { Tilemap } from "tairu/tilemap.js";
|
||||
|
||||
new TilesetTileEditor({
|
||||
|
|
@ -916,7 +982,9 @@ new TilesetTileEditor({
|
|||
tilesets: [heavyMetalTileset47],
|
||||
});
|
||||
```
|
||||
```output tairu 01HQ4A45WNAEJGCT2WDMQJHK14
|
||||
|
||||
{:program=tairu :placeholder=01HQ4A45WNAEJGCT2WDMQJHK14}
|
||||
```output
|
||||
```
|
||||
|
||||
:nap: <!--
|
||||
|
|
@ -947,7 +1015,7 @@ You have been warned.
|
|||
- after a while I switched to a fork - [Lite XL](https://github.com/lite-xl/lite-xl), which had better font rendering and more features
|
||||
|
||||
% id = "01HPD4XQPWB11TZSX5VAAJ6TCD"
|
||||
- I stopped using it because VS Code was just more feature packed and usable; no need to reinvent the wheel, rust-analyzer *just works.*
|
||||
- I stopped using it because VS Code was just more feature packed and usable; no need to reinvent the wheel, rust-analyzer _just works._
|
||||
|
||||
% id = "01HPD4XQPW3G7BXTBBTD05MB8V"
|
||||
- the LSP plugin for Lite XL had some issues around autocompletions not filling in properly :pensive:
|
||||
|
|
@ -956,11 +1024,11 @@ You have been warned.
|
|||
while tinkering with your editor is something really cool, in my experience it's only cool up to a point.
|
||||
|
||||
% id = "01HPD4XQPWV1BAPA27SNDFR93B"
|
||||
- the cool thing with Tilekit is that it's *more* than just your average bitwise autotiling - of course it *can* do basic autotiling, but it can also do so much more
|
||||
- the cool thing with Tilekit is that it's _more_ than just your average bitwise autotiling - of course it _can_ do basic autotiling, but it can also do so much more
|
||||
|
||||
% id = "01HPD4XQPWM1JSAPXVT6NBHKYY"
|
||||
classes.branch_children = "branch-quote"
|
||||
- if I had to describe it, it's basically something of a *shader langauge for tilesets.* this makes it really powerful, as you can do little programs like
|
||||
- if I had to describe it, it's basically something of a _shader langauge for tilesets._ this makes it really powerful, as you can do little programs like
|
||||
|
||||
% id = "01HPD4XQPWE7ZVR0SS67DHTGHQ"
|
||||
- autotile using this base tileset
|
||||
|
|
|
|||
|
|
@ -12,6 +12,7 @@
|
|||
|
||||
% id = "01H9R1KJESJ0G0VQAW994ZHR0S"
|
||||
- take the following example:
|
||||
|
||||
```cpp
|
||||
class ComfyZone
|
||||
{
|
||||
|
|
@ -41,16 +42,16 @@
|
|||
- this can be _very_ hard to spot if you have a big class with lots of declarations inside.
|
||||
|
||||
% id = "01H9R1KJESCJ3VC8ATPYFDCPSP"
|
||||
- this can be worked around by banning access modifiers from appearing in `#ifdef`s, but you have to *realize* that this might happen
|
||||
- this can be worked around by banning access modifiers from appearing in `#ifdef`s, but you have to _realize_ that this might happen
|
||||
|
||||
% id = "01H9R1KJES4ZYHVADDF80WAXH6"
|
||||
- and I've seen instances of this exact thing occurring in the Unreal Engine codebase, which is *full* of long lists of declarations (made even longer by the prevalence of `UPROPERTY()` specifiers)
|
||||
- and I've seen instances of this exact thing occurring in the Unreal Engine codebase, which is _full_ of long lists of declarations (made even longer by the prevalence of `UPROPERTY()` specifiers)
|
||||
|
||||
% id = "01H9R1KJES182MCV2V0A4VHKKX"
|
||||
- even if we didn't have the preprocessor, that access modifier is state _you_ have to keep track of
|
||||
|
||||
% id = "01H9R1KJESH7PWNKCKW3H0WJHW"
|
||||
- I very often find myself needing to scroll upward after <kbd>Ctrl</kbd>-clicking on a field or function declaration, just to find out if I can use it
|
||||
- I very often find myself needing to scroll upward after `<kbd>Ctrl</kbd>`{=html}-clicking on a field or function declaration, just to find out if I can use it
|
||||
|
||||
% id = "01H9R1KJESFE6F1D4J5PA5Q381"
|
||||
- (thankfully IDEs are helpful here and Rider shows you a symbol's visibility in the tooltip on hover, but I don't have Rider on code reviews)
|
||||
|
|
|
|||
|
|
@ -5,6 +5,7 @@
|
|||
|
||||
% id = "01J0VN48B2Z5BFFEZCEYG63662"
|
||||
- obviously the simplest way would be to just use the C library.
|
||||
|
||||
```cpp
|
||||
int main(void)
|
||||
{
|
||||
|
|
@ -35,7 +36,7 @@
|
|||
- this approach has the nice advantage of being really simple, but it doesn't work well if you build your codebase on RAII.
|
||||
|
||||
% id = "01J0VN48B2CT2DVHEB1HGK8KB7"
|
||||
- and as much as I disagree with using it *everywhere* and injecting object-oriented design into everything, RAII is actually really useful for OS resources such as an `SDL_Window*`.
|
||||
- and as much as I disagree with using it _everywhere_ and injecting object-oriented design into everything, RAII is actually really useful for OS resources such as an `SDL_Window*`.
|
||||
|
||||
% id = "01J0VN48B2SX6GX0B3AKDVHGFX"
|
||||
- to make use of RAII you might be tempted to wrap your `SDL_Window*` in a class with a destructor…
|
||||
|
|
@ -81,6 +82,7 @@ struct window
|
|||
|
||||
% id = "01J0VN48B2E1X2G415P1TNG4CJ"
|
||||
- copying windows doesn't really make sense, so we can delete the copy constructor and copy assignment operator…
|
||||
|
||||
```cpp
|
||||
struct window
|
||||
{
|
||||
|
|
@ -99,6 +101,7 @@ struct window
|
|||
|
||||
% id = "01J0VN48B2AAD3SKFWNDMYV4FV"
|
||||
- so we'll also want an explicit move constructor and a move assignment operator:
|
||||
|
||||
```cpp
|
||||
struct window
|
||||
{
|
||||
|
|
@ -129,6 +132,7 @@ struct window
|
|||
|
||||
% id = "01J0VN48B2TFMXQRPPKJXEEX2E"
|
||||
- with all of this combined, our final `window` class looks like this:
|
||||
|
||||
```cpp
|
||||
struct window
|
||||
{
|
||||
|
|
@ -205,10 +209,12 @@ struct window
|
|||
|
||||
% id = "01J0VN48B2WZ9PAX0W5W2ZMPPN"
|
||||
- albeit I'll admit that writing
|
||||
|
||||
```cpp
|
||||
int width;
|
||||
SDL_GetWindowSize(&window, &width, nullptr);
|
||||
```
|
||||
|
||||
just to obtain the window width does _not_ spark joy.
|
||||
|
||||
% id = "01J0VN48B2DCN9PPHHC818NPMD"
|
||||
|
|
@ -246,6 +252,7 @@ this is what _smart pointers_ are for after all - our good friends `std::shared_
|
|||
% id = "01J0VN48B2NBTZ62YDNKMDN1CC"
|
||||
- to set a custom deleter for an `std::shared_ptr`, we provide it as the 2nd argument of the constructor.
|
||||
so to automatically free our `SDL_Window` pointer, we would do this:
|
||||
|
||||
```cpp
|
||||
int main(void)
|
||||
{
|
||||
|
|
@ -272,6 +279,7 @@ this is what _smart pointers_ are for after all - our good friends `std::shared_
|
|||
}
|
||||
}
|
||||
```
|
||||
|
||||
and that's all there is to it!
|
||||
|
||||
% id = "01J0VN48B2WHNDKVBSDJRTYG4T"
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ scripts = [
|
|||
]
|
||||
|
||||
% id = "01J291S06DS12DCFTNKJ27BNSQ"
|
||||
- *ooh I'm sure this one is gonna be really controversial but here I go*
|
||||
- _ooh I'm sure this one is gonna be really controversial but here I go_
|
||||
|
||||
% id = "01J291S06DRH9SP8K1QE03JVK8"
|
||||
- time and time again I've heard from people just how horrible JavaScript is, but I beg to differ.
|
||||
|
|
@ -31,15 +31,19 @@ you already have it on your computer.
|
|||
|
||||
% id = "01J2931RRHFPEH3D5MWEKGXGAE"
|
||||
- don't believe me? let me show you:
|
||||
```javascript i-am-showing-you-right-now
|
||||
|
||||
{:program=i-am-showing-you-right-now}
|
||||
```javascript
|
||||
console.log("see?") // and if you have JavaScript enabled, you can edit this!
|
||||
```
|
||||
```output i-am-showing-you-right-now
|
||||
|
||||
{:program=i-am-showing-you-right-now}
|
||||
```output
|
||||
see?
|
||||
```
|
||||
|
||||
% id = "01J2931RRHDZ979VTF2SN3J9CB"
|
||||
- and this goes for pretty much every modern personal computing device on the planet nowadays - *you can already run JavaScript on it.*
|
||||
- and this goes for pretty much every modern personal computing device on the planet nowadays - _you can already run JavaScript on it._
|
||||
|
||||
% id = "01J2931RRHEMZY9M5W3EG666YK"
|
||||
- sure it may not be the cleanest language in terms of design, but JavaScript running anywhere and everywhere is its superpower.
|
||||
|
|
@ -48,7 +52,7 @@ you already have it on your computer.
|
|||
- JavaScript being available on everyone's computers makes it a super-accessible programming language to learn: all you have to do is open your web browser and go to the console in its Developer Tools.
|
||||
|
||||
% id = "01J2931RRH51K35C80Z2NHSVRW"
|
||||
- moreso, if you are building a website and would like to embed a language interpreter (like me,) *you already have JavaScript for that.*
|
||||
- moreso, if you are building a website and would like to embed a language interpreter (like me,) _you already have JavaScript for that._
|
||||
|
||||
% id = "01J2931RRH65HHY6BQ7N0P9MX9"
|
||||
- yes, you could in theory embed [Lua][page:programming/languages/lua], but for most cases JavaScript is Already There and there is nothing wrong with it.
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@
|
|||
but the designers of Lua had the restraint to just have One.
|
||||
|
||||
% id = "01HRG2RJC13YK030EPGMKM9H8H"
|
||||
- tables are extremely powerful in what they can do, because they're more than just a way of structuring data - they also allow for interfacing with the language *syntax* through operator overloading
|
||||
- tables are extremely powerful in what they can do, because they're more than just a way of structuring data - they also allow for interfacing with the language _syntax_ through operator overloading
|
||||
|
||||
% id = "01HRG2RJC1PDZFB2WBW7D827KF"
|
||||
+ in fact object oriented programming in Lua is typically done by overloading the `[]` indexing operator.
|
||||
|
|
@ -56,18 +56,18 @@
|
|||
local fallback = { b = 2 }
|
||||
local base = { a = 1 }
|
||||
|
||||
-- The __index field can be both a function *and* a table.
|
||||
-- The __index field can be both a function _and_ a table.
|
||||
-- { __index = the_table } is a shorthand for { __index = function (t, k) return the_table[k] end }
|
||||
setmetatable(base, { __index = fallback })
|
||||
assert(base.b == 2)
|
||||
```
|
||||
|
||||
% id = "01HRG2RJC23XH1053A69MQJD4N"
|
||||
- I'll be honest that I don't like the standard library of Lua from a usability standpoint, but maybe it *doesn't need to be bigger*.
|
||||
- I'll be honest that I don't like the standard library of Lua from a usability standpoint, but maybe it _doesn't need to be bigger_.
|
||||
it's similar to the principles of [Go](https://go.dev/), where the language encourages using dumb constructs rather than super clever code with lots of abstraction.
|
||||
|
||||
% id = "01HRG2RJC2P3832KTQMANBHGE6"
|
||||
- though unlike Go, Lua has the goal of being *small* because it needs to be *embeddable*, especially given it's used in very constrained environments in the real world. (microcontrollers!)
|
||||
- though unlike Go, Lua has the goal of being _small_ because it needs to be _embeddable_, especially given it's used in very constrained environments in the real world. (microcontrollers!)
|
||||
|
||||
% id = "01HRG2RJC2S3V38FM6DB0481WK"
|
||||
- therefore there are technical, not just ideological reasons to keep the library small.
|
||||
|
|
@ -76,10 +76,10 @@
|
|||
- and I really like that from an embedder's standpoint, it's possible to completely disable certain standard library modules for sandboxing!
|
||||
|
||||
% id = "01HRG2RJC2W4MK96FMWRTS8QCJ"
|
||||
- Lua also knows *very* well how much syntax sugar to have to make writing code pleasant, but not to overdose it so much as to give you instant diabetes.
|
||||
- Lua also knows _very_ well how much syntax sugar to have to make writing code pleasant, but not to overdose it so much as to give you instant diabetes.
|
||||
|
||||
% id = "01HRG2RJC28DT0TZT47WPABD65"
|
||||
+ as an example, there's function call syntax: you can pass it a string or table *literal*, which is just enough to enable some really nice DSLs without making the grammar too complex.
|
||||
+ as an example, there's function call syntax: you can pass it a string or table _literal_, which is just enough to enable some really nice DSLs without making the grammar too complex.
|
||||
|
||||
% id = "01HRG2RJC2CVKS9CFVQ9HJSBH4"
|
||||
- once upon a time I dreamed up a DSL for building GUIs using this sugar.
|
||||
|
|
@ -97,7 +97,7 @@
|
|||
```
|
||||
|
||||
% id = "01HRG2RJC2T7BF6XS3T7Q8AXW2"
|
||||
- ***JUST LOOK AT HOW CLEAN IT IS!*** with no need to [invent magic syntax](https://www.typescriptlang.org/docs/handbook/jsx.html) or anything!
|
||||
- _*JUST LOOK AT HOW CLEAN IT IS!*_ with no need to [invent magic syntax](https://www.typescriptlang.org/docs/handbook/jsx.html) or anything!
|
||||
|
||||
% id = "01HRG2RJC2D69JYCWQXSF2FQNY"
|
||||
- the only missing thing then would be list comprehensions to be able to transform data into GUI elements, but even that can be ironed over using function literals:
|
||||
|
|
@ -122,7 +122,7 @@
|
|||
}
|
||||
```
|
||||
|
||||
interpret this code however you want, but *damn* it looks clean. again with no magic syntax!
|
||||
interpret this code however you want, but _damn_ it looks clean. again with no magic syntax!
|
||||
|
||||
% id = "01HRG2RJC2PA5KE0DH0RRFGW9E"
|
||||
- there is also the incredibly useful sugar for indexing tables by string literals: instead of `table["x"]` you can write down `table.x`
|
||||
|
|
@ -136,10 +136,10 @@
|
|||
the parameter is explicit, there is just sugar for passing it into functions and declaring functions with it.
|
||||
|
||||
% id = "01HRG2RJC2FF05JWQ6KHS4Y5WF"
|
||||
- I really wish Lua had at least *a* form of static typing though, since knowing about errors you make early is _really_ helpful during development.
|
||||
- I really wish Lua had at least _a_ form of static typing though, since knowing about errors you make early is _really_ helpful during development.
|
||||
|
||||
% id = "01HRG2RJC2JP3HRTVMAQ22HDVE"
|
||||
+ it regularly happened to me that a type error I made only occured at *some point* later during runtime; and then you have to track down a reproduction case and make a fix at the source. not fun.
|
||||
+ it regularly happened to me that a type error I made only occured at _some point_ later during runtime; and then you have to track down a reproduction case and make a fix at the source. not fun.
|
||||
|
||||
% id = "01HRG3MJ0KGZ8T4KHMV6KZXDK4"
|
||||
- there's also the ugly case I had with a division by zero in the last rewrite of [Planet Overgamma][def:planet_overgamma/repo], which caused a NaN to propagate through physics and into rendering, causing a crash.
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@
|
|||
- you say `info` sounds wrong for debug info? well,
|
||||
|
||||
% id = "01HBTSXTTATA4GW13QBC8YMWP1"
|
||||
- guess what, it's debug ***info***
|
||||
- guess what, it's debug _*info*_
|
||||
|
||||
% id = "01HBTSXTTANNMHXDGG1M4W70XN"
|
||||
- the very concept of logs is to dump a load of (debug) info for later analysis,
|
||||
|
|
@ -172,10 +172,10 @@
|
|||
- I'd rather have the program crash and burn at the point a `NaN` is produced rather than have to sift through all the math to find that one division by zero I didn't account for
|
||||
|
||||
% id = "01HPEMVAH9XG3RK62RFXD29RWV"
|
||||
- this does influence performance negatively, but it saves *so much* debugging pain and finding out which non deterministic scenario causes a NaN to propagate through the system
|
||||
- this does influence performance negatively, but it saves _so much_ debugging pain and finding out which non deterministic scenario causes a NaN to propagate through the system
|
||||
|
||||
% id = "01HPEMVAH9CKAEQBMC8S6MR0GQ"
|
||||
- worst case scenario you pull a Rust and disable those checks on release mode. that *does* work, but I don't like the idea of disabling numeric safety checks on release mode either.
|
||||
- worst case scenario you pull a Rust and disable those checks on release mode. that _does_ work, but I don't like the idea of disabling numeric safety checks on release mode either.
|
||||
|
||||
% id = "01HPEQ01JRMM17Y30BP7ZFKZRJ"
|
||||
+ :page: operator overloading is good, but getters and setters are not
|
||||
|
|
@ -184,10 +184,10 @@
|
|||
- this one stems from an argument I had today, so I'll write my thoughts for future generations' enjoyment here
|
||||
|
||||
% id = "01HPEQ01JR4YWC9Q6VYS82J0E3"
|
||||
- I'll start by prefacing that I think operator overloading is good [*iff*][def:word/iff] it's implemented in a way that a single operator has only one, well-defined meaning
|
||||
- I'll start by prefacing that I think operator overloading is good [_iff_][def:word/iff] it's implemented in a way that a single operator has only one, well-defined meaning
|
||||
|
||||
% id = "01HPEQ01JRBB8Z3P0KFJSR0SJN"
|
||||
- this means `+` really means *addition* and nothing else.
|
||||
- this means `+` really means _addition_ and nothing else.
|
||||
|
||||
% id = "01HPEQ01JRJJBP9C701B36ZR4N"
|
||||
- this is practically impossible to enforce at a language level - what prevents the standard library authors from overloading `+` to mean string concatenation after all?
|
||||
|
|
@ -196,13 +196,14 @@
|
|||
- however we can at least do our best by writing good defaults and coding standards that gently suggest what to do and what not to do
|
||||
|
||||
% id = "01HPEQ01JR4ZC0M68818EDVDBF"
|
||||
- for example, allow users to define their own arbitrary operators that are explicitly *not* addition, to incentivize inventing new syntax for these things
|
||||
- for example, allow users to define their own arbitrary operators that are explicitly _not_ addition, to incentivize inventing new syntax for these things
|
||||
|
||||
% id = "01HPEQ01JRTWHH6PVNTFBDXPVT"
|
||||
- the way I'd like to do it in [my dream language][def:rokugo/repo] is by a few means
|
||||
|
||||
% id = "01HPEQ01JRAAK5MQCZ7CFZ75FA"
|
||||
- `(+)` is defined to be a polymorphic operator which calls into a module implementing the `AddSub` interface, which means you have to implement both addition *and* subtraction for `(+)` to work on your type
|
||||
- `(+)` is defined to be a polymorphic operator which calls into a module implementing the `AddSub` interface, which means you have to implement both addition _and_ subtraction for `(+)` to work on your type
|
||||
|
||||
```rokugo
|
||||
let AddSub = interface {
|
||||
type T
|
||||
|
|
@ -216,7 +217,7 @@
|
|||
```
|
||||
|
||||
% id = "01HPEQ01JR71RV53NNSFFDV6XN"
|
||||
- note how this operator *does not* have any effects declared on it - this means addition and subtraction must not have any side effects such as I/O
|
||||
- note how this operator _does not_ have any effects declared on it - this means addition and subtraction must not have any side effects such as I/O
|
||||
|
||||
% id = "01HPEQ01JRJR3ZAY24BP8TF5HH"
|
||||
+ the `(add AND subtract)` rule enforces types like strings to take a different operator, because `(-)` does not have a well-defined meaning on strings
|
||||
|
|
@ -234,7 +235,7 @@
|
|||
- so now getters and setters: what's so bad about them?
|
||||
|
||||
% id = "01HPEQ01JRQPZJEDDXV4BJN1GP"
|
||||
- the problem is that given the rule above - *one operator means one thing* - getters and setters completely destroy your assumptions about what `=` might do
|
||||
- the problem is that given the rule above - _one operator means one thing_ - getters and setters completely destroy your assumptions about what `=` might do
|
||||
|
||||
% id = "01HPEQ01JR0E8C0VJZ1D9TJRAG"
|
||||
- what's that? you didn't expect `camera.angle_z = 420` to throw because 420 is out of the `[-π/2, π/2]` range? oops!
|
||||
|
|
@ -250,13 +251,16 @@
|
|||
|
||||
% id = "01HPEQ01JRQFSFVPQA41MFZ91T"
|
||||
- this is less of a problem in languages that feature automatic generation of getters and setters - such as Kotlin
|
||||
|
||||
```kotlin
|
||||
var someVariable: String
|
||||
get
|
||||
private set
|
||||
// no infinite recursion to be seen here!
|
||||
```
|
||||
but it's still an issue in eg. JavaScript, where one mistake can send your call stack down the spiral:
|
||||
|
||||
but it's still an issue in e.g. JavaScript, where one mistake can send your call stack down the spiral:
|
||||
|
||||
```javascript
|
||||
class Example {
|
||||
#someVariable = "";
|
||||
|
|
@ -265,6 +269,7 @@
|
|||
set someVariable(value) { this.someVariable = value; } // typo again!!!!!!!!!! dammit!
|
||||
}
|
||||
```
|
||||
|
||||
and the error is not caught until runtime.
|
||||
|
||||
% id = "01HPEQ01JRMMS1B400DP6DV5M9"
|
||||
|
|
|
|||
|
|
@ -1,19 +1,23 @@
|
|||
% id = "programming/projects/stitchkit"
|
||||
content.link = "programming/projects/stitchkit"
|
||||
+ ### Stitchkit
|
||||
|
||||
A Hat in Time mod stitching toolkit
|
||||
|
||||
% id = "programming/projects/muscript"
|
||||
content.link = "programming/projects/muscript"
|
||||
+ ### MuScript
|
||||
|
||||
UnrealScript compiler, part of stitchkit
|
||||
|
||||
% id = "programming/projects/yarnbox"
|
||||
content.link = "programming/projects/yarnbox"
|
||||
+ ### Yarnbox
|
||||
|
||||
A Hat in Time bytecode injection mod loader
|
||||
|
||||
% id = "programming/projects/shelter"
|
||||
content.link = "programming/projects/shelter"
|
||||
+ ### shelter
|
||||
|
||||
ideas for an operating system; not actually implemented
|
||||
|
|
|
|||
|
|
@ -78,7 +78,7 @@
|
|||
+ parallelization with an event loop
|
||||
|
||||
% id = "01HA0GPJ8B48K60BWQ2XZZ0PB5"
|
||||
+ the thing with a pass-based architecture is that with enough locking, it *may* be easy to parallelize.
|
||||
+ the thing with a pass-based architecture is that with enough locking, it _may_ be easy to parallelize.
|
||||
|
||||
% id = "01HA0GPJ8B5QB6DF8YVTYC2HJY"
|
||||
+ I can imagine parallelization existing on many levels here.
|
||||
|
|
@ -131,7 +131,7 @@
|
|||
- because we're using a set, the computation is never duplicated; remember that if an answer has already been memoized, it does not spawn a task and instead returns the answer immediately
|
||||
|
||||
% id = "01HA0GPJ8B0V2VJMAV1YCQ19Q8"
|
||||
- though this may be hard to do with Rust because, as far as I know, there is no way to suspend a function conditionally? **(needs research.)**
|
||||
- though this may be hard to do with Rust because, as far as I know, there is no way to suspend a function conditionally? *(needs research.)*
|
||||
|
||||
% id = "01HA0GPJ8BBREEJCJRWPJJNR3N"
|
||||
- once there are no more tasks in the queue, we're done compiling
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ legacy of today's systems
|
|||
the project
|
||||
|
||||
% id = "01HFP3E77CVPJMQ69305QHRXDH"
|
||||
+ the design goal is to build a **secure operating system you can trust**
|
||||
+ the design goal is to build a *secure operating system you can trust*
|
||||
|
||||
% id = "01HFP3E77CFCF260WBQWTBNPP7"
|
||||
- gone will be the days where you download an executable from the Internet and have no idea
|
||||
|
|
@ -25,7 +25,7 @@ legacy of today's systems
|
|||
you have to inspect, the better
|
||||
|
||||
% id = "01HFP3E77CGBD4ZQ2JN4Z761VE"
|
||||
+ **NOTE:** at this point shelter is nothing more than an incomplete design. OS development is
|
||||
+ *NOTE:* at this point shelter is nothing more than an incomplete design. OS development is
|
||||
something I wanna get into but haven't enough time to research everything as of now, therefore
|
||||
I'm jotting down my ideas here
|
||||
|
||||
|
|
|
|||
|
|
@ -77,14 +77,14 @@
|
|||
- from my analyses when building [Yarnbox][branch:programming/projects/yarnbox], most chunks of bytecode don't exceed 4096 bytes
|
||||
|
||||
% id = "01HA4KNTTKW393XV8CPZSW2J7H"
|
||||
+ the engine loads your bytecode *mostly* verbatim, so we could include a recognizable signature at the end of every script
|
||||
+ the engine loads your bytecode _mostly_ verbatim, so we could include a recognizable signature at the end of every script
|
||||
|
||||
% id = "01HA4NZ9DADP5E842D1630NH19"
|
||||
- I imagine we could use a short string of bytes that's unlikely to collide with anything yet fast to search for. probably 16 bytes (128 bits) would be enough but we can experiment
|
||||
with less
|
||||
|
||||
% id = "01HA4NZ9DA4HADG7SFDTPKKJ11"
|
||||
- I say it loads your code *mostly* verbatim because it actually parses the bytecode to translate archive object indices to
|
||||
- I say it loads your code _mostly_ verbatim because it actually parses the bytecode to translate archive object indices to
|
||||
|
||||
% id = "01HA4NZ9DAW2KEDX62E810PA03"
|
||||
- since we can't reallocate memory, we'll have to always preallocate all 65536 bytes - but 64 KiB isn't that much in the first place,
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
- I don't have UE installed on my home computer yet, so you'll have to take my word for a lot of these things
|
||||
|
||||
% id = "01H8Y0CKD1VENHWERX7CTGCE6M"
|
||||
- anyways back to your regularly scheduled bullet points, *\*ahem\**
|
||||
- anyways back to your regularly scheduled bullet points, _\*ahem\*_
|
||||
|
||||
% id = "01H8Y0CKD1QHMTGFCK2RC3NPDV"
|
||||
+ Blueprint, _my arch nemesis!_
|
||||
|
|
@ -171,7 +171,7 @@ flow and introduces control flow into the mix
|
|||
+ which is a portmanteau of Blueprint and spaghetti.
|
||||
|
||||
% id = "01H8Y427B0PJN75GA33S9CZJYH"
|
||||
- I can't believe I remembered the spelling of that word. *portmanteau*.
|
||||
- I can't believe I remembered the spelling of that word. _portmanteau_.
|
||||
|
||||
% id = "01H8YT7R15B3Z3T486DB53TR51"
|
||||
- there are plugins on the marketplace that solve this, but I refuse to believe Epic Games doesn't have this problem themselves
|
||||
|
|
@ -199,7 +199,7 @@ flow and introduces control flow into the mix
|
|||
- the biggest offender here being that hard references are the default
|
||||
|
||||
% id = "01H8Y427B17K7219TPH8VRFZ96"
|
||||
- thus you can add a Mesh Component to your Blueprint and it'll load *the entire mesh with all the textures and skeleton and everything* when you wanna tweak a variable or some logic in the event graph
|
||||
- thus you can add a Mesh Component to your Blueprint and it'll load _the entire mesh with all the textures and skeleton and everything_ when you wanna tweak a variable or some logic in the event graph
|
||||
|
||||
% id = "01H8Y427B1QNZHJ5Z8W0QNFYPE"
|
||||
- and not asynchronously in the background, you will have to _wait_ for it to finish loading. which is pretty annoying
|
||||
|
|
|
|||
|
|
@ -21,6 +21,7 @@
|
|||
|
||||
% id = "01HP1FESY38JWXNSJKPZNHP33Q"
|
||||
+ the interface you have to implement is:
|
||||
|
||||
```cpp
|
||||
struct IFixer
|
||||
{
|
||||
|
|
@ -64,6 +65,7 @@
|
|||
|
||||
% id = "01HP1FESY30HDA6JNR323GXD3D"
|
||||
- minimal example:
|
||||
|
||||
```cpp
|
||||
auto Message = FTokenizedMessage::Create(
|
||||
EMessageVerbosity::Error,
|
||||
|
|
|
|||
|
|
@ -23,11 +23,13 @@
|
|||
|
||||
% id = "01HV1DGFHMDFMWY2FWRHN3NGAX"
|
||||
- the thing is - it doesn't. `GENERATED_BODY()` by itself is incredibly stupid:
|
||||
|
||||
```cpp
|
||||
#define BODY_MACRO_COMBINE_INNER(A,B,C,D) A##B##C##D
|
||||
#define BODY_MACRO_COMBINE(A,B,C,D) BODY_MACRO_COMBINE_INNER(A,B,C,D)
|
||||
#define GENERATED_BODY(...) BODY_MACRO_COMBINE(CURRENT_FILE_ID,_,__LINE__,_GENERATED_BODY);
|
||||
```
|
||||
|
||||
let's disassemble it piece by piece.
|
||||
|
||||
% id = "01HV1DGFHM4BW1FXVX3AMJYR91"
|
||||
|
|
@ -44,13 +46,17 @@ let's disassemble it piece by piece.
|
|||
% id = "01HV1DGFHM6XQ68XJPART8TND3"
|
||||
- the actual form it seems to take is `FID_{Path}` with `{Path}` being the file path relative to the project root directory, with slashes and dots replaced with underscores.
|
||||
for:
|
||||
|
||||
```
|
||||
Engine/Source/Runtime/Engine/Classes/Engine/Blueprint.h
|
||||
```
|
||||
|
||||
the file ID is:
|
||||
|
||||
```
|
||||
FID_Engine_Source_Runtime_Engine_Classes_Engine_Blueprint_h
|
||||
```
|
||||
|
||||
I haven't inspected the UnrealBuildTool/UnrealHeaderTool sources though, so there may be more to it.
|
||||
|
||||
% id = "01HV1DGFHMVS11W47KWXJC7TY4"
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue