update readme (#982)

README.md

@@ -8,6 +8,7 @@
   <a target="_blank" rel="noopener noreferrer" href="https://github.com/water111/jak-project/workflows/Windows/badge.svg"><img src="https://github.com/water111/jak-project/workflows/Windows/badge.svg" alt="Windows" style="max-width:100%;"></a>
   <a href="https://coveralls.io/github/water111/jak-project?branch=master" rel="nofollow"><img src="https://coveralls.io/repos/github/water111/jak-project/badge.svg?branch=master" alt="Coverage Status" style="max-width:100%;"></a>
   <a href="https://www.codacy.com/gh/water111/jak-project/dashboard?utm_source=github.com&amp;utm_medium=referral&amp;utm_content=xTVaser/jak-project&amp;utm_campaign=Badge_Grade" rel="nofollow"><img src="https://app.codacy.com/project/badge/Grade/7c3cdc07523f43aca3433484ebc62ff9" alt="Codacy Badge" style="max-width:100%;"></a>
+  <a href="https://discord.gg/E7yFpd6w9G"><img src="https://img.shields.io/discord/756287461377703987" alt="Discord"></a>
 </p>
 
 ## Table of Contents
@@ -44,11 +45,14 @@ Our objectives are:
 We support both Linux and Windows on x86-64.
 
 ## Current Status
-So far, we've decompiled around 130,000 lines of GOAL code, out of an estimated 500,000 total lines and we've started work on an OpenGL renderer.  Currently, the main display process (`*dproc*`) runs and sends data to our renderer.  We can load textures, text files, and level files. Using keyboard controls, we can open the debug menu and turn on some simple debug visualizations.
+So far, we've decompiled around 341,233 lines of GOAL code, out of an estimated 500,000 total lines and we've started work on an OpenGL renderer.  Currently, the main display process (`*dproc*`) runs and sends data to our renderer.  We can load textures, text files, and level files. Using keyboard controls, we can open the debug menu and turn on some simple debug visualizations.
 
+Here are some screenshots of the renderer:
+![](./docs/img/screenshot_hut.jpg)
+![](./docs/img/screenshot_vi1.jpg)
 
-Video of debug menu and actor visibility:
-https://www.youtube.com/watch?v=0AoiYY4S7nI
+YouTube playlist:
+https://www.youtube.com/playlist?list=PLWx9T30aAT50cLnCTY1SAbt2TtWQzKfXX
 
 To help with decompiling, we've built a decompiler that can process GOAL code and unpack game assets. We manually specify function types and locations where the original code had type casts until the decompiler succeeds, then we clean up the output of the decompiled code by adding comments and adjusting formatting, then save it in `goal_src`. Our decompiler is designed specifically for processing the output of the original GOAL compiler.  As a result, when given correct casts, it often produces code that can be directly fed into a compiler and works perfectly. This is tested as part of our unit tests, and so far we have around 130,000 lines (220 files) that pass.
 
@@ -56,11 +60,12 @@ We don't save any assets from the game - you must bring your own copy of the gam
 
 ## What's Next
 
-We are focusing on three areas:
 
-- Continue decompilation of GOAL code. Recently we have started on the "gameplay" code for creatures and objects in the game world, which is going pretty fast.
-- Improve the decompiler. We are always finding new features in the GOAL language.
-- Investigate more complicated renderers. The font and debug rendering is much simpler than the highly optimized renderers used for characters and backgrounds. We are starting to look at some of these renderers in detail.
+- Continue decompilation of GOAL code. We've made huge progress recently in decompiling gameplay code. We're finishing that up and also working on the some of the rendering and collision code.  Here's our decompilation progress over the past year:
+![](./docs/img/code_progress.png)
+- Start running gameplay code! We can now spawn simple actors like particle effects and collectables.
+- Improve the decompiler. We are always finding new features and macros in the GOAL language.
+- Investigate more complicated renderers. We have an in-progress port of the "tfrag" background renderer, shown in the screenshots above.
 
 ## Getting Started - Linux (Ubuntu)
 
@@ -91,7 +96,6 @@ and run `cmake` (in a fresh build directory) with:
 ```
 cmake -DCMAKE_SHARED_LINKER_FLAGS="-fuse-ld=lld" -DCMAKE_EXE_LINKER_FLAGS="-fuse-ld=lld" -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ..
 ```
-this decreases the compile and link time from ~10 seconds to ~4 seconds.
 
 ## Getting Started - Linux (Arch)
 
@@ -227,9 +231,7 @@ The final component is the "runtime", located in `game`. This is the part of the
 
 ## Directory Layout
 
-- `.github`: GitHub actions CI setup
-- `.vs`: Visual Studio project configurations
-- `assets`: extracted assets (textures, translated game text) generated by the decompiler. Not included in the repository. To be used when building the PC port.
+- `assets`: extracted assets (textures, translated game text, audio) generated by the decompiler. Not included in the repository. This data is used when building the PC port.
 - `build`: C++ CMake build folder
 - `common`: common C++ code shared between the compiler, decompiler, and game.
   - `audio`: tools for decoding the audio files
@@ -260,7 +262,7 @@ The final component is the "runtime", located in `game`. This is the part of the
   - `overlord`: the I/O processor driver used to get data off of the DVD
   - `sce`: the Sony library implementation
   - `system`: PC-port specific OS-level stuff, like file I/O, threads, controllers, debug network connection
-- `goal_src`: The GOAL code for the game. It's mostly empty now.
+- `goal_src`: The GOAL code for the game.
   - `build`: info related to the GOAL build system.
   - `engine`: the game engine
   - `kernel`: The GOAL kernel
@@ -273,7 +275,7 @@ The final component is the "runtime", located in `game`. This is the part of the
   - `listener`: The OpenGOAL listener, which connects the compiler to a running GOAL program for the interactive REPL
   - `make`: The OpenGOAL build system, builds both code and data files
   - `regalloc`: Register allocator
-- `iso_data`: 
+- `iso_data`:
 - `out`: Outputs from the build process. Only the `iso` subfolder should contain assets used by the game.
   - `iso`: Final outputs that are used by the game.
   - `obj`: Object files generated by the compiler.