doc update
authorPerttu Ahola <celeron55@gmail.com>
Mon, 29 Nov 2010 21:07:03 +0000 (23:07 +0200)
committerPerttu Ahola <celeron55@gmail.com>
Mon, 29 Nov 2010 21:07:03 +0000 (23:07 +0200)
doc/README.txt
src/main.cpp

index 340d8f5f381582b26261ba19150020f9280d1d3d..ea84a6bec8a76e8c7a61ac007ff266b217d20ac3 100644 (file)
@@ -56,6 +56,10 @@ Compiling on GNU/Linux:
 - Neither of which can probably be found from your distro's repository.
 - Compiling each of them should be fairly unproblematic, though.
 
+Compiling on Windows:
+- Be sure to
+  #define JMUTEX_CRITICALSECTION
+  in jmutex.h before compiling it. Otherwise mutexes will be very slow.
 
 License of Minetest-c55
 -----------------------
index f4a52c40a6b08205e78bdbe21361cd763114acbd..a2185450f0922a1b548359f11b8c7848050ec12c 100644 (file)
@@ -19,6 +19,7 @@ with this program; if not, write to the Free Software Foundation, Inc.,
 \r
 /*\r
 =============================== NOTES ==============================\r
+NOTE: Things starting with TODO are sometimes only suggestions.\r
 \r
 NOTE: VBO cannot be turned on for fast-changing stuff because there\r
       is an apparanet memory leak in irrlicht when using it (not sure)\r
@@ -64,14 +65,13 @@ TODO: - Scripting
 \r
 SUGGESTION: Modify client to calculate single changes asynchronously\r
 \r
-TODO: Moving players more smoothly. Calculate moving animation from\r
-      data sent by server.\r
+TODO: Moving players more smoothly. Calculate moving animation\r
+      in a way that doesn't make the player jump to the right place\r
+         immediately when the server sends a new position\r
 \r
 TODO: There are some lighting-related todos and fixmes in\r
       ServerMap::emergeBlock\r
 \r
-TODO: Make a dirt node and use it under water\r
-\r
 FIXME: When a new sector is generated, it may change the ground level\r
        of it's and it's neighbors border that two blocks that are\r
           above and below each other and that are generated before and\r
@@ -81,55 +81,32 @@ SUGGESTION: Use same technique for sector heightmaps as what we're
             using for UnlimitedHeightmap? (getting all neighbors\r
                        when generating)\r
 \r
-TODO: Set server to automatically find a good spawning place in some\r
+SUGG: Set server to automatically find a good spawning place in some\r
       place where there is water and land.\r
          - Map to have a getWalkableNear(p)\r
+         - Is this a good idea? It's part of the game to find a good place.\r
 \r
 TODO: Transfer more blocks in a single packet\r
 SUGG: A blockdata combiner class, to which blocks are added and at\r
       destruction it sends all the stuff in as few packets as possible.\r
 \r
-TODO: If player is on ground, mainly fetch ground-level blocks\r
-TODO: Fetch stuff mainly from the viewing direction\r
+SUGG: If player is on ground, mainly fetch ground-level blocks\r
+SUGG: Fetch stuff mainly from the viewing direction\r
 \r
-TODO: Expose Connection's seqnums and ACKs to server and client.\r
+SUGG: Expose Connection's seqnums and ACKs to server and client.\r
       - This enables saving many packets and making a faster connection\r
          - This also enables server to check if client has received the\r
            most recent block sent, for example.\r
-\r
 TODO: Add a sane bandwidth throttling system to Connection\r
 \r
-FIXME: There still are *some* tiny glitches in lighting as seen from\r
-       the client side. The server calculates them right but sometimes\r
-          they don't get transferred properly.\r
-          - Server probably checks that a block is not sent, then continues\r
-          to sending it, then the emerge thread marks it as unsent and then\r
-          the sender sends the block as it was before emerging?\r
-TODO: How about adding a "revision" field to MapBlocks?\r
-\r
 SUGG: More fine-grained control of client's dumping of blocks from\r
       memory\r
          - ...What does this mean in the first place?\r
 \r
-TODO: Somehow prioritize the sending of blocks and combine the block\r
-      send queue lengths\r
-         - Take two blocks to be sent next from each client and assign\r
-           a priority value to them\r
-         - Priority is the same as distance from player\r
-         - Take the highest priority ones and send them. Send as many as\r
-           fits in the global send queue maximum length (sum of lengths\r
-               of client queues)\r
 TODO: Make the amount of blocks sending to client and the total\r
          amount of blocks dynamically limited. Transferring blocks is the\r
          main network eater of this system, so it is the one that has\r
          to be throttled so that RTTs stay low.\r
-FIXME: There is a bug that sometimes the EmergeThread bumps to\r
-       the client's emerge counter being already 0, and also the\r
-          sending queue size of the client can float to 1 or 2, which\r
-          stops the map from loading at all.\r
-          - A quick hack could be applied to ignore the error of\r
-            being at 0 and timing out old entries\r
-SUGG: Make client send GOTBLOCKS before updating meshes\r
 \r
 TODO: Server to load starting inventory from disk\r
 \r
@@ -137,17 +114,7 @@ TODO: PLayers to only be hidden when the client quits.
 TODO: - Players to be saved on disk, with inventory\r
 TODO: Players to be saved as text in map/players/<name>\r
 \r
-SUGGESTION: A map editing mode (similar to dedicated server mode)\r
-\r
-TODO: Maybe: Create a face calculation queue on the client that is\r
-      processed in a separate thread\r
-TODO: Make client's mesh updates to happen in a thread similar to\r
-      server's EmergeThread.\r
-         - This is not really needed, mesh update is really fast\r
-         - Instead, the lighting update can be slow\r
-         - So, this todo is not really a todo. It is a not-todo.\r
-SUGG: Make server to send all modified blocks after a node change\r
-      after all the stuff including lighting have been updated\r
+SUGG: A map editing mode (similar to dedicated server mode)\r
 \r
 TODO: Make fetching sector's blocks more efficient when rendering\r
       sectors that have very large amounts of blocks (on client)\r
@@ -169,16 +136,16 @@ SUGG: Add a time value to the param of footstepped grass and check it
       against a global timer when a block is accessed, to make old\r
          steps fade away.\r
 \r
-\r
 TODO: Add config parameters for server's sending and generating distance\r
 \r
 TODO: Copy the text of the last picked sign to inventory in creative\r
       mode\r
 \r
 TODO: Untie client network operations from framerate\r
+      - Needs some input queues or something\r
 \r
 SUGG: Make a copy of close-range environment on client for showing\r
-      on screen, with minimal mutexes to slow the main loop down\r
+      on screen, with minimal mutexes to slow down the main loop\r
 \r
 SUGG: Make a PACKET_COMBINED which contains many subpackets. Utilize\r
       it by sending more stuff in a single packet.\r
@@ -193,8 +160,8 @@ SUGG: Split MapBlockObject serialization to to-client and to-disk
 \r
 TODO: Get rid of GotSplitPacketException\r
 \r
-Before release:\r
-======================================================================\r
+SUGG: Implement lighting using VoxelManipulator\r
+      - Would it be significantly faster?\r
 \r
 TODO: Check what goes wrong with caching map to disk (Kray)\r
 \r
@@ -203,7 +170,6 @@ TODO: Remove LazyMeshUpdater. It is not used as supposed.
 Doing now:\r
 ======================================================================\r
 \r
-TODO: Implement lighting using VoxelManipulator\r
 \r
 ======================================================================\r
 \r