In this section you can check out what I'm currently working in, practically in real time.
If some of this seems cryptic it's because the logs seen here come directly from my personal productivity tool prio, and are really just "notes to self".
Nevertheless, if you are interested in what I'm currently working on, this space will certainly be updated FAR more often than the news section.
18:27:01 sandblox TASK: orientations persistence / format change
18:26:53 sandblox CLOCK: 00:13 hours
17:56:26 sandblox CLOCK: 00:25 hours
17:01:31 sandblox CLOCK: 00:13 hours
03:38:28 sandblox LOG
Ok here's a fun bit of development:
I have been bothered by the fact that adding any additional per-instance data (talking about entries in the Grid) will bloat the data size, as the single byte present is used for material index. Of course, doubling the size doesn't really matter much as it would only take 8 MB at the current world size, but it does feel inherently wasteful since only certain instances will be using the data at all.
I just now implemented support for a diagonal mesh type, intended for ramps and similar level decorations (like inset lights), and got to thinking about the principle of explicitly storing only what you actually need, as opposed to implicitly storing everything.
In this case adding additional storage to the Grid to handle the cases where certain mesh types need more data (like orientation) would be implicit, sort of like a union being the size of the largest permutation.
What I did instead was use a key-tree to store orientation data (calculated from the vector of the placement of the block) only when the mesh type of the material in question is the diagonal type, and clearing any residual data when it is not this mesh type.
This means that there is additional data stored only for the actual indices that use diagonal mesh materials; a quick test in a small area I'd created yielded something in the order of 25 diagonal mesh instances.
I think that this is a very interesting concept that can be expanded for all kinds of things; for example the recent thoughts on implicit & infinite worlds with things that you can remove / destroy. In these cases you can remove something from the implicit representation by storing data when the thing is removed / destroyed (position key or equivalent), which will result in the object not being re-spawned when a given world chunk is generated.
Ideally some kind of balanced structure should be used, like an AVL-tree, but I suppose that a Jet that is regenerated for each change to the structure would be even better, so that chunk building and intersection access is as fast as possible at run time.
What else does this concept expand to?
01:46:01 sandblox CLOCK: 0.1 days (03:03 hours)
22:57:00 sandblox TASK: remove legacy material load support
22:02:54 sandblox CLOCK: 00:27 hours
21:35:28 sandblox TASK: generalize multimaterials
20:21:52 sandblox CLOCK: 0.1 days (02:07 hours)
18:11:54 sandblox CLOCK: 0.1 days (01:36 hours)
17:18:40 sandblox TASK: creeps seek player eye
15:39:05 codebase TASK: fix ray vs cylinder
15:38:55 codebase TASK: factor out constant editor
14:57:51 codebase CLOCK: 00:21 hours
13:42:48 sandblox LOG
Implemented willGenMesh(), a brute check to see if a chunk will actually output a mesh as a result of a build operation. This is much faster for checking solid / empty chunks.
There may be issues with edge cases.
11:30:07 codebase TASK: move ACE/ Sandblox extended edit methods to dxut::EditGui
20:13:15 codebase CLOCK: 0.1 days (03:21 hours)
19:31:45 codebase TASK: factor out common TypeVisitor
16:46:31 codebase TASK: refactor noise functions
16:07:04 codebase LOG
Shifting as many constant::XXX instances to const as possible, as they are usually edited via a dedicated editor which undermines this constness (via core::Traversable).
16:23:19 sandblox CLOCK: 00:45 hours
15:59:00 sandblox TASK: zombie
21:20:30 sandblox LOG
Playing around with the classic exploding barrel concept...
16:08:38 sandblox CLOCK: 0.1 days (01:15 hours)
16:08:16 sandblox TASK: creeps seek player
15:50:08 sandblox LOG
All builders now use vertex optimization.
13:52:09 sandblox LOG
Yesterday saw the addition of "multi-materials", that a given side of a block can use more than a single tile / block. The current test is for material 99 only.
Everything is tesselated the same (for lighting reasons), but the actual block index used varies in space. This material test is 4x4 blocks in x and z, and 2x2 blocks in y (this is arbitrary).
I suppose it would be simple enough to generalize this by adding more block mesh types, i.e. block1x1, block2x2, block3x3, block 4x4. However I anticipate cases where you would want 1x4, 2x4 etc as well, so we probably need a configurable 2d integer vector, ranging from 1 to the number of blocks in each axis on the tilepage.
For simplicity I guess it will be ok to require that the blocks used are sequentially placed on the tilepage; this removes the need for further mapping as well as keeps the texture page actually looking like the image you are shooting for.
An alternative would be to simply have each block index map to a unique texture. This is more in the vein of Quake / Doom and would probably be simpler for the artist, but would require more draw calls (one per block index /material / texture). It sort of all depends on the type of game you are going for, the size of the world, average draw calls, etc.
Need to look into optimizing the number of vertices added (in the multimaterial and / or multi texture cases), since tiling materials will have the same uvs and in some cases matching lighting.
22:40:40 sandblox TASK: creep collision
22:10:39 sandblox TASK: multi materials
19:00:24 sandblox TASK: shoot creeps
23:24:08 sandblox TASK: creep with simple ai
23:24:06 sandblox TASK: creep spawner entity
23:24:05 sandblox TASK: entity tool
23:24:01 sandblox CLOCK: 0.1 days (02:06 hours)
20:15:55 sandblox TASK: prebaked ao and sky shadows
20:01:52 sandblox LOG
doom3 enemy / gameplay analysis (as pertaining to making a shooter using sandblox)
-player has various projectile weapons with tradeoffs like
-rate of fire
-damage per projectile
-close vs long range effectiveness
-slow vs hitscan projectiles
-zombies, slow, walk up and slap you
-soldiers, star in cover and shoot at you
-heads, fly at you and head butt you
-imps, throw slow fireballs, also melee, also jump at you
-pinky, melee butts you
-teleporting knife arms, melee but also jump around using tele
-cacodemons, fly, but shoot slow projectiles
-barrels, static but dangerous if hit with weapons fire, can be used offensively
-map features pertaining to enemies
-enemies that are spawned on level start but are passive until they have los to player
-triggers that spawn active enemies in predefined locations
-triggers that open closets with active enemies in them
-triggers that drop the floor out from you, optionally spawning enemies / opening closets or simply giving enemies los to you
-general map features
-find the key, open door (i.e. security clearance)
-press the button, open door
-lighting conditions (dark)
01:56:12 codebase CLOCK: 0.1 days (02:36 hours)
20:58:17 codebase CLOCK: 0.2 days (04:54 hours)
15:40:52 codebase CLOCK: 0.1 days (03:12 hours)
10:41:38 codebase TASK: test inf
13:49:04 sabk CLOCK: 0.1 days (02:26 hours)
13:09:55 sbtf CLOCK: 00:35 hours
12:34:33 sbtf TASK: rooms
16:04:09 sabk CLOCK: 01:09 hours
16:02:27 sabk TASK: sounds for various causes of death
14:59:19 sabk TASK: bug: biswitch doesn't work when passage set
19:19:00 sbtf TASK: tris to quads
15:04:57 music TASK: make a tree
07:42:38 sbtf CLOCK: 0.1 days (01:34 hours)
07:08:50 sbtf TASK: blood on walls
05:21:24 sbtf TASK: random ambience
05:21:20 sbtf TASK: stinger
16:10:49 sbtf CLOCK: 0.1 days (01:42 hours)
14:26:33 sbtf TASK: fov scare
14:26:32 sbtf TASK: random textures
14:25:59 sbtf TASK: fix rendering
14:25:57 sbtf TASK: fix motion detection
18:09:44 sabk TASK: Spiked, Drowned, Burninated, Astrocreeped, Creatured, Electrocuted
13:57:12 sabk CLOCK: 01:04 hours
16:36:21 sabk TASK: duplicates of walker, swimmer, jumper
16:12:04 sabk LOG
Tilepage switching (Y and U) was missing from GfxTool, fixed that.
16:11:47 sabk TASK: tilepage switch in all relevant tools
16:04:01 sabk TASK: binary switch toggles 2 tile types, analogous to trinary switch toggling 3...
16:27:29 sabk CLOCK: 00:31 hours
16:27:22 sabk TASK: binary switch / tile
16:27:15 sabk TASK: rename switch to triswitch
14:41:04 sabk CLOCK: 00:33 hours
14:07:42 sabk TASK: world tool music swap
14:07:41 sabk TASK: world tool background swap
13:12:52 sabk CLOCK: 01:04 hours
20:33:15 sabk CLOCK: 0.1 days (01:24 hours)
20:32:24 sabk TASK: world tool tile swap (per screen)
11:48:59 prionews LOG
Updated the How to use PRIO section to reflect the gui changes in version 2.0.