Update

bbs.md

@@ -20,3 +20,4 @@ The first BBS was CBBS (computerized bulletin board system) created by Ward Chri
 - [Usenet](usenet.md)
 - [modem world](modem_world.md)
 - [tildeverse](tildeverse.md)
+- [multi user dungeon](mud.md)

doom.md

@@ -38,5 +38,6 @@ There is no [antialiasing](antialiasing.md) in the engine, i.e. aliasing can be
 ## See Also
 
 - [Duke 3D](duke3d.md)
+- [Jedi engine](jedi_engine.md)
 - [Build engine](build_engine.md)
 - [raycasting](raycasting.md)

duke3d.md

@@ -18,3 +18,4 @@ Duke ran on **[Build](build.md) engine**, a legendary [software rendering](sw_re
 
 - [Doom](doom.md)
 - [Anarch](anarch.md)
+- [Jedi engine](jedi_engine.md)

game_engine.md

@@ -40,6 +40,7 @@ The following are some notable game engines.
     - **id Tech 5**: 3D engine used e.g. in Rage and some shitty Wolfenstein games.
     - **id Tech 6**: 3D engine adding [Vulkan](vulkan.md) support, used e.g. in Doom 2016.
     - **id Tech 7**: 3D engine used e.g. in Doom: Eternal.
+  - **[Jedi engine](jedi_engine.md)**: old 90s "2.5D/Pseudo3D" engine best known for being used in *Dark Forces * (Star Wars game).
   - **[GameMaker](gamemaker.md)**: Laughable toy for non-programmers.
   - **[RAGE](rage.md)**: 3D open-world engine developed and used by [Rockstar](rockstar.md) for games such as [GTA](gta.md).
   - **[Source](source_engine.md)**: 3D engine by [Valve](valve.md) used in games such as [Half Life 2](half_life2.md).

jedi_engine.md

@@ -0,0 +1,3 @@
+# Jedi Engine
+
+Jedi engine is an old (1995) [proprietary](proprietary.md)/closed source ["2.5D"/"Pseudo3D"/primitive3D](pseudo3d.md) [game engine](game_engine.md) best known for being used in games Star Wars: Dark Forces and Outlaws. It was mostly notable for its at the time advanced 3D rendering that was similar to previously released [Doom](doom.md) but yet a bit slightly improved, e.g. by adding features like room-above-room and fake looking up/down. There is a "modern" [FOSS](foss.md) rewrite of the engine using "true 3D" and [GPU](gpu.md) accelerated rendering, called the *Force engine*; the original Jedi engine's source code isn't available so its internal working is not known exactly; some suspected the developers to have reverse engineer the Doom engine and copied how it worked, however work on the Jedi engine began before Doom was released and the Jedi engine seems to work on the principle of [portal rendering](portal_rendering.md) (technique used in [Duke Nukem](duke3d.md)'s Build engine), unlike Doom which used [BSP](bsp.md) rendering. { This seems to be confirmed by the Force engine's dev on his blog and by one Russian video on YouTube. ~drummyfish }

mud.md

@@ -0,0 +1,3 @@
+# Multi User Dungeon
+
+TODO

needed.md

@@ -16,7 +16,7 @@ Here is a list of some projects and project ideas which we, [LRS](lrs.md), need
 | artificial human language              | hard?      |                                 |              | thinking bout it    |need LRS lang., big problems with definitions of words tho, think| Esperanto, Lojban, ...    |
 | audio/music editor                     | mid/hard?  |                                 |              |                     | for waveforms and/or MIDI (tracker music), can even be CLI/TUI  | Audacity, LMMS, ...       |
 | Arduino/Pokitto/... computer           | mid/hard?  |                                 |              |                     | until we have PD computer, we'll need a nice tiny embedded comp.|                           |
-| [BSP](bsp.md) "pseudo 3D" renderer (C) | mid/hard?  |                                 |              |                     | for Anarch II? :)                                               | Doom engine, BUILD        |
+| [portal renderer](portal_rendering.md) | mid/hard?  |                                 |              |                     | for Anarch II? :)                                               | Doom engine, BUILD        |
 | chat software                          | mid?       | dumbchat                        | drummyfish   | one done            | make it KISS, no encryption, no Unicode, ... just chat!         | IRC                       |
 | [chatbot](chatbot.md)                  | mid?       |                                 |              | plans in my head    | probably NOT neural net, KISS lib for good enough chatbot       |                           |
 | [chess](chess.md) engine/library (C)   | mid/hard   |[smallchesslib](smallchesslib.md)| drummyfish   | done                | it's not very strong tho :/                                     |                           |

