Update

c_tutorial.md

@@ -1683,7 +1683,7 @@ TODO
 
 ## Where To Go Next
 
-We haven't nearly covered the whole of C, but you should have pretty solid basics now. Now you just have to go and write a lot of C programs, that's the only way to truly master C. WARNING: Do not start with an ambitious project such as a 3D game. You won't make it and you'll get demotivated. Start very simple (a Tetris clone perhaps?).
+We haven't nearly covered the whole of C, but you should have pretty solid basics now. Now you just have to go and write a lot of C programs, that's the only way to truly master C. WARNING: Do not start with an ambitious project such as a 3D game. You won't make it and you'll get demotivated. Start very simple (a Tetris clone perhaps?). Try to develop some consistent programming style/formatting -- see our [LRS programming style](programming_style.md) you may adopt (it's better than trying to make your own really).
 
 You should definitely learn about common [data structures](data_strucutre.md) ([linked lists](linked_list.md), [binary trees](binary_tree.md), [hash tables](hash.md), ...) and [algorithms](algorithm.md) ([sorting](sorting.md), [searching](search.md), ...). As an advanced programmer you should definitely know a bit about [memory management](memory_management.md). Also take a look at basic [licensing](license.md). Another thing to learn is some [version control system](vcs.md), preferably [git](git.md), because this is how we manage bigger programs and how we collaborate on them. To start making graphical programs you should get familiar with some library such as [SDL](sdl.md).
 

feminism.md

@@ -4,10 +4,12 @@
 
 Feminism, also feminazism, is a [fascist](fascism.md) [terrorist](terrorism.md) [pseudoleftist](pseudoleft.md) movement aiming for establishing [female](woman.md) as the superior gender, for social revenge on men and gaining political power, e.g. that over [language](political_correctness.md). Similarly to [LGBT](lgbt.md), feminism is violent, [toxic](toxic.md) and [harmful](harmful.md), based on [brainwashing](brainwashing.md), mass hysteria, [bullying](bullying.md) (e.g. the [metoo](metoo.md) campaign) and [propaganda](propaganda.md).
 
-[LMAO](lmao.md), this just sums up the feminist ways: **a supposed woman writer who won 1 million euro prize turned out to actually be three men writers**, see Carmen Mola :)
+[LMAO](lmao.md), this just sums up the feminist ways: **a supposed woman writer who won 1 million euro prize turned out to actually be three men writers**, see Carmen Mola :) Also the recent "historically first all female space walk" at which they managed to lose $100K worth of equipment :D
 
 If anything's clear, then that feminism is not at all about gender equality but about hatred towards men. Firstly feminism is not called *gender equality movement* but *feminism*, i.e. for-female, and as we know, [name plays a huge role](name_is_important.md). To a feminist man is what a [jew](jew.md) was to the Nazi; the whole story is repeated again, we have yet again not learned a bit from our history. Indeed, women have historically been oppressed and needed support, but once women reach social equality -- which has basically already happened a long time ago now -- feminist movement will, if only by [social inertia](social_inertia.md), keep pursuing more advantages for women (what else should a movement called *feminism* do?), i.e. at this point the new goal has already become female superiority. In the age of capital no one is going to just dissolve a movement because it has already reached its goal, such a movement present political capital one will simply not throw out of window, so feminists will forever keep saying they're being oppressed and will forever keep inventing new bullshit issues to keep [fighting](fight_culture.md). Note for example that feminists care about things such as wage gap but of course absolutely don't give a damn about opposite direction inequality, such as men dying on average much younger than women etc. -- feminism cares about women, not equality. And of course, when men establish "men rights" movements, suddenly feminists see those as "fascist", "toxic" and "violent" and try to destroy such movements.
 
