Update

demoscene.md

@@ -1,18 +1,19 @@
 # Demoscene
 
-Demoscene is a [hacker](hacking.md) [art](art.md) subculture revolving around making so called [demos](demo.md), programs that produce rich and interesting audiovisual effects and which are sometimes limited by strict size constraints (so called [intros](intro.md)). The scene originated in northern [Europe](europe.md) sometime in 1980s (even though things like screen hacks existed long before) among groups of [crackers](cracker.md) who were adding small signature effect screens into their cracked software (like "digital graffiti"); programming of these cool effects later became an art of its own and started to have their own competitions, so called *[compos](compo.md)*, at dedicated real life events called *[demoparties](demoparty.md)* (which themselves evolved from *[copyparties](copyparty.md)*, real life events focused on [piracy](piracy.md)). The community is still centered mostly in the Europe (primarily Finland), it is underground, out of the mainstream; [Wikipedia](wikipedia.md) says that by 2010 its size was estimated to 10000 people (such people are called *demosceners*).
+Demoscene is a [hacker](hacking.md) [art](art.md) subculture revolving around making so called [demos](demo.md), programs that produce rich and interesting audiovisual effects and which are sometimes limited by strict size constraints (so called [intros](intro.md)). The scene originated in northern [Europe](europe.md) sometime in 1980s (even though things like screen hacks existed long before) among groups of [crackers](cracker.md) who were adding small signature effect screens into their cracked software (like "digital graffiti"); programming of these cool effects later became an art of its own and started to have their own competitions (sometimes with high financial prizes), so called *[compos](compo.md)*, at dedicated real life events called *[demoparties](demoparty.md)* (which themselves evolved from *[copyparties](copyparty.md)*, real life events focused on [piracy](piracy.md)). The community is still centered mostly in the Europe (primarily Finland), it is underground, out of the mainstream; [Wikipedia](wikipedia.md) says that by 2010 its size was estimated to 10000 people (such people are called *demosceners*).
 
-Demoscene is a bittersweet topic: on one side it's awesome, full of beautiful hacking, great ideas and minimalism, on the other side there are secretive people who don't share their source code (most demos are [proprietary](proprietary.md)) and ugly unportable programs that exploit quirks of specific platforms (many times proprietary ones like [Windows](windows.md)). These guys simply try to make the coolest visuals and smallest programs, with all good and bad that comes with it. Try to take only the good of it.
+Demoscene is a bittersweet topic: on one side it's awesome, full of beautiful hacking, great ideas and minimalism, on the other side there are secretive people who don't share their source code (most demos are [proprietary](proprietary.md)) and ugly unportable programs that exploit quirks of specific platforms -- common ones are [DOS](dos.md), [Commodore 64](c64.md), [Amiga](amiga.md) or [Windows](windows.md). These guys simply try to make the coolest visuals and smallest programs, with all good and bad that comes with it. Try to take only the good of it.
 
-The scene is perhaps a bit similar to the culture of street rap, except that there's less improvisation (obviously, making a program takes long) and competition happens between groups rather than individuals. Nevertheless the focus is on competition, originality, style etc. Individuals within a demogroup have roles such as a [programmer](programmer.md), visual artist, music artist, director, even [PR](pr.md) etc.
+Besides "digital graffiti" the scene is also perhaps a bit similar to the culture of street rap, except that there's less improvisation (obviously, making a program takes long) and competition happens between groups rather than individuals. Nevertheless the focus is on competition, originality, style etc. But demos should show off technological skills as the highest priority -- trying to "win by content" rather than programming skills is sometimes frowned upon. Individuals within a demogroup have roles such as a [programmer](programmer.md), visual artist, music artist, director, even [PR](pr.md) etc.
 
-A demo isn't a video, it is a non-[interactive](interactive.md) [real time](real_time.md) executable (even though categories outside of this may also appear). Demos themselves aren't really limited by constraints (well, sometimes a limit such as 4 MB is imposed), it's where the programmers can show off all they have. However compos are often organized for **intros**, demos whose executable size is limited (i.e. NOT the size of the source code, like in [code golfing](golf.md), but the size of the compiled binary). The main categories are 4K intros and 64K intros, rarely also 256K intros (all sizes are in [kibibytes](memory_units.md)). Apparently even such categories as 256 byte intro appear. Sometimes also platform may be specified (e.g. [Commodore 64](c64.md), [PC](pc.md) etc.). The winner of a compo is decided by voting.
+A demo isn't a video, it is a non-[interactive](interactive.md) [real time](real_time.md) executable that produces the same output on every run (even though categories outside of this may also appear). [Viznut](viznut.md) has noted that this "static nature" of demos may be due to the established culture in which demos are made for a single show to the audience. Demos themselves aren't really limited by resource constraints (well, sometimes a limit such as 4 MB is imposed), it's where the programmers can show off all they have. However compos are often organized for **intros**, demos whose executable size is limited (i.e. NOT the size of the source code, like in [code golfing](golf.md), but the size of the compiled binary). The main categories are 4Kib intros and 64Kib intros, rarely also 256Kib intros (all sizes are in [kibibytes](memory_units.md)). Apparently even such categories as 256 [byte](byte.md) intro appear. Sometimes also platform may be specified (e.g. [Commodore 64](c64.md), [PC](pc.md) etc.). The winner of a compo is decided by voting.
 
