Made the front page less confusing to readers

README.md

@@ -13,9 +13,11 @@ Real-time dynamic light with depth-based casted shadows and normal mapping at 29
 * **Determinism down to machine precision** means that if it worked on one computer, it will probably work the same on another computer.
 * **Often faster than the monitor's refresh rate** for isometric graphics with dynamic light. Try the Sandbox SDK example compiled in release mode on Ubuntu or Manjaro to check if it's smooth on your CPU. Quad-core Intel Core I5 should be fast enough in resonable resolutions, hexa-core I5 will have plenty of performance and octa-core I7 is butter smooth even in high resolutions.
 * **Low latency for retro 2D graphics** using the CPU's higher frequency for low resolutions. There are no hardware limits other than CPU cycles and memory. Render to textures, apply deferred light filters or write your modified rendering pipeline for custom geometry formats.
-* **Easy to use GUI system.** Create a window, load the interface from a file and connect a lambda function to a button's click action using only a few lines of procedural code.
 * **Create your legacy.** Make software that future generations might be able to port, compile and run natively without the need for emulators.
 
+## More than a graphics API, less than a graphics engine
+It is a rendering API, image processing framework and graphical user interface system in a static C++14 library meant to minimize the use of dynamic dependencies in long-term projects while still offering the power to make your own abstractions on top of low-level rendering operations. The core library itself is mostly pure math and can be compiled on most systems using GNU's C++14, but the window backends that takes user input and displays the final image buffer are implemented outside of the library for each platform. This places most platform dependent code into a single module that can be ported relatively easy if you have worked with the system's native API before. A window backend for X11 is currently supporting Linux, which is recommended for trying the SDK and learning. On embedded systems, you can output images as ascii art via SSH to debug robotic vision.
+
 ## Still a public beta
 Don't use it for safety-critical projects unless you verify correctness yourself and take all responsibility. Either way, it's probably a lot safer than using OpenGL, OpenCL or Direct3D simply by being a single implementation where bugs will be mostly the same on each platform. Stack memory for VLA may vary. Test everything with billions of cases.
 
@@ -27,26 +29,11 @@ Don't use it for safety-critical projects unless you verify correctness yourself
 * Linux Mint need the compiler and X11 headers, so run "sudo apt install g++" and "sudo apt install libx11-dev" before compiling.
 * There's a half finished Win32 port that's not published because it wasn't fast enough when emulated on 64-bit Windows. Might have to write for 64-bit only on Windows to prevent poor performance.
 
-## Remaining work
-* Optimization of 3D rendering is still quite primitive. There's no quad-tree algorithm for quickly skipping large chunks of unseen pixels. There's no depth sorting nor early removal of triangles yet.
-* The 3D camera system doesn't have a fixed API yet. The ability to not have a far-clip-plane made it complicated to express using a standard view space, so clip planes are stored separatelly while rendering. There might be a better solution.
-
-## How you can help
-* Report bugs that you find. (Visual C++ is not supported because it doesn't have C++14 nor C11 extensions)
-* Port the Window wrapper to more platforms with instructions for compiling and linking.
-* Create your own GUI components that can be pasted into a project and registered to the class factory. The most used may be taken into the core.
-* Develop minimal-dependency open-source games as a complement to the SDK.
-* Create 3D model import/export functions for standard formats.
-* Create 3D model editor with custom format for generating pre-rendered extremely detailed isometric sprites with diffuse, normal and height images, compatible with the Sandbox example.
-
 ## Supported CPU hardware
 * Intel/AMD using SSE2 intrinsics.
 * ARM using NEON intrinsics.
 * Unknown Little-Endian systems. (without SIMD vectorization)
 
-## Might support if it comes back:
-* Big endian. Currently mostly used in routers, which aren't nearly powerful enough.
-
-## Will never support: (Don't worry power-users, this is a nerdy library meant for Linux geeks, retro gamers and scientists.)
-* Mobile phones. You can't take a phone application and just release it for a desktop system, because this is why Windows 8 failed. Use the right tool for each task and consider the differences in usability contexts.
-* Web frontends. The whole point of using this software renderer is the ability to write your own image filters using portable SIMD vectors in C++. A web script that can run native C++ applications is a web script that I would never allow into my browser due to the total lack of security. At least let me scan for viruses and choose whether to trust the source first.
+## Will not target:
+* Mobile phones. Because the constant changes breaking backwards compatibility on mobile platforms would defeat the purpose of using a long-lifetime framework, you will be on your own if you try to use the library for such use cases. You cannot just take something from a desktop and run it on a phone, because mobile platforms require custom C++ compilers, screen rotation, battery saving, knowing when to display the virtual keyboard, security permissions, forced full-screen... Trying to do both at the same time would end up with design compromises in both ends like Microsoft Windows 8 or Ubuntu's Unity lock screen.
+* Web frontends. Such a wrapper over this library would not be able to get the power of SIMD intrinsics for defining your own image filters, so you would be better off targeting a GPU shading language from the browser which is more suited for dynamic scripting.