+{ I really have no issues with women, I truly love everyone, but I do pay attention to statistics. One of the biggest things feminism achieved for me in this regard is that now it's simply not enough for me to see a woman achieve success in society to be convinced she is skilled or capable, a woman getting PhD to me nowadays automatically just means she got it because she's a woman and we need more quotas of "strong women in SCIENCE". In the past I didn't see it this way, a woman that did something notable a back then was mostly convincing to me. Nowadays I just require much better evidence to believe she is good at something, e.g. seeing something truly good she created -- to be honest, I now don't recall any woman in "modern times" to have convinced me, but I am really open to it and just waiting to be proven wrong. ~drummyfish }
+
 Part of the success of feminism is also [capitalism](capitalism.md) -- women with priviledges, e.g. those of not having to work as much as men, are not accepted under capitalism; everyone has to be exploited as much as possible, everyone has to be a work slave. Therefore capitalist propaganda promotes ideas such as "women not having to work is oppression by men and something a woman should be ashamed of", which is of course laughable, but with enough brainwashing anything can be established, even the most ridiculous and obvious bullshit.
 
 Apparently in Korea feminists already practice segregation, they separate parking spots for men and women so as to prevent women bumping into men or meeting a man late at night because allegedly men are more aggressive and dangerous. Now this is pretty ridiculous, this is exactly the same as if they separated e.g. parking lots for black and white people because black people are statistically more often involved in crime, you wouldn't want to meet them at night. So, do we still want to pretend feminists are not fascist?

lrs.md

@@ -43,6 +43,7 @@ Here are a few bullet points giving further ideas about what LRS is about, also
 - Programs are efficient.
 - No one owns programs, no one owns data, no one owns art, no one owns information. Everything is [free](free.md), legally AND [in any other way](de_facto.md).
 - Use universal interfaces (text), be compatible.
+- No [usercentrism](usercentrism.md): a user is NOT above programmer or any other living being (as it is in [capitalism](capitalism.md)). This means that if e.g. a feature can make user's life 1% better but will enslave additional 10 programmers with perpetual [maintenance](maintenance.md), it should NOT be added.
 - Code is reusable.
 - [Hacking](hacking.md) is good. Allow hacking, allow breaking and raping of your program in ways you didn't intend.
 - Be [portable](portability.md), respect weaker platforms and platforms of other types. 

programming_style.md

@@ -1,32 +1,41 @@
-# Programming Style
+# Programming Style/Code Formatting
 
-Here we discuss a good programming style (formatting, conventions etc.). Remember that nothing is set in stone, the most important thing is to be consistent and actually think about why you're doing things the way you're doing them. Think from the point of view of a programmer who gets just your source code without any way to communicate with you, make his life as easy as possible.
+TODO
 
-## Recommended C Programming Style
+## Recommended LRS C Programming Style/Formatting
 
