mirror of
https://github.com/minetest/minetest.git
synced 2024-11-27 10:03:45 +01:00
Move huge comment from the beginning of main.cpp to doc/ancient_main_comment.txt
This commit is contained in:
Perttu Ahola
parent
f49914dd17
commit
37b2bc3c0c
345
doc/ancient_main_comment.txt
Normal file
345
doc/ancient_main_comment.txt
Normal file
@ -0,0 +1,345 @@
|
|||||||
|
------------------------------------------------------------------
|
||||||
|
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:
|
||||||
|
----------------
|
||||||
|
|
||||||
|
======================================================================
|
||||||
|
|
||||||
|
*/
|
||||||
342
src/main.cpp
342
src/main.cpp
@ -17,348 +17,6 @@ with this program; if not, write to the Free Software Foundation, Inc.,
|
|||||||
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
|
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
|
||||||
*/
|
*/
|
||||||
|
|
||||||
/*
|
|
||||||
=============================== 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:
|
|
||||||
----------------
|
|
||||||
|
|
||||||
======================================================================
|
|
||||||
|
|
||||||
*/
|
|
||||||
|
|
||||||
#ifdef NDEBUG
|
#ifdef NDEBUG
|
||||||
/*#ifdef _WIN32
|
/*#ifdef _WIN32
|
||||||
#pragma message ("Disabling unit tests")
|
#pragma message ("Disabling unit tests")
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user