-Some of the biggest demoparties are or were Assembly (Finland), The Party (Denmark), The Gathering (Norway), Kindergarden (Norway) and Revision (Germany). A guy on https://mlab.taik.fi/~eye/demos/ says that he has never seen a demo [female](female.md) programmer and that females often have free entry to demoparties while men have to pay because there are almost no women anyway xD Some famous demogroups include Future Crew (Finland), Pulse (international), Haujobb (international), Conspiracy (Hungary) and [Razor 1911](razor_1911.md) (Norway).
+Some of the biggest demoparties are or were Assembly (Finland), The Party (Denmark), The Gathering (Norway), Kindergarden (Norway) and Revision (Germany). A guy on https://mlab.taik.fi/~eye/demos/ says that he has never seen a demo [female](female.md) programmer and that females often have free entry to demoparties while men have to pay because there are almost no women anyway xD Some famous demogroups include Farbrausch (Germany, also created a tiny 3D shooter game [.kkrieger](kkrieger.md)), Future Crew (Finland), Pulse (international), Haujobb (international), Conspiracy (Hungary) and [Razor 1911](razor_1911.md) (Norway). { Personally I liked best the name of a group that called themselves *Byterapers*. ~drummyfish } There is an online community of demosceners at at https://www.pouet.net.
 
-**On technological side of demos**: great amount of hacking, exploitation of bugs and errors and usage of techniques going against "good programming practices" are made use of in making of demos. They're usually made in [C](c.md), [C++](cpp.md) or [assembly](assembly.md) (though some retards even make demos in [Java](java.md) [lmao](lmao.md)). In intros it is extremely important to save space wherever possible, so things such as [procedural generation](procgen.md) and [compression](compression.md) are heavily used. Manual [assembly](assembly.md) optimization is common. [Tracker music](tracker_music.md), [chiptune](chiptune.md), [fractals](fractal.md) and [ASCII art](ascii_art.md) are very popular. New techniques are still being discovered, e.g. [bytebeat](bytebeat.md). The final executable is also compressed with [specialized executable compression](executable_compression.md).
+**On technological side of demos**: great amount of hacking, exploitation of bugs and errors and usage of techniques going against "good programming practices" are made use of in making of demos. They're usually made in [C](c.md), [C++](cpp.md) or [assembly](assembly.md) (though some retards even make demos in [Java](java.md) [lmao](lmao.md)). In intros it is extremely important to save space wherever possible, so things such as [procedural generation](procgen.md) and [compression](compression.md) are heavily used. Manual [assembly](assembly.md) optimization for size can take place. [Tracker music](tracker_music.md), [chiptune](chiptune.md), [fractals](fractal.md) and [ASCII art](ascii_art.md) are very popular. New techniques are still being discovered, e.g. [bytebeat](bytebeat.md). [GLSL](glsl.md) shader source code that's to be embedded in the executable has to be minified or compressed. Compiler flags are chosen so as to minimize size, e.g. small size optimization (`-Os`), turning off buffer security checks or turning on fast [float](float.md) operations. The final executable is also additionally compressed with [specialized executable compression](executable_compression.md).
 
 ## See Also
 
 - [code golf](golf.md)
+- [kkrieger](kkrieger.md)
 - [LAN party](lan_party.md)

frameless.md

@@ -6,6 +6,6 @@ Typically this is done with [image order](image_order.md) rendering methods, i.e
 
 The main advantage of frameless rendering is of course saving a huge amount of memory usually needed for double buffering, and usually also increased performance (fewer pixels are processed per second). The animation may also seem more smooth and responsive -- reaction to input is seen faster. Another advantage, and possibly a disadvantage as well, is a **[motion blur](motion_blur.md)** effect that arises as a side effect of updating by individual pixels spread over the screen: some pixels show the scene at a newer time than others, so the previous images kind of blend with the newer ones. This may add realism and also prevent temporal [aliasing](aliasing.md), but blur may sometimes be undesirable, and also the kind of blur we get is "pixelated" and noisy.
 
-Selecting the pixels to update can be done in many ways, usually with some [pseudorandom](pseudorandom.md) selection, but regular patterns may also be used. There have been papers that implemented adaptive frameless rendering that detected where it is best to update pixels to achieve low noise.
+Selecting the pixels to update can be done in many ways, usually with some [pseudorandom](pseudorandom.md) selection ([jittered sampling](jittered_sampling.md), [Halton sequence](halton_sequence.md), Poisson Disk sampling, ...), but regular patterns may also be used. There have been papers that implemented adaptive frameless rendering that detected where it is best to update pixels to achieve low noise.
 
 Historically similar (though different) techniques were used on computers that didn't have enough memory for a double buffer or redrawing the whole screen each frame was too intensive on the CPU; programmers had to identify which pixels had to be redrawn and only update those. This resulted in techniques like *adaptive tile refresh* used in scrolling games such as [Commander Keen](commander_keen.md).