Update

cracker.md

@@ -2,4 +2,4 @@
 
 Crackers are the good people who in computer systems, with use of [hacking](hacking.md), remove artificial barriers to obtaining and sharing of [infomration](information.md); for example they help remove [DRM](drm.md) from [games](game.md) or leak data from secret databases. This is normally illegal which makes the effort even more admirable.
 
-Cracker is also a yummy food.
+Cracker is also food.

jokes.md

@@ -23,6 +23,7 @@ Please do NOT post lame "big-bang-theory" jokes like *sudo make sandwich* or *th
 - How to install a package on [Debian](debian.md)? I don't know, but on my [Arch](arch.md) it's done with `pacman`.
 - Difference between a beginner and pro programmer? Pro programmer fails in a much more sophisticated manner.
 - What's a [computer](computer.md)? A device that can make a hundred million mistakes per second.
+- Boss: "We're going to need to store additional information about gender of all 1600 people in our database." Me: "OK that's only 200 extra bytes.". Diversity department: "You're fired."
 
 ## See Also
 

main.md

@@ -60,6 +60,7 @@ Some more specialized topics you may want to check out are:
 
 And if you just want something more obscure and [fun](fun.md), check out these:
 
+- [jokes](jokes.md)
 - [esoteric programming languages](esolang.md)
 - [open consoles](open_console.md)
 - [brain software](brain_software.md)

pedophilia.md