portal_rendering.md

@@ -0,0 +1,25 @@
+# Portal Rendering
+
+{ I haven't yet gotten to implementing a portal renderer so it's possible I make a wrong claim here by mistake, but I'll try not to :) ~drummyfish }
+
+Portal rendering is a method of [3D rendering](3d_rendering.md) that treats the rendered environment as spaces (e.g. rooms) connected by portals (doors, windows, ...) which allows fast and simple determination of visibility and therefore fast and simple rendering. It was a quite popular way of 3D rendering for example in the old 1990s 3D [games](game.md) such as [Descent](descent.md) and [Duke Nukem](duke3d.md).
+
+The **basic general idea** is to represent the 3D environment as a set of "rooms" (generally any [subdivision](subdivision.md) unit of space, not just "house rooms" of course) and their connections to other rooms through portals ("holes", shared walls through which one room connects to another); then when rendering we simply draw the room the camera resides in (from the inside) and proceed to draw the rooms that are connected by portals which are now visible on the screen, treating each of those portals as a kind of new smaller screen (i.e. a [clipping](clipping.md) window). Then we go on to [recursively](recursion.md) draw portals in those rooms again etc. until some terminating condition is met (e.g. all screen pixels are covered or we have reached maximum draw depth etc.). A limitation imposed on a room is often that it has to be [convex](convex.md) so that its "from the inside" rendering is simple; non-convex spaces are then simply split into multiple convex ones -- [EZ](ez.md).
+
+Just as similar methods like [raycasting](raycasting.md) and [BSP](bsp.md) rendering, portal rendering can be used in various ways, it is not a simple [algorithm](algorithm.md) but rather a method, approach to rendering. It may also be used just as a "helper" for visibility determination in another method. Notably there is a "full 3D" (*Descent*) and "2D" (*Duke Nukem*), sector based version of portal rendering. They are all based on the same principle but may have different limitations etc.
+
+**Advantages** of portal rendering:
+
+- **It can work without [precomputation](precomputation.md)**, which is a huge plus compared e.g. to [BSP](bsp.md) rendering (though optional precomputations such as [PVS](pvs.md) can of course be always employed). This among others saves time (precomputing can take a while), program complexity and space (no need to store extra precomputed data).
+- **The environment can be [dynamic](dynamic.md)** (change on the fly, consider e.g. destructible or animated environment), thanks to not needing precomputed data. This was made advantage of in Build engine games a lot, while in Doom only wall and ceiling height could change on the run.
+- **Impossible geometry can be created** -- as we may create any arbitrary spaces that connect to each other, it is possible to for example create a house that's bigger on the inside than on the outside, or a curved tunnel that would in reality intersect itself but doesn't. We can even have **room above room in the 2D version** (though in vanilla version there can't be two VISIBLE rooms above one another).
+- **Effect such as mirrors are easy** -- a mirror may be just a portal that connects to the same room in opposite way.
+- **There is no [overdraw](overdraw.md)**, a problem that plagues many 3D renderers, so **we don't need [z-buffer](z_buffer.md)** and may probably hack the method to not even [need](dependency.md) a [frame buffer](frame_buffer.md). This is pretty awesome, may reduce memory requirements greatly and allow things such as [frameless rendering](frameless.md). However z-buffer and [double buffering](double_buffering.md) are still mostly used so as to allow additional correct rendering of overlays to the environments, e.g. "2D [sprites](billboard.md)".
+- For mentioned reasons the method is relatively simple, efficient and [software rendering](sw_rendering.md) friendly, making it a good candidate for weak computers.
+- ...
+
+TODO
+
+## 2D Portal Rendering
+
+TODO

sw_rendering.md

@@ -43,6 +43,7 @@ These are some notable software renderers:
 - **[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.
 - **[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.
 - **[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/).

usenet.md

@@ -22,3 +22,4 @@ Search for Usenet archives, I've found some sites dedicated to this, also [Inter
 
 - [BBS](bbs.md)
 - [modem world](modem_world.md)
+- [multi user dungeon](mud.md)