From 7585d96b376160f304fb45ff91d91f85c0b36c08 Mon Sep 17 00:00:00 2001 From: Graham Date: Tue, 10 Sep 2019 21:42:41 +0100 Subject: [PATCH] Add initial FAQ Not really 'frequently' yet, as the project is still private, but these are questions I predict will be asked when it is made public. --- docs/faq.md | 76 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 76 insertions(+) create mode 100644 docs/faq.md diff --git a/docs/faq.md b/docs/faq.md new file mode 100644 index 0000000000..8fb8342cfa --- /dev/null +++ b/docs/faq.md @@ -0,0 +1,76 @@ +# Frequently Asked Questions + +## How was build 550 chosen? + +A mixture of reasons: + +* The early HD era is my favourite. In particular, I like the 'clean'-looking + tabs in the user interface, and 550 was the last build with those. I also + considered 530, but 550 has a better built-in world map viewer (it supports + dungeons in addition to the main surface). +* Availability of the original loader, client, game unpacker and jaggl jars. +* Availability of the complete set of original client data files. +* Availability of a large proportion of the location file encryption keys. + +## Why does OpenRS2 use Maven instead of Gradle? + +Gradle's task-based model is significantly better than Maven's fixed lifecycle +model. + +However, Gradle's flexibility and rate of development has come at a cost of +worse IDE integration, to the point at which recent versions of IntelliJ IDEA +now delegate build actions to Gradle by default rather than attempting to +understand the project structure. This tends to be slower and consume more +memory than IDEA's built-in build system. While this setting can be changed, I +think it is a sign of the future of Gradle's IDE integration. + +Furthermore, [nar-maven-plugin][nar-maven-plugin] is, at the time of writing, +significantly better than Gradle's support for building native code. Gradle's +new C++ plugin simply doesn't provide enough features. + +This might be a decision we revisit in the future. + +## Why is OpenRS2 licensed under the GNU GPL? + +As significant amount of work went into the development of OpenRS2. My aim is +to encourage community contributions rather than effort being duplicated across +multiple independent closed-source forks, making a copyleft license desirable. + +I also wanted to frustrate commercial use, given OpenRS2 is itself developed +entirely non-commercially. While the GPL does this to an extent, the AGPL would +have been more appropriate. However, it would be far more difficult to enforce +the AGPL than the GPL, disadvantaging honest users who would have otherwise +obeyed the license. + +A small number of modules (`deob-annotations` and the native library +replacements) are instead licensed under the LGPL, as it needs to be possible +to legally link these modules with the proprietary client code. + +## Why rewrite the client's native libraries? + +Again, there are a mixture of reasons: + +* Availability of the original native libraries. I struggled to find the + original native libraries for 550, except for 32-bit Windows. While Linux and + macOS natives are available for nearby revisions, they are not compatible + with the 550 client. +* The original native libraries were not built for 64-bit Linux and macOS. + While this was probably not a major problem in 2009, 64-bit architectures are + now the norm. +* Non-x86 architectures like ARM and RISC-V are becoming more popular. If we + start seeing a shift away from x86 on desktop machines, the native libraries + will need to be built for those architectures. +* The original macOS jaggl native library is backed by an NSView, which was + deprecated in Java 6 and removed in Java 7. Java 7 requires surfaces to be + backed by a CALayer instead. +* I anticipate that at some point in the future the Linux AWT implementation + will be ported from X11 to Wayland, which will require porting the jaggl + native library from GLX to EGL. +* The switch away from OpenGL to newer graphics APIs like Metal and Vulkan + might eventually necessitate the inclusion of OpenGL to Metal/Vulkan + translation layers. +* I'm concerned about backwards compatibility and bit rot. The original native + libraries were compiled 10 years ago, and at some point one of their + dependencies might drop backwards binary compatibility. + +[nar-maven-plugin]: https://maven-nar.github.io/