From 3a6d6e475158c3fff8317098535ff61af4d4c20b Mon Sep 17 00:00:00 2001 From: BlockMen Date: Fri, 25 Apr 2014 19:33:31 +0200 Subject: Move the old stuff to doc --- doc/old/ancient_main_comment.txt | 345 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 345 insertions(+) create mode 100644 doc/old/ancient_main_comment.txt (limited to 'doc/old/ancient_main_comment.txt') diff --git a/doc/old/ancient_main_comment.txt b/doc/old/ancient_main_comment.txt new file mode 100644 index 000000000..d7b0e307f --- /dev/null +++ b/doc/old/ancient_main_comment.txt @@ -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: +---------------- + +====================================================================== + +*/ -- cgit v1.2.3