diff --git a/tutorials/3d/procedural_geometry/arraymesh.rst b/tutorials/3d/procedural_geometry/arraymesh.rst index 27138dfd7..708bf062d 100644 --- a/tutorials/3d/procedural_geometry/arraymesh.rst +++ b/tutorials/3d/procedural_geometry/arraymesh.rst @@ -40,7 +40,7 @@ The third parameter is an array of blendshapes for the Mesh to use. While this t using blendshapes, it is possible to specify them when creating a surface from arrays. The last parameter is the compress flags which specifies which arrays to store with half as many bits. The -values can be found in the classref for :ref:`VisualServer ` under :ref:`ArrayFormat `. +values can be found in the classref for :ref:`RenderingServer ` under :ref:`ArrayFormat `. For normal usage you will find it is best to leave the last two parameters empty. diff --git a/tutorials/3d/procedural_geometry/index.rst b/tutorials/3d/procedural_geometry/index.rst index f8c65671d..221453aff 100644 --- a/tutorials/3d/procedural_geometry/index.rst +++ b/tutorials/3d/procedural_geometry/index.rst @@ -52,7 +52,7 @@ What a Mesh is A Mesh is composed of one or more surfaces. A surface is an array composed of multiple sub-arrays containing vertices, normals, UVs, etc. Normally the process of constructing surfaces and meshes is -hidden from the user in the :ref:`VisualServer `, but with ArrayMeshes, the user can construct a Mesh +hidden from the user in the :ref:`RenderingServer `, but with ArrayMeshes, the user can construct a Mesh manually by passing in an array containing the surface information. Surfaces diff --git a/tutorials/best_practices/data_preferences.rst b/tutorials/best_practices/data_preferences.rst index 8a725d941..e824d6788 100644 --- a/tutorials/best_practices/data_preferences.rst +++ b/tutorials/best_practices/data_preferences.rst @@ -317,7 +317,7 @@ Users can manipulate... 2. the number of regions contained within the texture (frames). -Godot's :ref:`VisualServer ` then draws +Godot's :ref:`RenderingServer ` then draws the regions in sequence at the prescribed rate. The good news is that this involves no extra logic on the part of the engine. The bad news is that users have very little control. diff --git a/tutorials/io/background_loading.rst b/tutorials/io/background_loading.rst index bd2cc772e..1aa9a8e19 100644 --- a/tutorials/io/background_loading.rst +++ b/tutorials/io/background_loading.rst @@ -213,7 +213,7 @@ Not blocking main thread during the polling If you have a mutex to allow calls from the main thread to your loader class, don't lock the main thread while you call ``poll`` on your loader class. When a resource is done loading, it might require some resources from the -low-level APIs (VisualServer, etc), which might need to lock the main +low-level APIs (RenderingServer, etc), which might need to lock the main thread to acquire them. This might cause a deadlock if the main thread is waiting for your mutex while your thread is waiting to load a resource. diff --git a/tutorials/io/files/resource_queue.gd b/tutorials/io/files/resource_queue.gd index 896de4fb6..414929b77 100644 --- a/tutorials/io/files/resource_queue.gd +++ b/tutorials/io/files/resource_queue.gd @@ -81,7 +81,7 @@ func is_ready(path): func _wait_for_resource(res, path): _unlock("wait_for_resource") while true: - VisualServer.sync() + RenderingServer.force_sync() OS.delay_usec(16000) # Wait approximately 1 frame. _lock("wait_for_resource") if queue.size() == 0 || queue[0] != res: diff --git a/tutorials/performance/thread_safe_apis.rst b/tutorials/performance/thread_safe_apis.rst index ecec63498..85e5964ab 100644 --- a/tutorials/performance/thread_safe_apis.rst +++ b/tutorials/performance/thread_safe_apis.rst @@ -14,7 +14,7 @@ Below is a list of ways multithreading can be used in different areas of Godot. Global scope ------------ -:ref:`Global Scope` singletons are all thread-safe. Accessing servers from threads is supported (for VisualServer and Physics servers, ensure threaded or thread-safe operation is enabled in the project settings!). +:ref:`Global Scope` singletons are all thread-safe. Accessing servers from threads is supported (for RenderingServer and Physics servers, ensure threaded or thread-safe operation is enabled in the project settings!). This makes them ideal for code that creates dozens of thousands of instances in servers and controls them from threads. Of course, it requires a bit more code, as this is used directly and not within the scene tree. diff --git a/tutorials/performance/using_multimesh.rst b/tutorials/performance/using_multimesh.rst index acf8c9401..2acf529bb 100644 --- a/tutorials/performance/using_multimesh.rst +++ b/tutorials/performance/using_multimesh.rst @@ -35,7 +35,7 @@ which are ideal for this). Another alternative is to use GDNative and C++, which should be extremely efficient (it's possible to set the entire state for all objects using linear memory via the -:ref:`VisualServer.multimesh_set_buffer() ` +:ref:`RenderingServer.multimesh_set_buffer() ` function). This way, the array can be created with multiple threads, then set in one call, providing high cache efficiency. diff --git a/tutorials/performance/using_servers.rst b/tutorials/performance/using_servers.rst index 4872bddce..08fc86014 100644 --- a/tutorials/performance/using_servers.rst +++ b/tutorials/performance/using_servers.rst @@ -33,7 +33,7 @@ At the core, Godot uses the concept of Servers. They are very low-level APIs to rendering, physics, sound, etc. The scene system is built on top of them and uses them directly. The most common servers are: -* :ref:`VisualServer `: handles everything related to graphics. +* :ref:`RenderingServer `: handles everything related to graphics. * :ref:`PhysicsServer `: handles everything related to 3D physics. * :ref:`Physics2DServer `: handles everything related to 2D physics. * :ref:`AudioServer `: handles everything related to audio. @@ -67,11 +67,11 @@ For nodes, there are many functions available: method will return the viewport RID in the server. * For 3D, the :ref:`World ` resource (obtainable in the :ref:`Viewport ` and :ref:`Spatial ` nodes) - contains functions to get the *VisualServer Scenario*, and the *PhysicsServer Space*. This + contains functions to get the *RenderingServer Scenario*, and the *PhysicsServer Space*. This allows creating 3D objects directly with the server API and using them. * For 2D, the :ref:`World2D ` resource (obtainable in the :ref:`Viewport ` and :ref:`CanvasItem ` nodes) - contains functions to get the *VisualServer Canvas*, and the *Physics2DServer Space*. This + contains functions to get the *RenderingServer Canvas*, and the *Physics2DServer Space*. This allows creating 2D objects directly with the server API and using them. * The :ref:`VisualInstance` class, allows getting the scenario *instance* and *instance base* via the :ref:`VisualInstance.get_instance() ` @@ -94,23 +94,23 @@ This is an example of how to create a sprite from code and move it using the low extends Node2D - # VisualServer expects references to be kept around. + # RenderingServer expects references to be kept around. var texture func _ready(): # Create a canvas item, child of this node. - var ci_rid = VisualServer.canvas_item_create() + var ci_rid = RenderingServer.canvas_item_create() # Make this node the parent. - VisualServer.canvas_item_set_parent(ci_rid, get_canvas_item()) + RenderingServer.canvas_item_set_parent(ci_rid, get_canvas_item()) # Draw a texture on it. # Remember, keep this reference. texture = load("res://my_texture.png") # Add it, centered. - VisualServer.canvas_item_add_texture_rect(ci_rid, Rect2(texture.get_size() / 2, texture.get_size()), texture) + RenderingServer.canvas_item_add_texture_rect(ci_rid, Rect2(texture.get_size() / 2, texture.get_size()), texture) # Add the item, rotated 45 degrees and translated. var xform = Transform2D().rotated(deg2rad(45)).translated(Vector2(20, 30)) - VisualServer.canvas_item_set_transform(ci_rid, xform) + RenderingServer.canvas_item_set_transform(ci_rid, xform) The Canvas Item API in the server allows you to add draw primitives to it. Once added, they can't be modified. The Item needs to be cleared and the primitives re-added (this is not the case for setting the transform, @@ -121,7 +121,7 @@ Primitives are cleared this way: .. tabs:: .. code-tab:: gdscript GDScript - VisualServer.canvas_item_clear(ci_rid) + RenderingServer.canvas_item_clear(ci_rid) Instantiating a Mesh into 3D space @@ -135,24 +135,24 @@ The 3D APIs are different from the 2D ones, so the instantiation API must be use extends Spatial - # VisualServer expects references to be kept around. + # RenderingServer expects references to be kept around. var mesh func _ready(): # Create a visual instance (for 3D). - var instance = VisualServer.instance_create() + var instance = RenderingServer.instance_create() # Set the scenario from the world, this ensures it # appears with the same objects as the scene. var scenario = get_world().scenario - VisualServer.instance_set_scenario(instance, scenario) + RenderingServer.instance_set_scenario(instance, scenario) # Add a mesh to it. # Remember, keep the reference. mesh = load("res://mymesh.obj") - VisualServer.instance_set_base(instance, mesh) + RenderingServer.instance_set_base(instance, mesh) # Move the mesh around. var xform = Transform(Basis(), Vector3(20, 100, 0)) - VisualServer.instance_set_transform(instance, xform) + RenderingServer.instance_set_transform(instance, xform) Creating a 2D RigidBody and moving a sprite with it --------------------------------------------------- @@ -170,7 +170,7 @@ and moves a :ref:`CanvasItem ` when the body moves. func _body_moved(state, index): # Created your own canvas item, use it here. - VisualServer.canvas_item_set_transform(canvas_item, state.transform) + RenderingServer.canvas_item_set_transform(canvas_item, state.transform) func _ready(): @@ -198,7 +198,7 @@ The 3D version should be very similar, as 2D and 3D physics servers are identica Getting data from the servers ----------------------------- -Try to **never** request any information from ``VisualServer``, ``PhysicsServer`` or ``Physics2DServer`` +Try to **never** request any information from ``RenderingServer``, ``PhysicsServer`` or ``Physics2DServer`` by calling functions unless you know what you are doing. These servers will often run asynchronously for performance and calling any function that returns a value will stall them and force them to process anything pending until the function is actually called. This will severely decrease performance if you diff --git a/tutorials/rendering/multiple_resolutions.rst b/tutorials/rendering/multiple_resolutions.rst index 14e416b5d..4427eaaf5 100644 --- a/tutorials/rendering/multiple_resolutions.rst +++ b/tutorials/rendering/multiple_resolutions.rst @@ -403,15 +403,9 @@ Reducing aliasing on downsampling If the game has a very high base resolution (e.g. 3840×2160), aliasing might appear when downsampling to something considerably lower like 1280×720. -Aliasing can be made less visible by shrinking all images by a factor of 2 -upon loading. This can be done by calling the method below before -the game data is loaded:: - VisualServer.texture_set_shrink_all_x2_on_set_data(true) - -Alternatively, you can also enable mipmaps on all your 2D textures. However, -enabling mipmaps will increase memory usage which may be problematic on low-end -mobile devices. +To resolve this, you can enable mipmaps on all your 2D textures. However, enabling mipmaps +will increase memory usage which may be problematic on low-end mobile devices. Handling aspect ratios ---------------------- diff --git a/tutorials/rendering/viewports.rst b/tutorials/rendering/viewports.rst index 0a5cf541b..f9e49e397 100644 --- a/tutorials/rendering/viewports.rst +++ b/tutorials/rendering/viewports.rst @@ -156,7 +156,7 @@ it using (for example): :: # Wait until the frame has finished before getting the texture. - yield(VisualServer, "frame_post_draw") + await RenderingServer.frame_post_draw # You can get the image after this. Viewport Container