Update
Miloslav Ciz
2 years ago
parent
af3e90bf66
commit
5db91153c8
@ -0,0 +1,15 @@
|
||||
# Double Buffering
|
||||
|
||||
In [computer graphics](graphics.md) double buffering is a technique of rendering in which we do not draw directly to [video RAM](vram.md), but instead to a second "back buffer", and only copy the rendered frame from back buffer to the video RAM ("front buffer") once the rendering has been completed; this prevents flickering and displaying of incompletely rendered frames on the display. Double buffering requires a significant amount of extra memory for the back buffer, however it is also necessary for how graphics is rendered today.
|
||||
|
||||
In most libraries and frameworks today you don't have to care about double buffering, it's done automatically. For this reason in many frameworks you often need to indicate the end of rendering with some special command such as `flip`, `endFrame` etc. If you're going lower level, you may need to implement double buffering yourself.
|
||||
|
||||
Though we encounter the term mostly in computer graphics, the principle of using a second buffer in order to ensure the result is presented only when it's ready can be applied also elsewhere.
|
||||
|
||||
Let's take a small example: say we're rendering a frame in a 3D game. First we render the environment, then on top of it we render the enemies, then effects such as explosions and then at the top of all this we render the [GUI](gui.md). Without double buffering we'd simply be rendering all these pixel into the front buffer, i.e. the memory that is immediately shown on the display. This would lead to the user literally seeing how first the environment appears, then enemies are drawn over it, then effects and then the GUI. Even if all this redrawing takes an extremely short time, it is also the case that the final frame will be shown for a very short time before another one will start appearing, so in the result the user will see huge flickering: the environment may look kind of normal but the enemies, effects and GUI may appear transparent because they are only visible for a fraction of the frame. The user also might be able to see e.g. enemies that are supposed to be hidden behind some object if that object is rendered after the enemies. With double buffering this won't happen as we perform the rendering into the back buffer, a memory which doesn't show on the display. Only when we have completed the frame in the back buffer, we copy it to the front buffer, pixel by pixel. Here the user may see the display changing from the old frame to the new one from top to the bottom, but he will never see anything temporary, and since the old and new frames are usually very similar, this top-to-bottom update may not even be distracting (it is addressed by [vertical synchronization](vsync.md) if we really want to get rid of it).
|
||||
|
||||
There also exists [triple buffering](triple_buffering.md) which uses yet another additional buffer to increase [FPS](fps.md). With double buffering we can't start rendering a new frame into back buffer until the back buffer has been copied to the front buffer which may further be delayed by [vertical synchronization](vsync.md), i.e. we have to wait and waste some time. With triple buffering we can start rendering into the other back buffer while the other one is being copied to the front buffer. Of course this consumes significantly more memory. Also note that triple buffering can only be considered if the hardware supports parallel rendering and copying of data, and if the FPS is actually limited by this... mostly you'll find your FPS bottleneck is elsewhere in which case it makes no sense to try to implement triple buffering. On small devices like embedded you probably shouldn't even think about this.
|
||||
|
||||
Double buffering can be made more efficient by so called page flipping, i.e. allowing to switch the back and front buffer without having to physically copy the data, i.e. by simply changing the [pointer](pointer.md) of a display buffer. This has to be somehow supported by hardware.
|
||||
|
||||
**When do we actually need double buffering?** Not always, we can avoid it or suppress its memory requirements if we need to -- we may want to do this e.g. in [embedded](embedded.md) programming where we want to save every byte of RAM. The mainstream computers nowadays simply always run on a very fast FPS and keep redrawing the screen even if the image doesn't change, but if you write a program that only occasionally changes what's on the screen (e.g. an e-book reader), you may simply leave out double buffering and actually render to the front buffer once the screen needs to change, the user probably won't notice any flicker during a single quick frame redraw. You also don't need double buffering if you're able to compute the final pixel color right away, for example with [ray tracing](ray_tracing.md) you don't need any double buffering, unless of course you're doing some complex [postprocessing](postprocessing.md). Double buffering is only needed if we compute a pixel color but that color may still change before the frame is finished. You may also only use a partial double buffer if that is possible (which may not be always): you can e.g. split the screen into 16 regions and render region by region, using only a 1/16th size double buffer. Using a [palette](palette.md) can also make the back buffer smaller: if we use e.g. a 256 color palette, we only need 1 byte for every pixel of the back buffer instead of some 3 bytes for full [RGB](rgb.md). The same goes for using a smaller resolution that is the actual native resolution of the screen.
|
||||
@ -0,0 +1,14 @@
|
||||
# Semiconductor
|
||||
|
||||
{ For a physicist there's probably quite a lot of simplification, this is written from the limited point of view of a programmer. ~drummyfish }
|
||||
|
||||
Semiconductors are materials whose electrical conductivity varies greatly with conditions such as temperature, illumination or their purity, unlike insulators who generally don't conduct electricity very well (have a great [resistivity](resistivity.md)) and conductors who do. Semiconductors, especially [silicon](silicon.md) (Si), are the key component of [digital](digital.md) [electronic](electronic.md) [computers](computer.md) and integrated circuits. Other semiconductors include germanium, selenium or compound ones (composed of multiple elements).
|
||||
|
||||
Semiconductors are important for computers because they help implement the [binary](binary.md) logic circuits, they can behave like a switch that is either on (1) or off (0). Besides that they can serve e.g. for making measurements (a component whose resistivity depends on its illumination can be used to measure amount of light by measuring the resistivity). Especially important electronic components based on semiconductors are the **[diode](diode.md)** (lets current flow only one way) and **[transistor](transistor.md)** (a purely electrical "switch" that can be made extremely tiny).
|
||||
|
||||
Normally semiconductors don't conduct so well at room temperature (they conduct better at higher temperatures, unlike metals), but their conductivity can be increased by so called **doping** -- introducing small impurities of other elements. By doing this we can get two types of semiconductors:
|
||||
|
||||
- **N type**: By adding e.g. an arsenic atom to a grid of silicon atoms we get an extra free electron because arsenic has 5 outer electrons while silicon has 4. Arsenic binds its 4 electrons with neighboring silicon atoms (with so called covalent bond, sharing pairs of electrons), but will have one unbound electron, which thanks to not being bound can move easily and help conduct electricity (note that when the electron does move away, arsenic will still want to get another electron because it will become positive charged, but the fifth electron is simply always more "loose" thanks to not being bound). In this type of semiconductor we have negative particles, the **electrons**, moving around.
|
||||
- **P type**: By similarly adding e.g. an boron atom to a silicon grid, we get a similar situation; boron only has 3 outer electrons, so it will only bind to 3 silicon atoms, leaving one the bond with one silicon incomplete, forming a **hole**. This hole can be seen as a [virtual](virtual.md) positively charged particle, it is simply a lack of electron. An electron can temporarily jump in this hole but will want to move away as boron doesn't want it there. In this type of semiconductor we can imagine the holes moving around (even though physically only electrons are moving, of course).
|
||||
|
||||
If we connect a P and N type semiconductors, we get so called **PN junction** which only conducts current one way and is used in diodes and transistors. After putting P and N materials together, at the boundary some electrons from the N type material fill the holes in the P type material which creates a small *depletion region* of certain width. This region is an electric field that's negative on the P side and positive on the N side (because negative electrons have moved from N to P). If we connect the PN junction to a voltage source, with P side to the positive and N side to the negative terminal, we create an opposite electric field which will eliminate the depletion region and allow the flow of current. Connecting the sides the other way around will result in increasing the width of the depletion region and blocking the current flow.
|
||||
@ -1,5 +1,5 @@
|
||||
# Software
|
||||
|
||||
Software (SW) are programs that run on a computer, i.e. its non-physical parts (as opposed to [hardware](hw.md)); for example an [operating system](os.md), the internet [browser](browser.md) etc.
|
||||
Software (SW) are programs that run on a computer, i.e. its non-physical parts (as opposed to [hardware](hw.md)); for example an [operating system](os.md), the internet [browser](browser.md) etc. Software is created by [programming](programming.md).
|
||||
|
||||
Usually we can pretty clearly say what is software and what is hardware, but there are cases where it's debatable. Normally software is that about the computer which *can relatively easily be changed* (i.e. reinstalled by a typing a few commands or clicking a few buttons) while hardware is *hard-wired*, difficult to modify, and not expected or designed to be modified. Nevertheless e.g. some [firmware](firmware.md) is kind of software in form of instructions which is however many times installed in some special kind of memory that's difficult to reprogram and not expected to be reprogrammed often -- some software may be "burned in" into a circuit so that it could only be changed by physically rewiring the circuit (the ME spyware in [Intel](intel.md) [CPU](cpu.md)s has a built-in [minix](minix.md) operating system). And this is where it may sometimes be difficult to decide where the line is drawn. This issue is encountered e.g. by the [FSF](fsf.md) which certifies some hardware that works with free software as "Respects Your Privacy" (RYF), and they have very specific definition what to them classifies software.
|
||||
@ -0,0 +1,30 @@
|
||||
# Transistor
|
||||
|
||||
Transistor is a small [semiconductor](semiconductor.md) element of [electronic](electronics.md) circuits that can be used as an amplifier or a switch, and which is a basic building block of [digital](digital.md) electronic [computers](computer.md), integrated circuits and many other electronic devices. Transistors replaced [vacuum tubes](vacuum_tube.md) and [relays](relay.md) which were used in primitive computers of the 20th century; transistors can be made much smaller, cheaper, more reliable and, unlike relays, operated purely electronically and therefore much faster. Transistor has become the most manufactured device in history.
|
||||
|
||||
Transistor generally has three terminals. Its key principle is that of behaving like an electronically operated amplifier or switch: we can make a transistor *open* or *close* (i.e. conduct or not conduct electricity) by applying different voltage or current (and we can also make it something between *open* and *close*). The voltage/current by which we control the transistor can be lower than that which we control, so we can see this as an amplifier: we can control high current with low current, i.e. the high current follows the low current but has higher amplitude. We can also see this as a switch: by applying voltage/current we can make a wire connect (low resistivity) or disconnect (high resistivity) similarly to a physical switch. This switch behavior is important for computers because we can exploit it to implement [binary](binary.md) (on/off) [logic circuits](logic_gate.md).
|
||||
|
||||
A basic division of transistors is following:
|
||||
|
||||
- **bipolar junction transistor (BJT)**: They have 3 terminals: **emitter**, **base** and **collector**. By applying **current** in the base we control the current between emitter and collector (this current can be greater than the control current). BJTs use both kinds of carriers at once, electrons and holes. BJTs are older than FETs, not much used in integrated circuits now.
|
||||
- **PNP**: There is P semiconductor (emitter), N (base) and then P again (collector), creating 2 NP junctions. It opens when there is no current at base.
|
||||
- **NPN**: The other way around that PNP (N, then P, then N). It opens when there is current at base.
|
||||
- **field effect transistor (FET)**: They have 3 terminals: **source**, **gate** and **drain**. By applying **voltage** to gate we control the current between source and drain. They use only one kind of charge carriers (electrons or holes). This is due to a different internal structure from BJTs, e.g. by having gate separated from source and drain with a metal oxide layer in MOSFET. A voltage applied here kind of "pushes" the holes or electrons out of the way to create a channel between source and drain. The transistor can either be in enhancement mode (high voltage opens the transistor) or depletion mode (low voltage opens the transistor). FETs are newer and have some nicer properties, e.g. lower noise or lower power consumption: they **only consume power on state change**.
|
||||
- **P channel**: Source and drain are made of P semiconductor put into an N semiconductor.
|
||||
- **N channel**: Source and drain are made of N semiconductor put into a P semiconductor. They have a bit different properties from P channel FETs.
|
||||
|
||||
Commonly used graphical symbols for transistor are (usually in a circle):
|
||||
|
||||
```
|
||||
E E D D
|
||||
| | | |
|
||||
B___|.-' B___|.-' G |--' G |--'
|
||||
|'>. |'<. -->-|--. --<-|--.
|
||||
| | | |
|
||||
C C S S
|
||||
|
||||
BJT (NPN) BJT (PNP) FET (N) FET (P)
|
||||
```
|
||||
|
||||
First FET transistors were JFETs (junction-gate FET) but by today were mostly replaced by **MOSFETs** (metal-oxide-semiconductor FET), a transistor using a metal oxide layer for separating the gate terminal which gives it some nice properties over JFET. These transistors are used to implement [logic gates](logic_gate.md) e.g. using the **[CMOS](cmos.md)** fabrication process which uses complementary pairs of P and N channel FETs so that e.g. one is always off which decreases power consumption.
|
||||
|
||||
@ -0,0 +1,13 @@
|
||||
# Xonotic
|
||||
|
||||
Xonotic is a [free as in freedom](free_software.md) fast multiplayer arena [first-person-shooter](fps_game.md) [game](game.md) similar to e.g. [Quake](quake.md). It is one of the best libre games, i.e. games that are completely free by both code and data/content. It is available under [GPLv3](gpl.md). Its gameplay, graphics and customizability are amazing, it could very well be considered the best in the AFPS genre, even compared to AAA [proprietary](proprietary.md) games, which is extremely rare.
|
||||
|
||||
{ I've played Xonotic for years, it's really an excellent game. I've met a lot of nice people there as the players are usually programmers and people looking for [FOSS](foss.md). The gameplay is addictive and relaxing and you can have a great chat during it. Xonotic is a masterpiece. ~drummyfish }
|
||||
|
||||
Xonotic was forked from a game called [Nexuiz](nexuiz.md) after a trademark controversy. Nexuiz itself was created on top of liberated Quake 1 engine, so Xonotic still bears a lot Quake's legacy, however it masterfully expands on its core principles and makes the gameplay even better. For example rockets shot by rocket launcher can be guided with mouse while holding down the left button which adds a new element of skill and beautiful frag opportunities. New types of weapons were added to the classic AFPS weapons (e.g. the infamous electro, a [meme](meme.md) spamming weapon used by noobs for its forgiveness of lack of skill). Movement physics was also modified to give better air control and faster movement as a result.
|
||||
|
||||
As of 2022 the game has a small but pretty active community of regular players, centered mostly in Europe. There are regulars playing every day, big pros, noobs, famous spammers, campers, and nice conversations can be held during games. There are [memes](meme.md) and inside jokes. The community is pretty neat.
|
||||
|
||||
Better yet, the main servers have so far not been infected by the [SJW poison](tranny_software.md) and **allow a great amount of [free speech](free_speech.md)** -- another rarity. Even the game itself contains speech that SJWs would consider "offensive", there are e.g. voice lines calling other players "pussies" and even "retards". This is great.
|
||||
|
||||
The game can be highly customized and modded. Just like in other Quake engine games, there are many console commands (*cvars*) to alter almost anything about the game. Advanced programming can be done using [QuakeC](quakec.md). Maps can be created e.g. with [netradiant](netradiant.md).
|
||||
Loading…
Reference in New Issue