forked from openrs2/openrs2
Not really 'frequently' yet, as the project is still private, but these are questions I predict will be asked when it is made public.bzip2
parent
fffe8a2136
commit
7585d96b37
@ -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/ |
Loading…
Reference in new issue