summaryrefslogtreecommitdiff
path: root/old/ancient_main_comment.txt
diff options
context:
space:
mode:
authorBlockMen <nmuelll@web.de>2014-04-25 19:33:31 +0200
committerBlockMen <nmuelll@web.de>2014-04-25 19:33:31 +0200
commit3a6d6e475158c3fff8317098535ff61af4d4c20b (patch)
treecf5eeb1d701a4f822b5b761b2360a1f5dd93b2ef /old/ancient_main_comment.txt
parentcd14259bd9310e45246ba3aba3730cc5ee8ee6f0 (diff)
downloadminetest-3a6d6e475158c3fff8317098535ff61af4d4c20b.tar.gz
minetest-3a6d6e475158c3fff8317098535ff61af4d4c20b.tar.bz2
minetest-3a6d6e475158c3fff8317098535ff61af4d4c20b.zip
Move the old stuff to doc
Diffstat (limited to 'old/ancient_main_comment.txt')
-rw-r--r--old/ancient_main_comment.txt345
1 files changed, 0 insertions, 345 deletions
diff --git a/old/ancient_main_comment.txt b/old/ancient_main_comment.txt
deleted file mode 100644
index d7b0e307f..000000000
--- a/old/ancient_main_comment.txt
+++ /dev/null
@@ -1,345 +0,0 @@
-------------------------------------------------------------------
-The ancient comment from the beginning of main.cpp is stored here.
-------------------------------------------------------------------
-
-/*
-=============================== NOTES ==============================
-NOTE: Things starting with TODO are sometimes only suggestions.
-
-NOTE: iostream.imbue(std::locale("C")) is very slow
-NOTE: Global locale is now set at initialization
-
-NOTE: If VBO (EHM_STATIC) is used, remember to explicitly free the
- hardware buffer (it is not freed automatically)
-
-NOTE: A random to-do list saved here as documentation:
-A list of "active blocks" in which stuff happens. (+=done)
- + Add a never-resetted game timer to the server
- + Add a timestamp value to blocks
- + The simple rule: All blocks near some player are "active"
- - Do stuff in real time in active blocks
- + Handle objects
- - Grow grass, delete leaves without a tree
- - Spawn some mobs based on some rules
- - Transform cobble to mossy cobble near water
- - Run a custom script
- - ...And all kinds of other dynamic stuff
- + Keep track of when a block becomes active and becomes inactive
- + When a block goes inactive:
- + Store objects statically to block
- + Store timer value as the timestamp
- + When a block goes active:
- + Create active objects out of static objects
- - Simulate the results of what would have happened if it would have
- been active for all the time
- - Grow a lot of grass and so on
- + Initially it is fine to send information about every active object
- to every player. Eventually it should be modified to only send info
- about the nearest ones.
- + This was left to be done by the old system and it sends only the
- nearest ones.
-
-NOTE: Seeds in 1260:6c77e7dbfd29:
-5721858502589302589:
- Spawns you on a small sand island with a surface dungeon
-2983455799928051958:
- Enormous jungle + a surface dungeon at ~(250,0,0)
-
-Old, wild and random suggestions that probably won't be done:
--------------------------------------------------------------
-
-SUGG: If player is on ground, mainly fetch ground-level blocks
-
-SUGG: Expose Connection's seqnums and ACKs to server and client.
- - This enables saving many packets and making a faster connection
- - This also enables server to check if client has received the
- most recent block sent, for example.
-SUGG: Add a sane bandwidth throttling system to Connection
-
-SUGG: More fine-grained control of client's dumping of blocks from
- memory
- - ...What does this mean in the first place?
-
-SUGG: A map editing mode (similar to dedicated server mode)
-
-SUGG: Transfer more blocks in a single packet
-SUGG: A blockdata combiner class, to which blocks are added and at
- destruction it sends all the stuff in as few packets as possible.
-SUGG: Make a PACKET_COMBINED which contains many subpackets. Utilize
- it by sending more stuff in a single packet.
- - Add a packet queue to RemoteClient, from which packets will be
- combined with object data packets
- - This is not exactly trivial: the object data packets are
- sometimes very big by themselves
- - This might not give much network performance gain though.
-
-SUGG: Precalculate lighting translation table at runtime (at startup)
- - This is not doable because it is currently hand-made and not
- based on some mathematical function.
- - Note: This has been changing lately
-
-SUGG: A version number to blocks, which increments when the block is
- modified (node add/remove, water update, lighting update)
- - This can then be used to make sure the most recent version of
- a block has been sent to client, for example
-
-SUGG: Make the amount of blocks sending to client and the total
- amount of blocks dynamically limited. Transferring blocks is the
- main network eater of this system, so it is the one that has
- to be throttled so that RTTs stay low.
-
-SUGG: Meshes of blocks could be split into 6 meshes facing into
- different directions and then only those drawn that need to be
-
-SUGG: Background music based on cellular automata?
- http://www.earslap.com/projectslab/otomata
-
-SUGG: Simple light color information to air
-
-SUGG: Server-side objects could be moved based on nodes to enable very
- lightweight operation and simple AI
- - Not practical; client would still need to show smooth movement.
-
-SUGG: Make a system for pregenerating quick information for mapblocks, so
- that the client can show them as cubes before they are actually sent
- or even generated.
-
-SUGG: Erosion simulation at map generation time
- - This might be plausible if larger areas of map were pregenerated
- without lighting (which is slow)
- - Simulate water flows, which would carve out dirt fast and
- then turn stone into gravel and sand and relocate it.
- - How about relocating minerals, too? Coal and gold in
- downstream sand and gravel would be kind of cool
- - This would need a better way of handling minerals, mainly
- to have mineral content as a separate field. the first
- parameter field is free for this.
- - Simulate rock falling from cliffs when water has removed
- enough solid rock from the bottom
-
-SUGG: For non-mapgen FarMesh: Add a per-sector database to store surface
- stuff as simple flags/values
- - Light?
- - A building?
- And at some point make the server send this data to the client too,
- instead of referring to the noise functions
- - Ground height
- - Surface ground type
- - Trees?
-
-Gaming ideas:
--------------
-
-- Aim for something like controlling a single dwarf in Dwarf Fortress
-- The player could go faster by a crafting a boat, or riding an animal
-- Random NPC traders. what else?
-
-Game content:
--------------
-
-- When furnace is destroyed, move items to player's inventory
-- Add lots of stuff
-- Glass blocks
-- Growing grass, decaying leaves
- - This can be done in the active blocks I guess.
- - Lots of stuff can be done in the active blocks.
- - Uh, is there an active block list somewhere? I think not. Add it.
-- Breaking weak structures
- - This can probably be accomplished in the same way as grass
-- Player health points
- - When player dies, throw items on map (needs better item-on-map
- implementation)
-- Cobble to get mossy if near water
-- More slots in furnace source list, so that multiple ingredients
- are possible.
-- Keys to chests?
-
-- The Treasure Guard; a big monster with a hammer
- - The hammer does great damage, shakes the ground and removes a block
- - You can drop on top of it, and have some time to attack there
- before he shakes you off
-
-- Maybe the difficulty could come from monsters getting tougher in
- far-away places, and the player starting to need something from
- there when time goes by.
- - The player would have some of that stuff at the beginning, and
- would need new supplies of it when it runs out
-
-- A bomb
-- A spread-items-on-map routine for the bomb, and for dying players
-
-- Fighting:
- - Proper sword swing simulation
- - Player should get damage from colliding to a wall at high speed
-
-Documentation:
---------------
-
-Build system / running:
------------------------
-
-Networking and serialization:
------------------------------
-
-SUGG: Fix address to be ipv6 compatible
-
-User Interface:
----------------
-
-Graphics:
----------
-
-SUGG: Combine MapBlock's face caches to so big pieces that VBO
- can be used
- - That is >500 vertices
- - This is not easy; all the MapBlocks close to the player would
- still need to be drawn separately and combining the blocks
- would have to happen in a background thread
-
-SUGG: Make fetching sector's blocks more efficient when rendering
- sectors that have very large amounts of blocks (on client)
- - Is this necessary at all?
-
-SUGG: Draw cubes in inventory directly with 3D drawing commands, so that
- animating them is easier.
-
-SUGG: Option for enabling proper alpha channel for textures
-
-TODO: Flowing water animation
-
-TODO: A setting for enabling bilinear filtering for textures
-
-TODO: Better control of draw_control.wanted_max_blocks
-
-TODO: Further investigate the use of GPU lighting in addition to the
- current one
-
-TODO: Artificial (night) light could be more yellow colored than sunlight.
- - This is technically doable.
- - Also the actual colors of the textures could be made less colorful
- in the dark but it's a bit more difficult.
-
-SUGG: Somehow make the night less colorful
-
-TODO: Occlusion culling
- - At the same time, move some of the renderMap() block choosing code
- to the same place as where the new culling happens.
- - Shoot some rays per frame and when ready, make a new list of
- blocks for usage of renderMap and give it a new pointer to it.
-
-Configuration:
---------------
-
-Client:
--------
-
-TODO: Untie client network operations from framerate
- - Needs some input queues or something
- - This won't give much performance boost because calculating block
- meshes takes so long
-
-SUGG: Make morning and evening transition more smooth and maybe shorter
-
-TODO: Don't update all meshes always on single node changes, but
- check which ones should be updated
- - implement Map::updateNodeMeshes() and the usage of it
- - It will give almost always a 4x boost in mesh update performance.
-
-- A weapon engine
-
-- Tool/weapon visualization
-
-FIXME: When disconnected to the menu, memory is not freed properly
-
-TODO: Investigate how much the mesh generator thread gets used when
- transferring map data
-
-Server:
--------
-
-SUGG: Make an option to the server to disable building and digging near
- the starting position
-
-FIXME: Server sometimes goes into some infinite PeerNotFoundException loop
-
-* Fix the problem with the server constantly saving one or a few
- blocks? List the first saved block, maybe it explains.
- - It is probably caused by oscillating water
- - TODO: Investigate if this still happens (this is a very old one)
-* Make a small history check to transformLiquids to detect and log
- continuous oscillations, in such detail that they can be fixed.
-
-FIXME: The new optimized map sending doesn't sometimes send enough blocks
- from big caves and such
-FIXME: Block send distance configuration does not take effect for some reason
-
-Environment:
-------------
-
-TODO: Add proper hooks to when adding and removing active blocks
-
-TODO: Finish the ActiveBlockModifier stuff and use it for something
-
-Objects:
---------
-
-TODO: Get rid of MapBlockObjects and use only ActiveObjects
- - Skipping the MapBlockObject data is nasty - there is no "total
- length" stored; have to make a SkipMBOs function which contains
- enough of the current code to skip them properly.
-
-SUGG: MovingObject::move and Player::move are basically the same.
- combine them.
- - NOTE: This is a bit tricky because player has the sneaking ability
- - NOTE: Player::move is more up-to-date.
- - NOTE: There is a simple move implementation now in collision.{h,cpp}
- - NOTE: MovingObject will be deleted (MapBlockObject)
-
-TODO: Add a long step function to objects that is called with the time
- difference when block activates
-
-Map:
-----
-
-TODO: Flowing water to actually contain flow direction information
- - There is a space for this - it just has to be implemented.
-
-TODO: Consider smoothening cave floors after generating them
-
-TODO: Fix make_tree, make_* to use seed-position-consistent pseudorandom
- - delta also
-
-Misc. stuff:
-------------
-TODO: Make sure server handles removing grass when a block is placed (etc)
- - The client should not do it by itself
- - NOTE: I think nobody does it currently...
-TODO: Block cube placement around player's head
-TODO: Protocol version field
-TODO: Think about using same bits for material for fences and doors, for
- example
-
-SUGG: Restart irrlicht completely when coming back to main menu from game.
- - This gets rid of everything that is stored in irrlicht's caches.
- - This might be needed for texture pack selection in menu
-
-TODO: Merge bahamada's audio stuff (clean patch available)
-
-Making it more portable:
-------------------------
-
-Stuff to do before release:
----------------------------
-
-Fixes to the current release:
------------------------------
-
-Stuff to do after release:
----------------------------
-
-Doing currently:
-----------------
-
-======================================================================
-
-*/