assets/developer-notes/stephanie-gawroriski/2016/10/09.mkd

   1 # 2016/10/09
   2
   3 ## 11:58
   4
   5 So entity positions are 32-bit. 32 / 3 is 10 and 64 / 3 is 21. Since the chunk
   6 index takes 10 bits, its shift is 11. This leaves 8 bits for sub positions.
   7 This allows entity positions to be serialized as a long.
   8
   9 ## 13:46
  10
  11 I am thinking of making the surface world a bit larger and making the world
  12 not as tall.
  13
  14 ## 13:53
  15
  16 So I can make it 1024x1024x1024, 2048x2048x256, 4096x4096x64. Since my chunk
  17 size is 8, this effectively means that the world is more wide than it is
  18 tall. However, I believe going for 4096 wide and long would be the best
  19 choice.
  20
  21 ## 14:02
  22
  23 The surface would generally a bit more interesting, although underground
  24 could also be interesting too.
  25
  26 ## 14:10
  27
  28 So for this I need a functional class that just handles positions.
  29
  30 ## 14:17
  31
  32 Actually, I can use all of the 32-bit integer and treat it as unsigned. This
  33 would give me 13x13x6 bits, 8192x8192x64 chunks, 65536x65536x512 blocks.
  34
  35 ## 14:20
  36
  37 But do I need to worry about coordinates for things being packed into a single
  38 long? Not really. The only thing is that with a maximal block size of 13, this
  39 means the sub-block divisions is lower. If I want to keep all values signed
  40 this leaves me with 31 bits. Remove 13 and I have 18 for the block and sub.
  41 Since 3 are used for the block, that leaves 15 for the sub.
  42
  43 ## 14:40
  44
  45 If I got rid of mining blocks, I would only have to store items for the most
  46 part in save data for each chunk. This would be less intensive and would
  47 essentially allow me to target low memory systems which might not even have
  48 a disk. However, it would have to be interesting enough to not bore players.
  49
  50 ## 14:44
  51
  52 Could be an interesting. Basically, you can create a character/avatar and
  53 instead of being stuck to a single world you can spawn in a different one.
  54
  55 ## 14:47
  56
  57 However, that might be a bit tough. I suppose unless requested you can
  58 stay in the same world and stuff lying around would be saved for the most
  59 part. Since you would not be able to mine and say build bridges, that would
  60 instead be replaced by items that spawn bridges, and others that create
  61 ladders.
  62
  63 ## 14:51
  64
  65 Since some resources could still be utilized, say leaves from trees, I can
  66 store a simple value that just defines a set of resources available in a
  67 chunk. So basically you would have a scavage function when you point to a
  68 block that has a resource. So rockey dirt for example would have rock
  69 resources. If you scavage rocks too much then that is remembered. So
  70 essentially even though you cannot mine or remove trees for example, you
  71 can still drain the resources that are available. Then this will mean much
  72 more limited systems will still get the same set of features for the most
  73 part. Since storing all those chunks would be quite expensive.
  74
  75 ## 15:47
  76
  77 So the chunks will contain just the level data.
  78
  79 ## 15:50
  80
  81 This also means that `ChunkManager` does not need a `ReferenceQueue` for
  82 chunks, it just needs `Chunk`. Then that `Chunk` really just needs all the
  83 data associated with it. Since I no longer have to store those to the disk.
  84 So this simplifies the chunk code. The one class where I need refences and
  85 data splitting would be resources that exist within chunks. Since resources
  86 only use a limited range of values, I can group them into large cubes. So
  87 the world chunk size is divided by some value to get the resource data size.
  88 Storing all of the values would not be costly at all. There would be
  89 initialized and uninitialized values. However, values for all chunks would
  90 essentially become initialized when the chunk exists.
  91
  92 ## 15:52
  93
  94 So effectively, I would have to rethink how chunks are stored since I do
  95 want them to be allowed to be cleared from memory when not used. So
  96 essentially that means `Map<Integer, Reference<Chunk>>` where chunk is
  97 reference queued. If the queue detects that a chunk was collected it will
  98 be cleared from the index. So essentially I have the same as before,
  99 except that `ChunkData` is removed for the most part.
 100
 101 ## 16:42
 102
 103 I do wonder what would be the best way to have a cache of chunks. I can use
 104 `WeakHashMap`, however that has keys. I would want there to really just be
 105 a set for the most part.
 106
 107 ## 16:45
 108
 109 Well really, I just need a chunk specifier so I have
 110 `Map<ChunkIndex, Reference<Chunk>>`.
 111
 112 ## 18:51
 113
 114 J2ME has two graphics libraries. One is called M3G and the other is your
 115 standard Open GL ES. I will have to take a peek at M3G. I would suppose for
 116 simplicity that M3G will be implemented on top of OpenGL ES. This way, only
 117 OpenGL ES rasterizers only need to be created.