-This is our recommendation or perhaps just a suggestion/guide on the [C](c.md) programming style.
+Here we propose a programming style and C code formatting you may use in your programs. { It's basically a style I personally adopted and fine-tuned over many years of my programming. ~drummyfish } Remember that nothing is set in stone, the most important thing is usually to be consistent within a single project and to actually think about why you're doing things the way you're doing them. Keeping to the standard set here will gain you advantages such as increased readability for others already familiar with the same style and avoiding running into traps set by short-sighted decisions e.g. regarding identifiers. Try to think from the point of view of a programmer who gets just your source code without any way to communicate with you, make his life as easy as possible. The LRS style/formatting rules follow:
 
-- Respect the [LRS](lrs.md) principles.
+- **Respect the [LRS](lrs.md) design principles** ([KISS](kiss.md), no [OOP](oop.md), avoid dependencies such as [stdlib](stdlib.md) etc.).
-- Use **two spaces** for indentation. **Do not use [tabs](tab.md)!** Tabs are ugly, tricky non-standard behaving characters.
+- **Indentation: use two spaces, NEVER use [tabs](tab.md)**. Why? Tabs are ugly, tricky (look the same as spaces) non-standard behaving characters (behavior is dependent on editor and settings, some processors will silently convert tabs and spaces, copy-paste may do so also etc.), they don't carry over to some platforms (especially paper); your source will contain spaces either way, no need to insert additional blank character.
-- **Format to 80** columns or a similar width. Keep in mind the source may be edited on computers with small screens (like old [thinkpads](thinkpad.md)) with a screen split vertically.
+- **Limit source code width to 80** columns or similar value. Keep in mind the source may be edited on computers with small screens (like old [thinkpads](thinkpad.md), especially withing context of LRS) with a screen split vertically.
-- Write **opening and closing curly brackets on its own line, in the same columns**, e.g.:
+- Write **opening and closing curly brackets on their own lines, in the same columns**, e.g.:
 
 ```
 if (a == b)
 {
   doSomething();
+  doSomething2();
+}
+else
+{
   doSomethingElse();
+  doSomethingElse2();
 }
 ```
 
-- Prefer not writing curly brackets if you don't have to (e.g. with a single command in the block). You may still do it in tricky cases like nested branches.
+- **Omit curly brackets if you can** (e.g. with a single command in the block). However write them where not doing so is likely to cause confusion or syntax errors.
-- **naming**:
+- **Use normal brackets to make precedence and intention clearer** even if they would be unnecessary, don't flex by writing an expression with confusing precedence that saves 4 text characters. For example it may be better to write `(a && b) || c` rather than `a && b || c`.
-  - **camelCase for variables and functions** (like `myVariable`). Global and big-scope variables should have a descriptive, self-documenting name (e.g. `getTicksSinceStart`), local/short-scope ones can be just one letter.
+- **identifiers/names**:
-  - **CapitalCamelCase for data types** (like `ImaginaryNumber`).
+  - **Use `camelCase` for variables and functions** (e.g. `myVariable`). Global and big-scope variables should have a greatly descriptive, self-documenting name, even if long (e.g. `getTicksSinceStart`, `countryAreaKMSquared`), local/short-scope identifiers can be shorter (e.g. `argBackup` within a single function), even just one letter (e.g. `i` within a single loop).
-  - **ALL_CAPS_SNAKE_CASE for macros and constants** (like `PI` or `MY_MACRO`).
+  - **Use `CapitalCamelCase` for data types** (e.g. `ImaginaryNumber`, `GameState` etc.).
-  - It is advised that for your project you come up with a **three letter namespace prefix** that will come in front of your global identifiers. (E.g. [small3dlib](small3dlib.md) uses the prefix `S3L_`, [SDL](sdl.md) uses `SDL` etc.). If you choose a prefix `XYZ_`, prepend it to all global identifiers, it will prevent name clashes and help readability.
+  - **Use `ALL_CAPS_SNAKE_CASE` for macros and constants** (e.g. `PI`, `MIN`, `LOG_ERROR`, ...).
-  - **Prefix private global identifiers with `_`**, e.g. `_myInternalVar`.
+  - It is advised that for your project you come up with a **three letter namespace prefix** that will come in front of your global identifiers. (E.g. [small3dlib](small3dlib.md) uses the prefix `S3L_`, [SDL](sdl.md) uses `SDL` etc.). If you choose a prefix `XYZ_`, prepend it to all global identifiers, it will prevent name clashes and help readability, e.g. when writing a renderer you will export identifiers such as `XYZ_init`, `XYZ_draw`, `XYZ_setPixel`, `XYZ_Model3D` etc. Do NOT use the prefix in local variables (inside functions, loops etc.).
+  - **Prefix private global identifiers with `_`**, e.g. `_tmpPointerBackup`; with the above mentioned namespace prefix this will look e.g. like this: `_XYZ_tmpPointerBackup`. 
 - **Use spaces** to make code more readable, so e.g. `int x = 10, y = 20;` instead of `int x=10,y=20;`, write space between `if` and its condition etc.
+- **Use verbs for [functions](function.md), nouns for variables** and keep consistency, e.g. a function should be named `getTimeMS` while a variable will be named `timeMS`.
+- **Name from general to specific**, e.g. `getCountryTimezone` and `getCountryCapital` instead of `getTimeZoneOfCountry`, `getCapitalOfCountry` etc. This helps with code completion systems. It's not always exactly clear, you may also decide to go for `countryGetTimezone` etc., just keep it consistent.
+- **Filenames**: always use only lowercase letters (some older systems just know one case, don't confuse them), either use `camel_case.ext` or `nocase.ext`.
 - **Use blank lines** to logically group relevant lines of code. E.g.:
 
 ```
@@ -37,14 +46,25 @@ c += 3 * a;
 d -= b;
 
 if (c < d)
-a = b;
+  a = b;
+  
+doSomething(a);
 ```
 
-- Each file shall have a **global [comment](comment.md)** with at least: short description of the file's purpose (this is almost always missing), [license](license.md), the author(s) and year of creation.
+- Each file shall have a **global [comment](comment.md)** at the top with at least: short description of the file's purpose (this is almost always missing in mainstream), short documentation, [license](license.md), the author(s) and year of creation.
-- **Use [comments](comment.md)** to make your code better readable and searchable (add keywords to relevant parts of code etc.).
+- **Use [comments](comment.md)** to make your code better readable and searchable with things like [grep](grep.md) (add keywords to relevant parts of code, e.g. comment `// player shoots` to code implementing player shooting etc.). **Use [doxygen](doxygen.md) style comments** if you can, it costs nothing and allows auto documentation.
+- **TODOs and WIPs are good**.
 - **Don't use [enums](enum.md)**, use `#define`s.
-- **Global variables are great**, use them. **Long functions are fine**.
+- **Global variables are great**, use them. **Long functions are fine**. Repeating yourself may also be fine if the alternative is too complex.
 - **Adhere to C99  or C89 standard**.
 - **Try to not create many source files**, many times your project can very well be in a single file which is the ideal case. Create **[header only libraries](header_only.md)** If you have multiple files, keep them in the same directory and try to have just a **[single compilation unit](single_compilation_unit.md)** (only one .c file with several .h files). Try to make files no longer than 10k lines.
 - **Use the LRS [version numbering](version_numbering.md) system**.
-- **Do not use non-ASCII characters in the source code**.
+- **Never use non-[ASCII](ascii.md) characters in your source code**. Just don't, there is basically never any need for it.
+
+### Example
+
+Here is a short example applying the above shown style:
+
+```
+TODO (for now see LRS projects like Anarch, small3dlib, SAF etc.)
+```

programming_tips.md

@@ -4,9 +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.
+- **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.
 - **[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, 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.
 - TODO: moar

sw_rendering.md

@@ -39,21 +39,25 @@ Possible tricks, cheats and [optimizations](optimization.md) you may utilize inc
 These are some notable software renderers:
 
 - **[Build engine](build_engine.md)**: So called ["pseudo 3D"](pseudo_3d.md) or primitive 3D, this was a very popular [proprietary](proprietary.md) portal-rendering engine for older games like [Duke Nukem 3D](duke3d.md) or [Blood](blood.md).
-- **[BRender](brender.md)**: Old commercial renderer used in games such as Carmageddon, Croc or Harry Potter 1. Later made [FOSS](foss.md).
+- **[BRender](brender.md)**: Old commercial renderer used in games such as Carmageddon, Croc or [Harry Potter](harry_potter.md) 1. Later made [FOSS](foss.md).
-- **[Chasm: The Rift](chasm_the_rift.md) engine**: proprietary 1997 renderer made specifically for one game, notable especially by being a hybrid of "2.5D" and "true 3D", it managed to make it look very good.
+- **[Chasm: The Rift](chasm_the_rift.md) engine**: Mysterious proprietary 1997 renderer made specifically for one game, notable especially by being a hybrid of "2.5D" and "true 3D", it managed to make it look very good.
 - **[Dark Engine](dark_engine.md)**: Old proprietary game engine which includes a SW renderer, used mainly in the game Thief. The author writes about it at https://nothings.org/gamedev/thief_rendering.html.
+- **[Descent](descent.md) engine**: The 1995 proprietary game Descent featured one of the first real time "[true 3D](true3d.md)" engines based on [portal rendering](portal_rendering.md), it still stands as a marble of that time's technology.
 - **[id Tech](id_tech.md)**: Multiple engines by [Id software](id.md) (later made [FOSS](foss.md)) used for games like [Doom](doom.md), [Quake](quake.md) and its successors included a software renderer. Quake's SW renderer was partially described in the *Michael Abrash's Graphics Programming Black Book*, Doom's renderer is described e.g. in the book *Game Engine Black Book DOOM*.
 - **[Irrlich](irrlicht.md)**: [FOSS](foss.md) game engine including a software renderer as one of its [backends](backend.md).
 - **[Jedi](jedi_engine.md)**: Old proprietary "pseudo3D" engine.
 - **[Mesa](mesa.md)**: [FOSS](foss.md) implementation of [OpenGL](opengl.md) that includes a software rasterizer.
-- **[small3dlib](small3dlib.md)**: [LRS](lrs.md) [C](c.md) 3D rasterizer, very simple.
+- **[raycastlib](raycastlib.md)**: [LRS](lrs.md) [C](c.md) 2D raycasting ("2.5D") engine most notably used in [Anarch](anarch.md).
+- **[small3dlib](small3dlib.md)**: [LRS](lrs.md) pure [C](c.md) "true 3D" rasterizer, very simple but flexible and coming with all the high level features (textures, perspective correction etc.).
 - **[SSRE](ssre.md)**: The guy who wrote [LIL](lil.md) also made this renderer named Shitty Software Rendering Engine, accessible [here](http://runtimeterror.com/tech/ssre/).
 - **[System Shock](system_shock.md) engine**: Old proprietary game engine.
 - **[TinyGL](tinygl.md)**: Implements a subset of [OpenGL](opengl.md).
-- In general many old [games](game.md) in the 90s implemented their own software renderers, so you can look there.
+- **[Ultima underworld](ultima_underworld.md)**: Proprietary game featuring a very early (1992) texture mapped software 3D renderer.
+- **old [Unreal Engine](unreal_engine.md)**: One of the most mainstream popular proprietary engines nowadays featured software rendering fallbacks in early versions.
+- In general many old [games](game.md) in the 90s implemented their own software renderers. Also games on non-3D consoles such as [Gameboy Advance](gba.md) sometimes attempted simple software rendering 3D. These are the places where you can look for interesting renderers of this kind.
 - ...
 
 ## See Also
 
 - [3D rendering](3d_rendering.md)
-- [pseudo/primitive 3D, 2.5D](pseudo3d.md)
+- ["pseudo/primitive 3D, 2.5D"](pseudo3d.md)

wiki_style.md

@@ -42,6 +42,7 @@ These are some sources you can use for research and gathering information for ar
 - **Britannica online**: proprietary, but articles are nicely written, facts are in the public domain so we can steal them.
 - **Archives: [Internet Archive](internet_archive.md), [Archive Team Wiki](https://wiki.archiveteam.org/), [archive.li](https://archive.li/), ...**: Most information once available on the Internet is most likely no longer accessible nowadays (taken down, privatized, censored, no longer indexed, ...). Look in the archives!
 - **[wikiwikiweb](wikiwikiweb.md)**
+- **Ask people lol**: sometimes you can't find a piece of information anywhere (for example which rendering technique was used in an old proprietary game) but if you just send a short mail to someone (the game's programmer), he just gives you the information in a second. People often just forget this and spend countless hours digging for something when they can just write one email.
 - **[Wiby](wiby.md), marginalia and other non-commercial search engines**: this will find nice small non-commercial sites of tech and other nerds that Google suffocates under bloatsites (or simply censors)
 - **[Project Gutenberg](gutenberg.md)**: mostly older books but there are already some computer related books like [RMS's](rms.md) biography or [Jargon File](jargon_file.md)
 - **University theses** (and scientific paper of course): many university theses are publicly accessible and usually nicely sum up topics, bachelor level theses may be better understandable than PhD/master theses.