In [3D](3d.md) [computer graphics](graphics.md) billboard is a flat image placed in the scene that rotates so that it's always facing the camera. Billboards used to be greatly utilized instead of actual [3D models](3d_model.md) in old [games](game.md) thanks to being faster to render (and possibly also easier to create than full 3D models), but we can still encounter them even today and even outside retro games, e.g. [particle systems](particle_system.md) are normally rendered with billboards (each particle is one billboard). Billboards are also commonly called *[sprites](sprite.md)*, even though that's not exactly accurate.
There are two main types of billboards:
By axis of rotation there are two main types of billboards:
- Ones **rotating only about vertical axis**, i.e. billboards that change only their [yaw](yaw.md), they only face the camera in a top-down view of the scene. Such sprite may deform on the screen (when the camera is at different height level) just like 3D models do and when viewed completely from above will disappear completely. This may in some situations look better than other options (e.g. in [games](game.md) enemies won't appear lying on their back when seen from above).
- **Freely rotating** ones, i.e. ones that change all three [Euler angles](euler_angle.md) so that they ALWAYS face the camera from any possible angle. There may further be other two subtypes: billboards that align themselves with the camera's projection plane (they simply rotate themselves in the same way as the camera) which always end up on the screen as an undeformed and unrotated image, and billboards that face themselves towards the camera's position and copy the camera's [roll](roll.md) (though these may seem like two same things, they are not, for the latter we need to know the camera and billboard's positions, for the former we only need the camera's rotation). For simplicity we usually choose to implement the former, though the latter may result in look closer to that which would be produced by an actual 3D model of the object (e.g. a sphere projected to an ellipse by perspective).
- **Freely rotating** ones, i.e. ones that change all three [Euler angles](euler_angle.md) so that they ALWAYS face the camera from any possible angle.
Furthermore there is another subdivision into two main types by HOW the billboards rotate:
- **Projection plane aligned**: These billboards always align their orientation with the camera's projection plane (they simply rotate themselves in the same way as the camera) which always end up on the screen as an undeformed and unrotated image. This is simple to implement, we can simply [blit](blit.md) a 2D image on the rendered 3D view.
- **Camera position facing**: These billboards face themselves towards the camera's position and copy the camera's [roll](roll.md).
Though the two types above may seem like two same things at first glance, they are in fact not, for the latter we need to know the camera and billboard's positions, for the former we only need the camera's rotation. For simplicity we usually choose to implement the former (projection plane aligned), though the latter may result in look closer to that which would be produced by an actual 3D model of the object.
```
projection plane aligned position facing
| \
| |
| \
_.'| | _.'| |
<:_||<:_||
'.| | '.| |
camera camera
| /
| |
| | _ /
| _.-'
|
```
*Projection plane aligned vs position facing billboards.*
Some billboards also choose their image based on from what angle they're viewed (e.g. an enemy in a game viewed from the front will use a different image than when viewed from the side, as seen e.g. in [Doom](doom.md)). Also some billboards intentionally don't scale and keep the same size on the screen, for example health bars in some games.
@ -86,7 +86,7 @@ So secondly we need to implement a so called **search** algorithm -- typically s
Exhaustively searching the tree to great depths is not possible even with most powerful hardware due to astronomical numbers of possible move combinations, so the engine has to limit the depth quite greatly and use various [hacks](hacking.md), [approximations](approximation.md), [heuristics](heuristic.md) etc.. Normally it will search all moves to a small depth (e.g. 2 or 3 half moves or *plys*) and then extend the search for interesting moves such as exchanges or checks. Maybe the greatest danger of searching algorithms is so called **horizon effect** which has to be addressed somehow (e.g. by detecting quiet positions, so called *quiescence*). If not addressed, the horizon effect will make an engine misevaluate certain moves by stopping the evaluation at certain depth even if the played out situation would continue and lead to a vastly different result (imagine e.g. a queen taking a pawn which is guarded by another pawn; if the engine stops evaluating after the pawn take, it will think it's a won pawn, when in fact it's a lost queen). There are also many techniques for reducing the number of searched tree nodes and speeding up the search, for example pruning methods such as **alpha-beta** (which subsequently works best with correctly ordering moves to search), or **transposition tables** (remembering already evaluated position so that they don't have to be evaluated again when encountered by a different path in the tree).
**Alternative approaches**: most engines work as described above (search plus evaluation function) with some minor or bigger modifications. The simplest possible stupid AI can just make random moves, which will of course be an extremely weak opponent -- one might perhaps try to just program a few simple rules to make it a bit less stupid and possibly a simple training opponent for complete beginners: the AI may for example pick a few "good looking" candidate moves that are "usually OK" (pushing a pawn, taking a higher value piece, castling, ...) and aren't a complete insanity, then pick one at random only from those (this randomness can further be improved and gradually controlled by scoring the moves somehow and adding a more or less random value from some range to each score, then picking the moves with highest score). One could also try to just program in a few generic rules such as: checkmate if you can, otherwise take an unprotected piece, otherwise protect your own unprotected piece etc. -- this could produce some beginner level bot. Another idea might be a "Chinese room" bot that doesn't really understand chess but has a huge database of games (which it may even be fetching from some Internet database) and then just looking up what moves good players make in positions that arise on the board, however a database of all positions will never exist, so in case the position is not found there has to be some fallback (e.g. play random move, or somehow find the "most similar position" and use that, ...). As another approach one may try to use some **non neural network [machine learnening](machine_learning.md)**, for example [genetic programming](genetic_programming.md), to train the evaluation function, which will then be used in the tree search. Another idea that's being tried (e.g. in the Maia engine) is **pure neural net AI** (or another form of machine learning) which doesn't use any tree search -- not using search at all has long been thought to be impossible as analyzing a chess position completely statically without any "looking ahead" is extremely difficult, however new neural networks have shown to be extremely good at this kind of thing and pure NN AIs can now play on a master level (a human grandmaster playing ultra bullet is also just a no-calculation, pure pattern recognition play). Next, **[Monte Carlo](monte_carlo.md) tree search** (MCTS) is an alternative way of searching the game tree which may even work without any evaluation function: in it one makes many random playouts (complete games until the end making only random moves) for each checked move and based on the number of wins/losses/draws in those playouts statistically a value is assigned to the move -- the idea is that a move that most often leads to a win is likely the best. Another Monte Carlo approach may just make random playouts, stop at random depth and then use normal static evaluation function (horizon effect is a danger but hopefully its significance should get minimized in the averaging). However MCTS is pretty tricky to do well. MCTS is used e.g. in Komodo Dragon, the engine that's currently among the best. Another approach may lie in somehow using several methods and [heuristics](heuristic.md) to vote on which move would be best.
**Alternative approaches**: most engines work as described above (search plus evaluation function) with some minor or bigger modifications. The simplest possible stupid AI can just make random moves, which will of course be an extremely weak opponent (though even weaker can be made, but these will actually require more complex code as to play worse than random moves requires some understanding and searching for the worst moves) -- one might perhaps try to just program a few simple rules to make it a bit less stupid and possibly a simple training opponent for complete beginners: the AI may for example pick a few "good looking" candidate moves that are "usually OK" (pushing a pawn, taking a higher value piece, castling, ...) and aren't a complete insanity, then pick one at random only from those (this randomness can further be improved and gradually controlled by scoring the moves somehow and adding a more or less random value from some range to each score, then picking the moves with highest score). One could also try to just program in a few generic rules such as: checkmate if you can, otherwise take an unprotected piece, otherwise protect your own unprotected piece etc. -- this could produce some beginner level bot. Another idea might be a "Chinese room" bot that doesn't really understand chess but has a huge database of games (which it may even be fetching from some Internet database) and then just looking up what moves good players make in positions that arise on the board, however a database of all positions will never exist, so in case the position is not found there has to be some fallback (e.g. play random move, or somehow find the "most similar position" and use that, ...). As another approach one may try to use some **non neural network [machine learnening](machine_learning.md)**, for example [genetic programming](genetic_programming.md), to train the evaluation function, which will then be used in the tree search. Another idea that's being tried (e.g. in the Maia engine) is **pure neural net AI** (or another form of machine learning) which doesn't use any tree search -- not using search at all has long been thought to be impossible as analyzing a chess position completely statically without any "looking ahead" is extremely difficult, however new neural networks have shown to be extremely good at this kind of thing and pure NN AIs can now play on a master level (a human grandmaster playing ultra bullet is also just a no-calculation, pure pattern recognition play). Next, **[Monte Carlo](monte_carlo.md) tree search** (MCTS) is an alternative way of searching the game tree which may even work without any evaluation function: in it one makes many random playouts (complete games until the end making only random moves) for each checked move and based on the number of wins/losses/draws in those playouts statistically a value is assigned to the move -- the idea is that a move that most often leads to a win is likely the best. Another Monte Carlo approach may just make random playouts, stop at random depth and then use normal static evaluation function (horizon effect is a danger but hopefully its significance should get minimized in the averaging). However MCTS is pretty tricky to do well. MCTS is used e.g. in Komodo Dragon, the engine that's currently among the best. Another approach may lie in somehow using several methods and [heuristics](heuristic.md) to vote on which move would be best.
Many other aspects come into the AI design such as opening books (databases of best opening moves), endgame tablebases (precomputed databases of winning moves in simple endgames), clock management, pondering (thinking on opponent's move), learning from played games etc. For details see the above linked chess programming wiki.
@ -16,7 +16,7 @@ Though unknown to common people, the invention and adoption of free software has
**Is free software [communism](communism.md)?** This is a question often debated by [Americans](usa.md) who have a panic phobia of anything resembling ideas of sharing and giving away for free. The answer is: yes and no. No as in it's not [Marxism](marxism.md), the kind of [evil](evil.md) pseudocommunism that plagued the world not a long time long ago -- that was a hugely complex, twisted violent ideology encompassing whole society which furthermore betrayed many basic ideas of equality and so on. Compared to this free software is just a simple idea of not applying intellectual property to software, and this idea may well function under some form of early capitalism. But on the other hand yes, free software is communism in its general form that simply states that sharing is good, it is communism as much as e.g. teaching a kid to share toys with its siblings.
# Definition
## Definition
Free software was originally defined by [Richard Stallman](rms.md) for his [GNU](gnu.md) project. The definition was subsequently adopted and adjusted by other groups such as [Debian](debian.md) or [copyfree](copyfree.md) and so nowadays there isn't just one definition, even though the GNU definition is usually implicitly assumed. However, all of these definition are very similar and are quite often variations and subsets of the original one. The GNU definition of free software is paraphrased as follows:
@ -35,7 +35,7 @@ To make it clear, freedom 0 (use for any purpose) covers ANY use, even commercia
The developers of Debian operating system have created their own guidelines (Debian Free Software Guidelines) which respect these points but are worded in more complex terms and further require e.g. non-functional data to be available under free terms as well ([source](https://people.debian.org/~bap/dfsg-faq.html#not_just_code)), respecting also [free culture](free_culture.md), which GNU doesn't ([source](https://www.gnu.org/distros/free-system-distribution-guidelines.en.html#non-functional-data)). The definition of "[open source](open_source.md)" is yet more complex even though in practice legally free software is eventually also open source and vice versa. The [copyfree](copyfree.md) definition tries to be a lot more strict about freedom and forbids for example [copyleft](copyleft.md) (which GNU promotes) and things such as [DRM](drm.md) clauses (i.e. a copyfree license mustn't impose technology restrictions, even those seen as "justified", for similar reasons why we don't prohibit any kind of use for example).
# History
## History
Free software was invented by [Richard Stallman](rms.md) in the 1980s. His free software movement inspired later movements such as the [free culture](free_culture.md) movement and the evil [open-source](open_source.md) movement.
@ -43,11 +43,11 @@ Free software was invented by [Richard Stallman](rms.md) in the 1980s. His free
**The "free software alternatives" question** is one that's constantly being discussed under [capitalism](capitalism.md): [corporations](corporation.md) try to forcefully keep users enslaved by proprietary software environments while free software proponents and users themselves want to free the users with "alternatives" made as free software. A very common mistake for a free software newcomer to make is to try to **"drop-in replace proprietary software with free software"**; a user used to proprietary software and its ways just wants the programs he's used to, just "without ads and subscriptions etc.". This doesn't work, or only to an extremely limited scale, because the whole proprietary world is made and DESIGNED from the ground up to allow user exploitation as much as possible, with e.g. building such thing like [consumerism](consumerism.md) right into the design of visual elements of the software etc., i.e. proprietary vs free software is not just about a legal [license](license.md), but whole philosophy of technology, asking things such as [why are we so obsessed over "updates"](update_culture.md) or [why are we freaking out about privacy](privacy.md). Trying to drop-in replace proprietary technology with 1 to 1 looking free software is like trying to replace whole capitalism with an "environment friendly capitalism" in which everything works the same except we have cars made of wood and skyscrapers made of recycled paper -- indeed, one sees that to get rid of the destructive nature of capitalism we really have to replace capitalism as such with all its basic concepts with something fundamentally different; and the situation is same with proprietary software.
For example most users nowadays want [GUI](gui.md) in all programs, which is how they've been nurtured by capitalism, however we have to realize that **a truly ([de facto](de_facto.md), not just legally) free software has to be [minimalist](minimalism.md)** and so most TRULY free software will mostly work only from the [command line](cli.md); a command line program is not necessarily harder or less comfortable to use (users are just nurtured to think so by capitalism), it is however inherently more free than a GUI one in all ways (not only by being more flexible, efficient, [portable](portable.md) and non-discrimination, but also simpler and therefore e.g. modifiable by more people). We have to realize that a **freedom respecting computing environment INHERENTLY LOOKS DIFFERENT from the proprietary one**, the matter is NOT only about the license (free license is just a necessary condition to allow freedom under capitalism, however it is not a sufficient condition for freedom). Some projects calling themselves "free" (or rather "[open source](open_source.md)") make the mistake (sometimes intentionally, exactly to e.g. more easily pull over more users from the proprietary land) of simply mimicking proprietary ways 1 to 1 -- see e.g. [Fediverse](fediverse.md) ("free" facebook/twitter/etc.), [Blender](blender.md) etc. -- these are technically/legally free, but not actually, de-facto free. While a short-sighted view tells us this wins more users from the proprietary platforms, in long term we see we are just rebuilding dystopias, only painted with brighter colors so as to make them look friendlier (and oftentimes this is exactly the aim of the authors). Transitioning to TRULY free platforms is harder -- **one has to relearn basic things** such as, as has been mentioned, working with command line rather than GUI -- but ultimately right as one really gets more freedom, however under capitalist pressure and nurturing it is a hard thing to do, requiring extorting a lot of energy to resist the pressures of society.
For example most users nowadays want [GUI](gui.md) in all programs, which is how they've been nurtured by capitalism, however we have to realize that **a truly ([de facto](de_facto.md), not just legally) free software has to be [minimalist](minimalism.md)** and so most TRULY free software will mostly work only from the [command line](cli.md); a command line program is not necessarily harder or less comfortable to use (users are just nurtured to think so by capitalism), it is however inherently more free than a GUI one in all ways (not only by being more flexible, efficient, [portable](portability.md) and non-discrimination, but also simpler and therefore e.g. modifiable by more people). We have to realize that a **freedom respecting computing environment INHERENTLY LOOKS DIFFERENT from the proprietary one**, the matter is NOT only about the license (free license is just a necessary condition to allow freedom under capitalism, however it is not a sufficient condition for freedom). Some projects calling themselves "free" (or rather "[open source](open_source.md)") make the mistake (sometimes intentionally, exactly to e.g. more easily pull over more users from the proprietary land) of simply mimicking proprietary ways 1 to 1 -- see e.g. [Fediverse](fediverse.md) ("free" facebook/twitter/etc.), [Blender](blender.md) etc. -- these are technically/legally free, but not actually, de-facto free. While a short-sighted view tells us this wins more users from the proprietary platforms, in long term we see we are just rebuilding dystopias, only painted with brighter colors so as to make them look friendlier (and oftentimes this is exactly the aim of the authors). Transitioning to TRULY free platforms is harder -- **one has to relearn basic things** such as, as has been mentioned, working with command line rather than GUI -- but ultimately right as one really gets more freedom, however under capitalist pressure and nurturing it is a hard thing to do, requiring extorting a lot of energy to resist the pressures of society.
After some years dealing with software freedom (in serious ways, making money doesn't count) many -- including [us](lrs.md) -- realize that the "licensing" fuzz and legal questions, though important, are the surface, shallow views of freedom; one that also gets exploited by many (see e.g. [openwashing](openwashing.md)). Those who seek real freedom will sooner or later find themselves focusing on [minimalism](minimalism.md) and simplicity, e.g. [LRS](lrs.md), [suckless](suckless.md), [Bitreich](bitreich.md) etc. Going yet further, one starts to see the inherent interconnections of technology and whole society, and has to become interested also in social concepts, hence our proposal of [less retarded society](less_retarded_society.md).
After some years dealing with software freedom (in serious ways, making money doesn't count) many -- including [us](lrs.md) -- realize that the "licensing" fuss and legal questions, though important, are the surface, shallow views of freedom; one that also gets exploited by many (see e.g. [openwashing](openwashing.md)). Those who seek real freedom will sooner or later find themselves focusing on [minimalism](minimalism.md) and simplicity, e.g. [LRS](lrs.md), [suckless](suckless.md), [Bitreich](bitreich.md) etc. Going yet further, one starts to see the inherent interconnections of technology and whole society, and has to become interested also in social concepts, hence our proposal of [less retarded society](less_retarded_society.md).
@ -4,11 +4,11 @@ Mechanical computer (simple ones also being called *mechanical [calculators](cal
{ Britannica 11th edition has a truly amazing article on mechanical computers under the term *Calculating Machines*: https://en.wikisource.org/wiki/1911_Encyclop%C3%A6dia_Britannica/Calculating_Machines. Also this leads to many resources: https://www.johnwolff.id.au/calculators/Resources.htm. ~drummyfish }
If mechanical computer also utilizes [electronic](electronics.md) parts, it is called an electro-mechanical computer; here we'll however be mainly discussing purely mechanical computers.
If mechanical computer also utilizes [electronic](electronics.md) parts, it is called an **electro-mechanical** computer; here we'll however be mainly discussing purely mechanical computers.
**Disadvantages** of digital mechanical computers against electronic ones are great, they basically lose at everything except simplicity of implementation (in the desert). Mechanical computer is MUCH slower (speed will be measured in Hz), has MUCH less memory (mostly just a couple of [bits](bit.md) or [bytes](byte.md)), will be difficult to program ([machine code](machine_code.md) only), is MUCH bigger, limited by mechanical friction (so it will also be noisy), suffers from mechanical wear etc. Analog mechanical computers are maybe a bit better in comparison, but still lose to electronics big time. But remember, [less is more](less_is_more.md).
Some notable mechanical computers include e.g. the 1882 [Difference Engine](difference_engine.md) by Charles Babbage (aka the first [programmer](programmer.md)), Antikythera mechanism (ancient Greek astronomical computer), the famous [Curta](curta.md) calculators (quality, powerful pocket-sized mid-20th century calculators) { These are really cool, check them out. ~drummyfish }, [Enigma](enigma.md) ciphering device (used in WWII), [abacus](abacus.md), [slide rule](slide_rule.md), Odhner Arithmometer (extremely popular Russian table calculator), [Digi-Comp](digi_comp.md) I (educational programmable 3 bit toy computer) or [Turing Tumble](turing_tumble.md) { Very KISS and elegant, also check out. ~drummyfish } (another educational computer, using marbles).
Some **notable mechanical computers** include e.g. the 1882 [Difference Engine](difference_engine.md) by Charles Babbage (aka the first [programmer](programmer.md)), Antikythera mechanism (ancient Greek astronomical computer), the famous [Curta](curta.md) calculators (quality, powerful pocket-sized mid-20th century calculators) { These are really cool, check them out. ~drummyfish }, [Enigma](enigma.md) ciphering device (used in WWII), [abacus](abacus.md), [slide rule](slide_rule.md), Odhner Arithmometer (extremely popular Russian table calculator), [Digi-Comp](digi_comp.md) I (educational programmable 3 bit toy computer) or [Turing Tumble](turing_tumble.md) { Very KISS and elegant, also check out. ~drummyfish } (another educational computer, using marbles).
Let's also take a look at how we can classify mechanical computers. Firstly they can be:
@ -35,7 +35,7 @@ As mere [programmers](programming.md) let us focus more on **digital** computers
When building a digital computer from scratch we usually start by designing basic [logic gates](logic_gate.md) such as AND, NOT and OR -- here we implement the gates using mechanical principles rather than transistors or relays. For simple special-purpose calculators combining these logic gates together may be enough (also note we don't HAVE TO use logic gates, some mechanisms can directly perform arithmetic etc.), however for a highly programmable general purpose computer **logic gates alone practically won't suffice** -- in theory when we have finite memory ([in real world](irl.md) always), we can always just use only logic gates to perform any computation, but as the memory grows, the number of logic gates we would need would grow exponentially, so we don't do this. Instead we will need to additionally implement some **sequential processing**, i.e. something like a [CPU](cpu.md) that performs steps according to program instructions.
Now we have to choose our model of computation and general architecture, we have possibly a number of options. Mainly we may be deciding between having a separate storage for data and program (Harvard architecture) or having the program and data in the same memory (intending for the computer to "reshape" this initial program data into the program's output). Here there are paths to explore, the most natural one is probably trying to imitate a **[Turing machine](turing_machine.md)** (many physical finite-tape Turing machines exist, look them up), probably the simplest "intuitive" computer, but we can even speculate about e.g. some kind of rewriting system imitating formal [grammars](grammar.md), [cellular automata](cellular_automaton.md) etc -- someone actually built a simple and elegant [rule 110](rule110.md) marble computer (look up on YT), which is Turing complete, but not very practical. So Turing machine seems to be the closest to our current idea of a computer (try to program something useful in rule 110...), it's likely the most natural way, so that might be the best first choice we try.
Now we have to choose our model of computation and general architecture, we have possibly a number of options. Mainly we may be deciding between having a separate storage for data and program (Harvard architecture) or having the program and data in the same memory (intending for the computer to "reshape" this initial program data into the program's output). Here there are paths to explore, the most natural one is probably trying to imitate a **[Turing machine](turing_machine.md)** (many physical finite-tape Turing machines exist, look them up), probably the simplest "intuitive" computer, but we can even speculate about e.g. some kind of rewriting system imitating formal [grammars](grammar.md), [cellular automata](cellular_automaton.md) etc -- someone actually built a simple and elegant [rule 110](rule110.md) marble computer (look up on YT), which is Turing complete but not very practical (see [Turing tarpit](turing_tarpit.md)). So Turing machine seems to be the closest to our current idea of a computer (try to program something useful in rule 110...), it's likely the most natural way, so that might be the best first choice we try.
Turing machine has a separate memory for program and data. To build it we need two main parts: memory tape (an array of [bits](bit.md)) and control unit (table of states and their transitions). We can potentially design these parts separately and let them communicate via some simple interface, which simplifies things. The specific details of the construction will now depend on what components we use (gears, marbles, dominoes, levers, ...)...
@ -197,6 +197,6 @@ Whether the use of fluids/gases (water, air, steam, maybe even sand, ...) is sti
### Other
Don't forget there exist many other possible components and concepts a mechanical computer can internally use -- many things we leave out above for the questionability of their practical usability can be used to in fact carry out computation, for example dominoes or slinkies. Furthermore many actually useful things exist, e.g. teethed **cylinders/disks** may be used to record plots of data over time or to store and deliver read/only data (e.g. the program instructions) easily, see music boxes and gramophones; **[punch card](punch_card.md)** have widely been used for storing read-only data too. Sometimes deformed cylinders were used as an analog **2D [look up table](lut.md)** for some mathematical [function](function.md) -- imagine e.g. a device that has input *x* (rotating cylinder along its axis) and *y* (shifting it left/right); the cylinder can then at each surface point record function *f(x,y)* by its width which will in turn displace some stick that will mark the function value on a scale. To transfer movement **strings, chains and belts** may also be used. [Random number generation](rng.md) may be implemented e.g. with [Galton board](galton_board.md). If timing is needed, pendulums can be used just like in clock. Some mechanical computers even use pretty complex parts such as mechanical arms, but these are firstly hard to make and secondly prone to breaking, so try to avoid complexity as much as possible. Some old mechanical calculators worked by requiring the user to plug a stick into some hole (e.g. number he wanted to add) and then manually trace some path -- this can work on the same principle as e.g. the marble computer, but without needing the marbles complexity and size are drastically reduced.
Don't forget there exist many other possible components and concepts a mechanical computer can internally use -- many things we leave out above for the questionability of their practical usability can be used to in fact carry out computation, for example dominoes or slinkies. Furthermore many actually useful things exist, e.g. teethed **cylinders/disks** may be used to record plots of data over time or to store and deliver read/only data (e.g. the program instructions) easily, see music boxes and gramophones; **[punch card](punch_card.md)** have widely been used for storing read-only data too. Sometimes deformed cylinders were used as an analog **2D [look up table](lut.md)** for some mathematical [function](function.md) -- imagine e.g. a device that has input *x* (rotating cylinder along its axis) and *y* (shifting it left/right); the cylinder can then at each surface point record function *f(x,y)* by its width which will in turn displace some stick that will mark the function value on a scale. To transfer movement **strings, chains and belts** may also be used. [Random number generation](rng.md) may be implemented e.g. with [Galton board](galton_board.md). If timing is needed, pendulums can be used just like in clock. Some mechanical computers even use pretty complex parts such as mechanical arms, but these are firstly hard to make and secondly prone to breaking, so try to avoid complexity as much as possible. Some old mechanical calculators worked by requiring the user to plug a stick into some hole (e.g. number he wanted to add) and then manually trace some path -- this can work on the same principle as e.g. the marble computer, but without needing the marbles complexity and size are drastically reduced. Another ideas is a "combing" computer which is driven by its user repeatedly sliding some object through the mechanism (as if combing it) which performs the steps (sequential computation) and changes the state (which is either stored inside the computer or in the combing object).
BONUS THOUGHT: We have gotten so much used to using our current electronic digital computers for everything that sometimes we forget that at simulating actual physical reality they may still fail (or just be very overcomplicated) compared to a mechanical simulation which USES the physical reality itself; for example to make a simulation of a tsunami wave it may be more accurate to build an actual small model of a city and flood it with water than to make a computer simulation. That's why aerodynamic tunnels are still a thing. Ancient NASA flight simulators of space ships did use some electronics, but they did not use computer graphics to render the view from the ship, instead they used a screen projecting view from a tiny camera controlled by the simulator, moving inside a tiny environment, which basically achieved photorealistic graphics. Ideas like these may come in handy when designing mechanical computers as simulating reality is often what we want to do with the computer; for example if we want to model a [sine](sin.md) function, we don't have to go through the pain of implementing binary logic and performing iterative calculation of sine approximation, we may simply use a pendulum whose swinging draws the function simply and precisely.
RGB332 is a general 256 color [palette](palette.md) that encodes one color with 1 [byte](byte.md) (i.e. 8 [bits](bit.md)): 3 bits (highest) for red, 3 bits for green and 2 bits (lowest) for blue (as human eye is least sensitive to blue). RGB332 is an implicit palette -- it doesn't have to be stored in memory because the color index itself determines the color and vice versa. Compared to the classic 24 bit RGB (which assigns 8 bits to each of the RGB components), RGB332 is very "[KISS](kiss.md)/[suckless](suckless.md)" and often [good enough](good_enough.md) (especially with [dithering](dithering.md)) as it saves memory, avoids headaches with [endianness](byte_sex.md) and represents each color with just a single number (as opposed to 3), so it is often used in simple and limited computers such as [embedded](embedded.md). It is also in the [public domain](public_domain.md), unlike some other palettes, so it's additionally a legally safe choice. RGB332 also has a "sister palette" called [RGB565](rgb565.md) which uses two bytes instead of one and so offers many more colors.
RGB332 is a general 256 color [palette](palette.md) that encodes one color with 1 [byte](byte.md) (i.e. 8 [bits](bit.md)): 3 bits (highest) for red, 3 bits for green and 2 bits (lowest) for blue (as human eye is least sensitive to blue we choose to allocate fewest bits to blue). RGB332 is an implicit palette -- it doesn't have to be stored in memory (though doing so also has justifications) because the color index itself determines the color and vice versa. Compared to the classic 24 bit RGB (which assigns 8 bits to each of the RGB components), RGB332 is very "[KISS](kiss.md)/[suckless](suckless.md)" and often [good enough](good_enough.md) (especially with [dithering](dithering.md)) as it saves memory, avoids headaches with [endianness](byte_sex.md) and represents each color with just a single number (as opposed to 3), so it is often used in simple and limited computers such as [embedded](embedded.md). It is also in the [public domain](public_domain.md), unlike some other palettes, so it's additionally a legally safe choice. RGB332 also has a "sister palette" called [RGB565](rgb565.md) which uses two bytes instead of one and so offers many more colors.
A disadvantage of plain 332 palette lies in the linearity of each component's intensity, i.e. lack of [gamma correction](gamma_correction.md), so there are too many almost indistinguishable bright colors while too few darker ones { TODO: does a gamma corrected 332 exist? make it? ~drummyfish }. Another disadvantage is the non-alignment of the blue component with red and green components, i.e. while R/G components have 8 levels of intensity and so step from 0 to 255 by 36.4, the B component only has 4 levels and steps by exactly 85, which makes it impossible to create exact shades of grey (which of course have to have all R, G and B components equal).
RGB565 is a way of representing a total of 65536 [colors](color.md) in just 2 [bytes](byte.md), i.e. 16 [bits](bit.md), by using 5 bits (highest) for red, 6 bits for green (to which human eye is most sensitive) and 5 bits for blue; it can also be seen as a color [palette](palette.md).
RGB565 is a way of representing a total of 65536 [colors](color.md) in just 2 [bytes](byte.md), i.e. 16 [bits](bit.md), by using 5 bits (highest) for red, 6 bits for green (to which human eye is most sensitive) and 5 bits for blue; it can also be seen as a color [palette](palette.md). It is similar to [rgb332](rgb332.md)
