C++ is an [object-obsessed](oop.md) [joke](jokes.md) language based on [C](c.md) to which it adds only [capitalist](capitalist_software.md) features and [bloat](bloat.md), most notably [object obsession](oop.md). Most good programmers such as [Richard Stallman](rms.md) and [Linus Torvalds](linus_torvalds.md) agree that C++ is hilariously messy and also tragic in that it actually succeeded to become mainstream. The language creator [Bjarne Stroustrup](stroustrup.md) himself infamously admitted the language suck but laughs at its critics because it became successful anyway -- indeed, in a retarded society only [shit](shit.md) can succeed. As someone once said, "C++ is not an increment, it is excrement".
C++ (also crippled C) is an [object-obsessed](oop.md) [joke](jokes.md) language based on [C](c.md) to which it adds only [capitalist](capitalist_software.md) features and [bloat](bloat.md), most notably [object obsession](oop.md). Most good programmers such as [Richard Stallman](rms.md) and [Linus Torvalds](linus_torvalds.md) agree that C++ is hilariously messy and also tragic in that it actually succeeded to become mainstream. The language creator [Bjarne Stroustrup](stroustrup.md) himself infamously admitted the language suck but laughs at its critics because it became successful anyway -- indeed, in a retarded society only [shit](shit.md) can succeed. As someone once said, "C++ is not an increment, it is excrement".
Doom is a legendary video [game](game.md) released in December [1993](1990s.md), perhaps the most famous video game of all time, the game that popularized the [first person shooter](first_person_shooter.md) genre and shocked by its at the time extremely advanced [3D](pseudo_3D.md) graphics (yes, it was actually 3D) and caused one the biggest revolutions in video game history. It was made by [Id Software](id_software.md), most notably by [John Carmack](john_carmack.md) (graphics + engine programmer) and [John Romero](john_romero.md) (tool programmer + level designer). Doom is sadly [proprietary](proprietary.md), it was originally distributed as [shareware](shareware.md) (a free "demo" was available for playing and sharing with the option to buy a full version). However the game engine was later (1999) released as [free (as in freedom) software](free_software.md) under [GPL](gpl.md) which gave rise to many source [ports](port.md). The assets remain non-free but a completely free alternative is offered by the [Freedoom](freedoom.md) project that has created [free as in freedom](free_culture.md) asset replacements for the game. [Anarch](anarch.md) is an official [LRS](lrs.md) game inspired by Doom, completely in the [public domain](public_domain.md).
Doom is a legendary video [game](game.md) released in December [1993](1990s.md), perhaps the most famous video game of all time, the game that popularized the [first "person" shooter](first_person_shooter.md) genre and shocked by its at the time extremely advanced [3D](pseudo_3D.md) graphics (yes, **Doom is 3D**) and caused one the biggest revolutions in video game history. It was made by [Id Software](id_software.md), most notably by [John Carmack](john_carmack.md) (graphics + engine programmer) and [John Romero](john_romero.md) (tool programmer + level designer). Doom is sadly [proprietary](proprietary.md), it was originally distributed as [shareware](shareware.md) (a free "demo" was available for playing and sharing with the option to buy a full version). However the game engine was later (1999) released as [free (as in freedom) software](free_software.md) under [GPL](gpl.md) which gave rise to many source [ports](port.md) and "improved" "[modern](modern.md)" engines (which however look like shit, the original looks by far the best, if you want to play Doom use Chocolate Doom or Crispy Doom, avoid anything with GPU rendering). The assets remain non-free but a completely free alternative is offered by the [Freedoom](freedoom.md) project that has created [free as in freedom](free_culture.md) asset replacements for the game. [Anarch](anarch.md) is an official [LRS](lrs.md) game inspired by Doom, completely in the [public domain](public_domain.md).
{ Great books about Doom I can recommend: *Masters of Doom* (about the development) and *Game Engine Black Book: Doom* (details about the engine internals). ~drummyfish }
@ -10,10 +10,14 @@ The major leap that Doom engine's graphics brought was unprecedented, however Do
The game's backstory was simple and didn't stand in the way of gameplay, it's basically about a tough marine (so called *Doomguy*) on a Mars military base slaying hordes of demons from hell, all in a rock/metal style with a lot of gore and over-the-top violence (chain saws n stuff).
LOL someone created a Doom system monitor for [Unix](unix.md) systems called [psDooM](psdoom.md) where the monsters in game are the operating system [processes](process.md) and killing the monsters kills the processes.
Doom was followed by Doom II in 1995, which "content-wise" was basically just a data disc, the same game with new levels and some minor additions. Later there were some other releases and rereleases, notable is Doom III from 2004, Doom 2016 ("reboot") and Doom: Eternal (2020).
Some **[interesting](interesting.md) things** about Doom:
- Someone created a Doom system monitor for [Unix](unix.md) systems called [psDooM](psdoom.md) where the monsters in game are the operating system [processes](process.md) and killing the monsters kills the processes.
- Someone (kgsws) has been [hacking](hacking.md) the ORIGINAL Doom engine in an impressive way WITHOUT modifying the source code or the binary, rather using [arbitrary code execution](arbitrary_code_execution.md) bug; he added very advanced features known from newer source ports, for example an improved 3D rendering algorithms allowing geometry above geometry etc. (see e.g. https://yt.artemislena.eu/watch?v=RdbRPNPUWlU).
- TODO
## Doom Engine/Code
*See also [game engine](game_engine.md) for the list of different Doom engines.*
@ -22,7 +26,7 @@ Doom source code is written in [C89](c.md) and is about 36000 [lines of code](lo
The game only used [fixed point](fixed_point.md), no [float](float.md)!
The **Doom engine** was revolutionary and advanced (not only but especially) video game graphics by a great leap, considering its predecessor [Wolf3D](wolf3D.md) was really primitive in comparison (Doom basically set the direction for future trends in games such as driving the development of more and more powerful [GPUs](gpu.md) in a race for more and more impressive visuals). Doom used a technique called **[BSP rendering](bsp.md)** (levels were made of convex 2D sectors that were then placed in a BSP tree which helped quickly sort the walls for rendering front-to-back) that was able to render [realtime](realtime.md) 3D views of textured (all walls, floors and ceilings) environments with primitive lighting (per-sector plus diminishing lighting), enemies and items represented by 2D [billboards](billboard.md) ("[sprites](sprite.md)"). No [GPU](gpu.md) acceleration was used, graphics was rendered purely with [CPU](cpu.md) (so called [software rendering](sw_rendering.md), GPU rendering would come with Doom's successor [Quake](quake.md), and would also later be brought to Doom by newer community made engines, though the original always looks the best). This had its limitations, for example the camera could not look up and down, there could be no tilted walls and the levels could not have rooms above other rooms. The geometry of levels was only static, i.e. it could not change during play (only height of walls could), because rendering was dependent on precomputed BSP trees (which is what made it so fast). For these reasons some call Doom "[pseudo 3D](pseudo3d.md)" or 2.5D rather than "true 3D". Nevertheless, though with limitations, Doom did present 3D views and internally it did work with 3D coordinates (for example the player or projectiles have 2D position plus height coordinate), despite some dumb YouTube videos saying otherwise. For this reason we prefer to call Doom a **primitive 3D** engine, but 3D nonetheless. Other games later used the Doom engine, such as Heretic, Hexen and Strife. The Doom engine was similar to and competing with [Build](build_engine.md) engine that ran games like [Duke Nukem 3D](duke_3d.md), Blood and Shadow Warrior. All of these 90s shooters were amazing in their visuals and looked far better than any [modern](modern.md) shit. Build engine games had similar limitations to those of the Doom engine but would improve on them (e.g. faking looking up and down by camera tilting, which could in theory be done in Doom too, or allowing sloped floor and dynamic level geometry).
The **Doom engine** was revolutionary and advanced (not only but especially) video game graphics by a great leap, considering its predecessor [Wolf3D](wolf3D.md) was really primitive in comparison (Doom basically set the direction for future trends in games such as driving the development of more and more powerful [GPUs](gpu.md) in a race for more and more impressive visuals). Doom used a technique called **[BSP rendering](bsp.md)** (levels were made of convex 2D sectors that were then placed in a BSP tree which helped quickly sort the walls for rendering front-to-back) that was able to render [realtime](realtime.md) 3D views of textured (all walls, floors and ceilings) environments with primitive lighting (per-sector plus diminishing lighting), enemies and items represented by 2D [billboards](billboard.md) ("[sprites](sprite.md)"). No [GPU](gpu.md) acceleration was used, graphics was rendered purely with [CPU](cpu.md) (so called [software rendering](sw_rendering.md), GPU rendering would come with Doom's successor [Quake](quake.md), and would also later be brought to Doom by newer community made engines, though the original always looks the best). This had its limitations, for example the camera could not look up and down, there could be no tilted walls and the levels could not have rooms above other rooms. The geometry of levels was only static, i.e. it could not change during play (only height of walls could), because rendering was dependent on precomputed BSP trees (which is what made it so fast). For these reasons some call Doom "[pseudo 3D](pseudo3d.md)" or 2.5D rather than "true 3D", some retards took this even as far as calling Doom 2D with its graphics being just an "illusion", as if literally every 3D graphics ever wasn't a mere illusion. Nevertheless, though with limitations, Doom did present 3D views and internally it did work with 3D coordinates (for example the player or projectiles have 2D position plus height coordinate), despite some dumb YouTube videos saying otherwise. For this reason we prefer to call Doom a **primitive 3D** engine, but 3D nonetheless. Other games later used the Doom engine, such as Heretic, Hexen and Strife. The Doom engine was similar to and competing with [Build](build_engine.md) engine that ran games like [Duke Nukem 3D](duke_3d.md), Blood and Shadow Warrior. All of these 90s shooters were amazing in their visuals and looked far better than any [modern](modern.md) shit. Build engine games had similar limitations to those of the Doom engine but would improve on them (e.g. faking looking up and down by camera tilting, which could in theory be done in Doom too, or allowing sloped floor and dynamic level geometry).
Indexed ([palette](palette.md)) mode with "only" 256 colors was used for rendering. Precomputed color tables were used to make dimming of colors faster.
Fork is a branch that splits from the main branch of a project and continues to develop in a different direction as a separate version of that project, possibly becoming a completely new one. This may happen with any "intellectual work" or idea such as [software](software.md), movement, theory, literary universe, religion or, for example, a [database](database.md). Forks may later be *merged* back into the original project or continue and diverge far away, forks of different projects may also combine into a single project as well.
In technology forking generally means splitting, or better said duplicating an abstract entity (such as a computer process or development project) into two or more such entities so that each one can from then on develop differently; this is very similar to how biological cells duplicate by splitting. The term *fork* is used in many contexts, for example in software development (project forking), in [operating systems](operating_system.md) ([process](process.md) forking), in [cryptocurrencies](crypto.md) (blockchain forking), [nondeterministic](determinism.md) computing (computation forking) etc.
## Project Forking
In context of projects fork is a branch that splits from the main branch of a project and continues to develop in a different direction as a separate version of that project, possibly becoming a completely new one. This may happen with any "intellectual work" or idea such as [software](software.md), movement, theory, literary universe, religion or, for example, a [database](database.md). Forks may later be *merged* back into the original project or continue and diverge far away, forks of different projects may also combine into a single project as well.
For example the [Android](android.md) [operating system](os.md) and [Linux-libre](linux_libre.md) [kernel](kernel.md) have both been forked from [Linux](linux.md). [Linux distributions](distro.md) highly utilize forking, e.g. [Devuan](devuan.md) or [Ubuntu](ubuntu.md) and [Mint](mint.md) are forked from [Debian](debian.md). [Free software movement](free_software.md) was forked into [open source](open_source.md), [free culture](free_culture.md) and [suckless](suckless.md), and suckless was more or less forked into [LRS](lrs.md). [Wikipedia](wikipedia.md) also has forks such as [Metapedia](metapedia.md). [Memes](meme.md) evolve a lot on the basis of forking.
@ -15,4 +19,10 @@ There are two main kinds of forks:
**Is forking good?** Yes, to create anything new it is basically necessary to build on top of someone else's work, stand on someone else's shoulders. Some people criticize too much forking; for example some cry about [Linux](linux.md) [distro](distro.md) fragmentation, they say there are too many of distros and that people should rather focus their energy on creating a single or at least fewer good operating systems, i.e. that forking is kind of "wasting effort". [LRS](lrs.md) supports any kind of wild forking and experimentation, we believe the exploration of many directions to be necessary in order to find the right one, in a [good society](less_retarded_society.md) waste of work won't be happening -- that's an issue of a [competitive society](capitalism.md), not forking.
In fact we think that (at least soft) forking should be incorporated on a much more basic level, in the way that the [suckless](suckless.md) community popularized. In suckless **everyone's copy of software is a personal fork**, i.e. software is distributed in source form and is so extremely easy to compile and modify that every user is supposed to do this as part of the installation process (even if he isn't a programmer). Before compilation user applies his own selected patches, custom changes and specific configuration (which is done in the source code itself) that are unique to that user and which form source code that is the user's personal fork. Some of these personal forks may even become popular and copied by other users, leading to further development of these forks and possible natural rise of very different software. This should lead to natural selection, survival and development of the good and useful forks.
In fact we think that (at least soft) forking should be incorporated on a much more basic level, in the way that the [suckless](suckless.md) community popularized. In suckless **everyone's copy of software is a personal fork**, i.e. software is distributed in source form and is so extremely easy to compile and modify that every user is supposed to do this as part of the installation process (even if he isn't a programmer). Before compilation user applies his own selected patches, custom changes and specific configuration (which is done in the source code itself) that are unique to that user and which form source code that is the user's personal fork. Some of these personal forks may even become popular and copied by other users, leading to further development of these forks and possible natural rise of very different software. This should lead to natural selection, survival and development of the good and useful forks.
@ -107,6 +107,8 @@ Some games are pretty based as they don't even require [GUI](gui.md) and are onl
Another kind of cool games are computer implementations of non-computer games, for example [chess](chess.md), [backgammon](backgammon.md), [go](go.md) or various card games. Such games are very often well tested and fine-tuned gameplay-wise, popular with active communities and therefore [fun](fun.md), yet simple to program with many existing free implementations and good AIs (e.g. GNU chess, GNU go or [Stockfish](stockfish.md)). What's more, they are also many times completely [public domain](public_domain.md)!
{ There is a great lost world of nice old-style games that used to be made for old dumb phones with [Java](java.md) (J2ME) -- between about 2000 and 2010 there were tons and tons of quality Java mobile games that had e.g. entire magazines dedicated solely to them. These games are mostly lost and impossible to find, even videos of them, but if you can somehow get your hands on some of those old magazines, you're in for a great nostalgia trip. ~drummyfish }
### Games As LRS
Computer games can be [suckless](suckless.md) and just as any other software should try to adhere to the [Unix philosophy](unix_philosophy.md). A [LRS](lrs.md) game should follow all the principles that apply to any other kind of such software, for example being completely [public domain](public_domain.md) or aiming for high [portability](portability.md) and getting [finished](finished.md). This is important to mention because, sadly, many people see games as some kind of exception among software and think that different technological or moral rules apply -- this is wrong.
Gopher is a network [protocol](protocol.md) for publishing, browsing and downloading files and is known as a much simpler alternative to the [World Wide Web](www.md) (i.e. to [HTTP](http.md) and [HTML](html.md)). In fact it competed with the Web in its early days and even though the Web won in the mainstream, gopher still remains used by a small communities (however the more dedicated, see e.g. [bitreich](bitreich.md)). Gopher is like the Web but well designed, it is the [suckless](suckless.md)/[KISS](kiss.md) way of doing what the Web does, it contains practically no [bloat](bloat.md) and so [we](lrs.md) highly advocate its use. Gopher inspired creation of [Gemini](gemini.md), a similar but bit more complex and "[modern](modern.md)" protocol, and the two together have recently become the main part of so called [Smol Internet](smol_internet.md). Gopher is much better than Gemini though.
As of 2022 the Veronica search engine reported 343 gopher servers in the world with 5+ million indexed selectors. As of 2023 the Gopher LAWN directory (made by [bitreich](bitreich.md)) contains 281 selected quality gopher holes.
As of 2023 the Veronica search engine reported 315 gopher servers in the world with 5+ million indexed selectors. Quarry search engine reports 369 servers and 1+ million indexed selectors. Gopher LAWN directory (made by [bitreich](bitreich.md)) contains 281 selected quality gopher holes.
Gopher **doesn't use any [encryption](encryption.md)**. This is good, encryption is [bloat](bloat.md). Gopher also **only uses [ASCII](ascii.md)**, i.e. there's no [Unicode](unicode.md). That's also good, Unicode is bloat (and mostly serves trannies to insert emojis of pregnant men into readmes, we don't need that). Gopher simple design is intentional, the authors deemed simplicity a good feature. Gopher is so simple that you may very well write your own client and server and comfortably use them (it is also practically possible to browse gopher without a specialized client, just with standard [Unix](unix.md) [CLI](cli.md) tools).
@ -4,8 +4,9 @@ This is a place for sharing some practical programming tips.
- **Add by small steps**: When adding features/functionality etc. into your code, do it by very small steps and test after each step. Do NOT add multiple things at once. If you add 3 features at once and then find out the program doesn't work, you will have an extremely hard time finding out the bug because it may be in feature 1, feature 2, feature 3 or ANY COMBINATION of them, so you may very well never find the bug. If you instead test after adding each step, you find potential bugs immediately which will make fixing them very quick and easy.
- **No indentation for temporary code**: Tiny "workflow" tip: when adding new code, keep it unindented so that you know it's the newly added code and can delete it at any time. Only when you test the added code, indent it correctly to incorporate it as the final code. Of course, this fails in languages where indentation matters ([Python](python.md) cough cough) but similar effects can be achieved e.g. by adding many empty lines in front of/after the temporary code.
- **Comments/preprocessor to quickly hide code**: It is a basic trick to comment out lines of code we want to temporarily disable. However preprocessor may work even better, e.g. in C if you want to be switching between two parts of code, instead of constantly commenting one part and uncommenting the other just use `#if 0` and `#else` directives around the two parts. You can switch between them by just changing 0 to 1 and back. This can also disable parts of code that already contain multiline comments (unlike a comment as nested multiline comments aren't allowed).
- **[Comments](comment.md)/[preprocessor](preprocessor.md) to quickly hide code**: It is a basic trick to comment out lines of code we want to temporarily disable. However preprocessor may work even better, e.g. in C if you want to be switching between two parts of code, instead of constantly commenting one part and uncommenting the other just use `#if 0` and `#else` directives around the two parts. You can switch between them by just changing 0 to 1 and back. This can also disable parts of code that already contain multiline comments (unlike a comment as nested multiline comments aren't allowed).
- **[KEEP IT SIMPLE](kiss.md)** and keep it [LRS](lrs.md), do not blindly follow mainstream ways and "workflows" as those are more often than not horrible. For example instead of using some uber bug tracker, you should use a simple plaintext TODO.txt file; instead of using and IDE use [vim](vim.md) or something similar. Stay away from [OOP](oop.md), [dependencies](dependency.md) etc.
- **Don't listen to advice of anyone who does programming for living**, he's most definitely accustomed to the worst ways of programming and will try to push you to [OOP](oop.md), [bloat](bloat.md), [proprietary](proprietary.md) tech, [tranny software](tranny_software.md), [GitHub](github.md) etc. Listening to advice of such people is like taking advice on whether to take drugs from a drug dealer.
- **Most true programming is done away from the computer** -- soydevs think that a good programmer just spends hours in front of a computer bashing the keyboard and drinking litres of coffee to stay alive and [PRODUCTIVE](productivity_cult.md); indeed, they usually do, but they are not good programmers, their time is spent slaving the computer doing [maintenance](maintenance.md), debugging, updating and socializing on Twitter. A good programmer actually programs everywhere: when going for walk, before falling asleep, when watching a movie etc. He only starts writing a serious program after years of thinking about it and already having most of it programmed in his head; sitting in front of a computer and writing the algorithm down is only the final smaller part of the journey.
- **Most true programming is done away from the computer** -- soydevs think that a good programmer just spends hours in front of a computer bashing the keyboard and drinking litres of coffee to stay alive and [PRODUCTIVE](productivity_cult.md); indeed, they usually do, but they are not good programmers, their time is spent slaving the computer doing [maintenance](maintenance.md), debugging, googling, updating and socializing on Twitter. A good programmer actually programs everywhere: when going for walk, before falling asleep, when sleeping, when watching a movie etc. He only starts writing a serious program after years of thinking about it and already having most of it programmed in his head; sitting in front of a computer and writing the algorithm down is only the final smaller part of the journey.
- **Program on a weak computer**, this will "force" you to make your program efficient (and learn [how to do it](optimization.md)), any inefficiency will be immediately apparent as your program will simply run slow or swap. Small [embedded](embedded.md) devices such as [open consoles](open_console.md) are ideal.
