mirror of
https://github.com/stan220/godot-docs.git
synced 2026-09-08 20:29:03 +00:00
Fix formatting issues reported by the builder
This commit is contained in:
@@ -26,26 +26,29 @@ described here and cross-compiling the binary.
|
||||
Requirements
|
||||
------------
|
||||
|
||||
- `XCode with the iOS SDK <https://developer.apple.com/xcode/download>`__
|
||||
(a dmg image, for newer versions a **xip** file is going to be downloaded.)
|
||||
- `Clang >= 3.5 <http://clang.llvm.org>`__ for your development
|
||||
machine installed and in the ``PATH``. It has to be version >= 3.5
|
||||
to target ``arm64`` architecture.
|
||||
- `Fuse <https://github.com/libfuse/libfuse>`__ for mounting and unmounting
|
||||
the dmg image.
|
||||
- `darling-dmg <https://github.com/darlinghq/darling-dmg>`__, which
|
||||
needs to be built from source. The procedure for that is explained
|
||||
below.
|
||||
- For newer versions you should download `xar <https://mackyle.github.io/xar/>` and `pbzx <https://github.com/NiklasRosenstein/pbzx>`.
|
||||
- For building darling-dmg, you'll need the development packages of
|
||||
- `XCode with the iOS SDK <https://developer.apple.com/xcode/download>`__
|
||||
(a dmg image, for newer versions a **xip** file is going to be downloaded.)
|
||||
- `Clang >= 3.5 <http://clang.llvm.org>`__ for your development
|
||||
machine installed and in the ``PATH``. It has to be version >= 3.5
|
||||
to target ``arm64`` architecture.
|
||||
- `Fuse <https://github.com/libfuse/libfuse>`__ for mounting and unmounting
|
||||
the dmg image.
|
||||
- `darling-dmg <https://github.com/darlinghq/darling-dmg>`__, which
|
||||
needs to be built from source. The procedure for that is explained
|
||||
below.
|
||||
|
||||
- For newer versions you should download `xar <https://mackyle.github.io/xar/>`__
|
||||
and `pbzx <https://github.com/NiklasRosenstein/pbzx>`__.
|
||||
- For building darling-dmg, you'll need the development packages of
|
||||
the following libraries: fuse, icu, openssl, zlib, bzip2.
|
||||
- For building xar and pbzx you may want to follow `this guide <https://gist.github.com/phracker/1944ce190e01963c550566b749bd2b54>`
|
||||
- For building xar and pbzx you may want to follow
|
||||
`this guide <https://gist.github.com/phracker/1944ce190e01963c550566b749bd2b54>`__.
|
||||
|
||||
- `cctools-port <https://github.com/tpoechtrager/cctools-port>`__
|
||||
for the needed build tools. The procedure for building is quite
|
||||
peculiar and is described below.
|
||||
- `cctools-port <https://github.com/tpoechtrager/cctools-port>`__
|
||||
for the needed build tools. The procedure for building is quite
|
||||
peculiar and is described below.
|
||||
|
||||
- This also has some extra dependencies: automake, autogen, libtool.
|
||||
- This also has some extra dependencies: automake, autogen, libtool.
|
||||
|
||||
Configuring the environment
|
||||
---------------------------
|
||||
|
||||
@@ -52,10 +52,10 @@ Defines with replacements may also have one or more *arguments*, which can then
|
||||
be passed when referencing the define (similar to a function call).
|
||||
|
||||
If the replacement code is not defined, the identifier may only be used with
|
||||
``#ifdef` or ``#ifndef`` directives.
|
||||
``#ifdef`` or ``#ifndef`` directives.
|
||||
|
||||
Compared to constants (``const CONSTANT = value;``), ``#define``s can be used
|
||||
anywhere within the shader. ``#define``s can also be used to insert arbitrary
|
||||
Compared to constants (``const CONSTANT = value;``), ``#define`` can be used
|
||||
anywhere within the shader. ``#define`` can also be used to insert arbitrary
|
||||
shader code at any location, while constants can't do that.
|
||||
|
||||
.. code-block:: glsl
|
||||
@@ -197,14 +197,14 @@ of the ``#if`` preprocessor statement:
|
||||
#endif
|
||||
|
||||
However, the ``#if`` variant can be faster in certain scenarios. This is because
|
||||
all run-time branches in a shader are still compiled and variables within
|
||||
all run-time branches in a shader are still compiled and variables within
|
||||
those branches may still take up register space, even if they are never run in
|
||||
practice.
|
||||
|
||||
`Modern GPUs are quite effective at performing "static" branching <https://medium.com/@jasonbooth_86226/branching-on-a-gpu-18bfc83694f2>`__.
|
||||
"Static" branching refers to ``if`` statements where *all* pixels/vertices
|
||||
evaluate to the same result in a given shader invocation. However, high amounts
|
||||
of :abbr:`VGPR (Vector General-Purpose Register)`s (which can be caused by
|
||||
Modern GPUs are `quite effective <https://medium.com/@jasonbooth_86226/branching-on-a-gpu-18bfc83694f2>`__
|
||||
at performing "static" branching. "Static" branching refers to ``if`` statements where
|
||||
*all* pixels/vertices evaluate to the same result in a given shader invocation. However,
|
||||
high amounts of :abbr:`VGPRs (Vector General-Purpose Register)` (which can be caused by
|
||||
having too many branches) can still slow down shader execution significantly.
|
||||
|
||||
#elif
|
||||
|
||||
Reference in New Issue
Block a user