@@ -2,7 +2,7 @@
 
 { [Rape](rape.md) of anyone is bad as is any violence against any living being. That's it. Any thought, desire or perception of any information must however never be considered wrong in itself. ~drummyfish }
 
-Pedophilia is a sexual orientation towards children, nowadays wrongfully labeled an illness just as e.g. homosexuality used to be labelled an illness. It is the forbidden sexual orientation of our age, even though all healthy people are pedophiles (just don't pretend you've never seen a [jailbait](jailbait.md) you found sexy), even though one cannot choose this orientation and even though pedophiles don't hurt anyone any more than for example gay people do, they are highly oppressed and tortured. Despite what the propaganda says, a pedophile is not automatically a rapist of children any more than a gay person is automatically a rapist of people of the same gender, and watching child porn won't make you want to rape children more than watching gay porn will make you want to rape people of the same gender. Nevertheless the society, especially the fascists from the [LGBT](lgbt.md) movement who ought to know more than anyone else what it is like to be oppressed only because of private sexual desires, actively hunt pedophiles, [bully](cancel_culture.md) them and lynch them on the internet and in the real life by both civilians and state (I shit you not, in [Murica](usa.md) there are whole police teams of pink haired lesbians who pretend to be little girls on the internet and tease guys so that they can lock them up and get a medal for it). There is a literal witch hunt going on against completely innocent people, just like in the middle ages. Innocent people are tortured, castrated, cancelled, rid of their careers, imprisoned, beaten, rid of their friends and families and pushed to suicide sometimes only for having certain files on their computers (not that any of the above is ever justified to do to anyone, even the worst criminal).
+Pedophilia is a sexual orientation towards children, nowadays wrongfully labeled a "disorder" just as e.g. homosexuality used to be labelled an illness. It is the forbidden sexual orientation of our age, even though all healthy people are pedophiles (just don't pretend you've never seen a [jailbait](jailbait.md) you found sexy), even though one cannot choose this orientation and even though pedophiles don't hurt anyone any more than for example gay people do, they are highly oppressed and tortured. Despite what the propaganda says, a pedophile is not automatically a rapist of children any more than a gay person is automatically a rapist of people of the same gender, and watching child porn won't make you want to rape children more than watching gay porn will make you want to rape people of the same gender. Nevertheless the society, especially the fascists from the [LGBT](lgbt.md) movement who ought to know better than anyone else what it is like to be oppressed only because of private sexual desires, actively hunt pedophiles, [bully](cancel_culture.md) them and lynch them on the internet and in the real life by both civilians and state (I shit you not, in [Murica](usa.md) there are whole police teams of pink haired lesbians who pretend to be little girls on the internet and tease guys so that they can lock them up and get a medal for it). There is a literal witch hunt going on against completely innocent people, just like in the middle ages. Innocent people are tortured, castrated, cancelled, rid of their careers, imprisoned, beaten, rid of their friends and families and pushed to suicide sometimes only for having certain files on their computers (not that any of the above is ever justified to do to anyone, even the worst criminal).
 
 The pedophile witch hunt exists because it's a great political tool. It is an arbitrarily invented victimless crime. By the principles of [fear culture](fear_culture.md), it allows to push things such as hard surveillance, similarly to e.g. "war on terror". You're a government or a corporation and want to spy on people chatting? Just make a law requiring mandatory [spyware](spyware.md) in all chat and justify it by "pedophiles" (this is what [EU](eu.md) did). You're against the surveillance law? You must be a pedophile! The witch hunt also allows to immediately cancel anyone uncomfortable. There's a guy who the government doesn't like? Maybe a political competition. Simple, just plant some files on his computer, make up a little story and they're gone.
 

sw_rendering.md

@@ -2,9 +2,9 @@
 
 Sofware (SW) rendering refers to [rendering](rendering.md) [computer graphics](graphics.md) without the help of [graphics card](gpu.md) (GPU), i.e. computing images only with [CPU](cpu.md). This mostly means rendering [3D](3d.md) graphics but can also refer to other kinds of graphics such as drawing [fonts](font.md) or [video](video.md). Before GPUs were invented, all rendering was done in software, of course -- games such as [Quake](quake.md) were designed with SW rendering and only added possible GPU acceleration later. SW rendering for traditional 3D graphics is also called software [rasterization](rasterization.md).
 
-SW rendering has advantages and disadvantages. Firstly it is **much slower** -- GPUs are designed to perform graphics-specific operations very quickly and, more importantly, they can process many pixels (and other elements) in [parallel](parallelism.md), while a CPU has to compute pixels sequentially one by one and that in addition to all other computations it is otherwise performing. This causes a much lower [FPS](fps.md) in SW rendering. For this reasons SW rendering is also normally of **lower quality** (lower resolution, [nearest neighbour](nn.md) texture filtering, ...) to allow at least somewhat workable FPS.
+SW rendering has advantages and disadvantages. Firstly it is **much slower** -- GPUs are designed to perform graphics-specific operations very quickly and, more importantly, they can process many pixels (and other elements) in [parallel](parallelism.md), while a CPU has to compute pixels sequentially one by one and that in addition to all other computations it is otherwise performing. This causes a much lower [FPS](fps.md) in SW rendering. For this reasons SW rendering is also normally of **lower quality** (lower resolution, [nearest neighbour](nn.md) texture filtering, ...) to allow workable FPS. Nevertheless thanks to the ginormous speeds of today's CPUs simple fullscreen SW rendering can be pretty fast on PCs and achieve even above 60 FPS; on slower CPUs (typically [embedded](embedded.md)) SW rendering is usable normally at around 30 FPS if resolutions are kept small.
 
-On the other hand SW rendering is more [portable](portability.md) (as it can be written in a portable language such as [C](c.md)), less [bloated](bloat.md) and **eliminates the [dependency](dependency.md) on GPU** so it will be supported almost anywhere as every computer has a CPU, while not all computers (such as [embedded](embedded.md) devices) have a GPU (or, if they have it, it may not be sufficient, supported or have a required [driver](driver.md)). SW rendering may also be implemented in a simpler way and it may be easier to deal with as there is e.g. no need to write [shaders](shader.md) in a special language, manage transfer of data between CPU and GPU or deal with parallel programming. It is the [KISS](kiss.md) approach.
+On the other hand SW rendering is more [portable](portability.md) (as it can be written purely in a portable language such as [C](c.md)), less [bloated](bloat.md) and **eliminates the [dependency](dependency.md) on GPU** so it will be supported almost anywhere as every computer has a CPU, while not all computers (such as [embedded](embedded.md) devices) have a GPU (or, if they have it, it may not be sufficient, supported or have a required [driver](driver.md)). SW rendering may also be implemented in a simpler way and it may be easier to deal with as there is e.g. no need to write [shaders](shader.md) in a special language, manage transfer of data between CPU and GPU or deal with parallel programming. SW rendering is the [KISS](kiss.md) approach.
 
 SW rendering may also utilize a much wider variety of rendering techniques than only 3D [rasterization](rasterization.md) traditionally used with [GPUs](gpu.md) and their [APIs](api.md), thanks to not being limited by hard-wired pipelines. This may include [splatting](splatting.md), [raytracing](raytracing.md) or [BSP rendering](bsp.md) (and many other ["pseudo 3D"](pseudo3d.md) techniques).
 
@@ -18,7 +18,7 @@ Note that SW rendering doesn't mean our program is never touching [GPU](gpu.md)
 
 Some SW renderers make use of specialized CPU instructions such as [MMX](mmx.md) which can make SW rendering faster thanks to handling multiple data in a single step. This is kind of a mid way: it is not using a GPU per se but only a mild form of hardware acceleration. The speed won't reach that of a GPU but will outperform a "pure" SW renderer. However the disadvantage of a hardware dependency is still present: the CPU has to support the MMX instruction set. Good renderers only use these instructions optionally and fall back to general implementation in case MMX is not supported.
 
-**Programming your own 3D software rasterizer** (in case [small3dlib](small3dlib.md) is somehow not enough for you): difficulty of this task depends on features you want -- a super simple [flat shaded](flat_shading.md) (no textures, no smooth shading) renderer is relatively easy to make, especially if you don't need movable camera, can afford to use [floating point](float.md) etc. The core of these renderers is the **[triangle](triangle.md) [rasterization](rasterization.md)** algorithm which, if you want, can be very simple -- even a naive one will give workable results -- or pretty complex and advanced, using various optimizations and things such as the [top-left rule](top_left_rule.md) to guarantee no holes and overlaps of triangles. Remember this function will likely be the performance [bottleneck](bottleneck.md) of your renderer so you want to put effort into [optimizing](optimization.md) it to achieve good [FPS](fps.md). Once you have triangle rasterization, you can draw 3D models which consist of vertices (points in 3D space) and triangles between these vertices (it's very simple to load simple 3D models e.g. from the [obj](obj.md) format) -- you simply project (using [perspective](perspective.md)) 3D position of each vertex to screen coordinates and draw triangles between these pixels with the rasterization algorithm. Here you need to also solve [visibility](visibility.md), i.e. possible overlap of triangles on the screen and correctly drawing those nearer the view in front of those that are further away -- a very simple solution is a [z buffer](z_buffer.md), but to save memory you can also e.g. [sort](sorting.md) the triangles by distance and draw them back-to-front ([painter's algorithm](painters_algorithm.md)). You may add a [scene](scene.md) data structure that can hold multiple models to be rendered. If you additionally want to have movable camera and models that can be transformed (moved, rotated, scaled, ...), you will additionally need to look into some [linear algebra](linear_algebra.md) and [transform matrices](transform_matrix.md) that allow to efficiently compute positions of vertices of a transformed model against a transformed camera -- you do this the same way as basically all other 3D engines (look up e.g. some [OpenGL](opengl.md) tutorials). If you also want texturing, the matter gets again a bit more complicated, you need to compute [barycentric](barycentric.md) coordinates (special coordinates within a triangle) as you're rasterizing the triangle, and possibly apply [perspective correction](perspective_correction.md) (otherwise you'll be seeing distortions). You then map the barycentrics of each rasterized pixel to [UV](uv.md) (texturing) coordinates which you use to retrieve specific pixels from a texture. On top of all this you may start adding all the advanced features of typical engines such as [acceleration structures](acceleration_structure.md) that for example discard models that are completely out of view, [LOD](lod.mf), instancing, [MIP maps](mip_map.md) and so on.
+**Programming your own 3D software rasterizer** (in case [small3dlib](small3dlib.md) is somehow not enough for you): difficulty of this task depends on features you want -- a super simple [flat shaded](flat_shading.md) (no textures, no smooth shading) renderer is relatively easy to make, especially if you don't need movable camera, can afford to use [floating point](float.md) etc. See the details of [3D rendering](3d_rendering.md), especially how the GPU pipelines work, and try to imitate them in software. The core of these renderers is the **[triangle](triangle.md) [rasterization](rasterization.md)** algorithm which, if you want, can be very simple -- even a naive one will give workable results -- or pretty complex and advanced, using various optimizations and things such as the [top-left rule](top_left_rule.md) to guarantee no holes and overlaps of triangles. Remember this function will likely be the performance [bottleneck](bottleneck.md) of your renderer so you want to put effort into [optimizing](optimization.md) it to achieve good [FPS](fps.md). Once you have triangle rasterization, you can draw 3D models which consist of vertices (points in 3D space) and triangles between these vertices (it's very simple to load simple 3D models e.g. from the [obj](obj.md) format) -- you simply project (using [perspective](perspective.md)) 3D position of each vertex to screen coordinates and draw triangles between these pixels with the rasterization algorithm. Here you need to also solve [visibility](visibility.md), i.e. possible overlap of triangles on the screen and correctly drawing those nearer the view in front of those that are further away -- a very simple solution is a [z buffer](z_buffer.md), but to save memory you can also e.g. [sort](sorting.md) the triangles by distance and draw them back-to-front ([painter's algorithm](painters_algorithm.md)). You may add a [scene](scene.md) data structure that can hold multiple models to be rendered. If you additionally want to have movable camera and models that can be transformed (moved, rotated, scaled, ...), you will additionally need to look into some [linear algebra](linear_algebra.md) and [transform matrices](transform_matrix.md) that allow to efficiently compute positions of vertices of a transformed model against a transformed camera -- you do this the same way as basically all other 3D engines (look up e.g. some [OpenGL](opengl.md) tutorials). If you also want texturing, the matter gets again a bit more complicated, you need to compute [barycentric](barycentric.md) coordinates (special coordinates within a triangle) as you're rasterizing the triangle, and possibly apply [perspective correction](perspective_correction.md) (otherwise you'll be seeing distortions). You then map the barycentrics of each rasterized pixel to [UV](uv.md) (texturing) coordinates which you use to retrieve specific pixels from a texture. On top of all this you may start adding all the advanced features of typical engines such as [acceleration structures](acceleration_structure.md) that for example discard models that are completely out of view, [LOD](lod.mf), instancing, [MIP maps](mip_map.md) and so on.
 
 ## Specific Renderers
 
@@ -32,8 +32,9 @@ These are some notable software renderers:
 - **[small3dlib](s3l.md)**: [LRS](lrs.md) [C](c.md) 3D rasterizer, very simple.
 - **SSRE**: The guy who wrote [LIL](lil.md) also made this renderer named Shitty Software Rendering Engine, accessible [here](http://runtimeterror.com/tech/ssre/).
 - **[TinyGL](tinygl.md)**: Implements a subset of [OpenGL](opengl.md).
-- Many old [games](game.md) implemented their own software renderers, so you can look there.
+- Many old [games](game.md) in the 90s implemented their own software renderers, so you can look there.
 
 ## See Also
 
+- [3D rendering](3d_rendering.md)
 - [pseudo/primitive 3D, 2.5D](pseudo3d.md)

tas.md

@@ -1,14 +1,14 @@
 # Tool Assisted Speedrun
 
-Tool assisted speedrun (TAS, also more generally: tool assisted superplay) is a category of [game](game.md) [speedruns](speedrun.md) in which help of tools and play techniques that would normally be considered [cheating](cheat.md) (such as [scripting](script.md) and time manipulation) is allowed. This makes it possible to create flawless, perfect or near-perfect runs which can serve as a theoretical upper limit for what is achievable by humans -- and of course TAS runs are pretty [fun](fun.md) to watch. The normal, non-TAS runs are called RTA (real time attack). For example the current (2022) RTA world record of Super Mario Bros is 4.58.881 while the TAS record is 4.41.27.
+Tool assisted speedrun (TAS, also more generally *tool assisted superplay*) is a category of [game](game.md) [speedruns](speedrun.md) in which help of any tools is allowed, even those that would otherwise be considered [cheating](cheating.md), e.g. scripts, savestates, [aimbots](aimbot.md) or time manipulation, however NOT those that alter the game itself. This makes it possible to create flawless, perfect or near-perfect runs which can serve as a theoretical upper limit for what is achievable by humans -- and of course TAS runs are pretty [fun](fun.md) to watch. The normal, non-TAS runs are called RTA (real time attack). For example the current (2022) RTA world record of Super Mario Bros is 4.58.881 while the TAS record is 4.41.27.
 
 { Watching a TAS is kind of like watching the [God](god.md) play the game. I personally like to watch Trackmania TASes, some are really unbelievable. Also note that [SAF](saf.md) games have TAS support. ~drummyfish }
 
 There is a website with videos of game TASes: https://tasvideos.org/.
 
-TAS does NOT allow hacking the game in other ways than what's possible to achieve by simply playing the game, i.e. it is not possible to hex edit the game's code before running it or manipulate its RAM content at run time. The goal of TAS is merely to find, as best as we can, the series of game inputs that will lead to completing the game as fast as possible. For this the game pretty much needs to be [deterministic](determinism.md), i.e. the same sequence of inputs must always reproduce the same run when replayed later.
+TAS does NOT allow hacking the game in other ways than what's possible to achieve by simply playing the game, i.e. it is not possible to hex edit the game's code before running it or manipulate its RAM content at run time with external tools. However note that some games are buggy and allow things such as altering their RAM content or code by merely playing the game (e.g. Pokemon Yellow allows so called arbitrary code execution), which generally IS allowed. The goal of TAS is merely to find, as best as we can, the series of game inputs that will lead to completing the game as fast as possible. For this the game pretty much needs to be [deterministic](determinism.md), i.e. the same sequence of inputs must always reproduce the same run when replayed later.
 
-TAS runs coexist alongside RTA runs as separate categories that are beneficial to each other: RTA runners come up with speedrunning techniques that TAS programmers can perfectly execute and vice versa, TAS runners many times discover new techniques and ideas for RTA runners (for example the insane discovery of groundbreaking noseboost when TAS was introduced to Trackmania). In fact RTA and TAS runners are many times the very same people.
+TAS runs coexist alongside RTA (non-TAS) runs as separate categories that are beneficial to each other: RTA runners come up with speedrunning techniques that TAS programmers can perfectly execute and vice versa, TAS runners many times discover new techniques and ideas for RTA runners (for example the insane discovery of groundbreaking noseboost when TAS was introduced to Trackmania). In fact RTA and TAS runners are many times the very same people. Of course if you submit a TAS run in RTA category, you'll be seen as a cheater.
 
 Creating a TAS is not an easy task, it requires great knowledge of the game (many times including its code) and its speedrunning, as well as a lot of patience and often collaboration with other TASers. TASes are made *offline* (not in real time), i.e. hours of work are required to program minutes or even seconds of the actual run. Many paths need to be planned and checked. Compared to RTAs, the focus switches from mechanical skills towards skillful mathematical analysis and planning. Besides this some technological prerequisites are necessary: the actual tools to assist with creation of the TAS. For many new [proprietary](proprietary.md) games it is extremely difficult to develop the necessary tools as their source code isn't available, their assembly is obscured and littered with "anti-cheating" malware. The situation is better with old games that are played in [emulators](emulator.md) such as [DOS](dos.md) games or games for consoles like [GameBoy](gameboy.md) -- emulators can give us a complete control over the environment, they allow to save and load the whole emulator state at any instant, we may slow the time down arbitrarily, rewind and script the inputs however we wish (an advanced technique includes e.g. [bruteforcing](brute_force.md): exhaustively checking all possible combinations of inputs over the following few frames to see which one produces the best time save). In games that don't have TAS tools people at least try to do the next best thing with segmented speedruns.