Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - d3x0r

Pages: [1] 2
General Discussion / School Mode
« on: November 01, 2019, 04:11:02 am »
Hello!  Great to see updates from y'all.

School shouldn't be tedious.... Right now, to get to be able to make your first tool... you have to dig, and I'm gussing it's 1.5 seconds(? 2?) per dig block?

( 64 * 3 = 192 ) * 1.5 = 382 seconds... 6 and a half minutes. (9 almost 10 minutes?)

And then I can find greenstone, and be able to return with it to the surface where my machine.

The document says.
'Where can you find it ?
You can find this voxel in the ground into the central blue flat zone.'  And the picture shows it on top of black rock blue... I know it's just showing the same block on the same oroginal blank stage, but... it does sort of imply that it can be over blackrrock blue - and it never is.

So ... I think " it's just another random block like copper, okay I'll keep digging sideways... surely they wouldn't force me to climb up and down all the time... " and dig t alot sideways, so now 30 minutes later and still no greenrock ...

Most voxelish digging games put rock only a little ways below dirt.... 4-8 voxels... because there's an infinite supply of dirt (blackrock blue).

So, optimally that's 6 minutes after the first 5-8 playing with the RTFM and external help; and having the cursor trapped to the game, so I can't click back on the browser... (tough, I know, to own the cursor, but give it up when you don't have it. )  There are lose focus events that you can revert the cursor capture... )

And if I was really new, I'd be sidetracked by copper and iron and other things, and it would really take me a long time to get to green rock; (I mentioned that earlier, it's realistically at LEAST 7 minutes, to make your first tool).

I wanted to learn to program, not spend my time in a clicker.

let me just reiterate, as i was closing this window... I missed the (X) a little...

1) when the game is not in focus, do not setmousepotiion on mouse event.  (background window of the browser, I miss the scroll bar a bit, and my mouse snaps to the other thing, but I was JUST typing in the browser... and then I have to get back to the scrollbar, but if there isn't actually another window over where the mosue moves, it's stuck, until you hit I to get to invenotry (free mouse) or something

2) alt-F4 doesn't work.

3) window isn't resizable by clicking on the frame (if you could somehow get the mouse off the game-focus :) )

So when drilling, if I click and drill, there's a kinda buzzing/grinding sound for the drill.  If I continue to hold the button, that sound stops for the second block.  if I release and click again it re-starts.  (almost shouldn't stop really?)

when holding shift (to run?) the footstep sound stops; and move speed doesn't seem different (if there's supposed to be one)

(Windows 7)

General Discussion / Evolutionary voxel robots?
« on: October 28, 2016, 04:37:27 am »

I ran across this the other day; and you don't have an off topic, and really hope you don't find this too random :)

General Discussion / Voxelarium.js
« on: May 24, 2016, 05:09:12 am »
I got tired of the C# port already :)  (never did finish actually implementing the game portion of it... just water)

Started a new javascript/three.js version...

click and drag; 's' enables moving scaling, it's not very good... faster than scroll wheel though

it's actually broken into separate files on the source side; fed through 'browserify' to make it simple to load on the web page.... but you can save the page and have all the sources; soon to make a github branch for it

(the mode buttons don't do anything any more; I also did a test ... )

(although it's more inspired by, and plajurizing a couple algorithms like sectorSphere :)

General Discussion / Dynamic fonts
« on: November 19, 2015, 06:37:54 am »
I've been tinkering with making a C# port, and was looking for a way to render fonts dynamically instead of having a fixed bitmap font of limited characters.   I stumbled on a C header-only font rendering library which is part of

so I have this class

which uses the c# port of that library and renders characters dynamically into a texture.  (as each character is needed, if it doesn't exist on the bitmap already, render it, copy it to the bitmap, mark the bitmap dirty, then when drawing, if dirty, re-download the image to OpenGL.  Works pretty good...  the GetCharacter routine would have to be changed to support utf-8 decoding instead of utf-16; GetCharacter takes a string and an index and returns  a 32 bit 'rune' named after the character type in Go.

Instead of porting squirrel and the assembly language I was planning on using C# scripts.  I have basic functionality to load .cs files, compile them and use them.  I don't have the reactor done.  so for now it's just a static rendering.  I made a GLSL shader that generates output that look like the general texture with lines on edges... can even control the thickness of the lines dynamically and face/edge color.

Implemented a texture atlas for everything else; but had to scale the images down and extract single faces to fit in an atlas correctly; but was planning on using the texture more as a decal image and the face-edge shader as the background.  So then moved the face/edge colors into the description file.

But; I'm working on interfacing with a physics engine... I was going to use Bullet, even spent some time to make a new C# port of that since the other is obsolete by 3-4 years.... but in the process ended up stumbling on BEPUPhysics which is already C# and has 4-5x the speed of bullet and already supports multi-threaded dispatch of work.   

I also played with the game 'fortresscraft' which is also voxel based and has conveyors/smelters/etc.  Their version makes ore types un-minable by the player, and you attach a drill to a block and get unlimited ore generated from the drill on the ore; kind of unrealistic... but then you can spend time on the automation instead of strip-mining the world...

For now I do very little checking of the C# scripts; but will eventually limit their functionality to just classes the game engine provides and not all of C# library; would be bad to get a script that reads your file system, opens a network connection and dumps all your stuff :)  Or worse... I do limit them now from using 'System.IO' but will eventually need more checks.  Will be nice once MS has compiler-as-a-service support released; can already do it in Mono.

Troubleshooting & Bug Reports / Code Bugs
« on: October 23, 2015, 12:03:33 pm »
void ZVoxelWorld::SectorUpdateFaceCulling(Long x, Long y, Long z, bool Isolated)

  UByte * BlocMatrix[3];

This is only a byte, but it's using Sector::Data which is UShort now.

This is OK because there's only 238 types right now.... but will be a problem with voxel type 256 ... or type&0xFF == 0

General Discussion / Similar game?
« on: October 08, 2015, 12:56:43 pm »
don't mean to promote it; maybe it will be some inspiration?

Stumbled on this other game...
short, quick start... guess this game is pretty deep....
there's lots of other in-play videos

Kinda reminds me of what blackvoxel is kinda attempting to be with automation; different but similar?

General Discussion / General Voxel Performance... no; no it's not
« on: October 07, 2015, 10:28:11 am »
Was going to mention this....
(references )

Basically I was playing with unity, and found there's a free voxel engine plugin.  Developed by the same people that did Polyvox.  And saw that article, and after reading the articles thought 'wow maybe that would be nice'

My first test case it turned out the the max distance from (-1,-1,-1) to (1,1,1) was 53.  (even smaller than the 256 that is the distance from (0,-1,0) to (0,0,0) in black voxel)  Which would mean that it would be even better for locality of voxels in cache.

However; that was just 1 case, and the real worst case is a distance of 3080(!). 
7,7,7 center
min 504   00000000000000000000000111111000
max 3584 00000000000000000000111000000000

The worse case gets worse and worse.... iterating over 0-100,0-100,0-100 the average max distance is 41296(!)

Each point at 7, 15, 31, 63, is increasingly large offset...

So ya; ignore this.

this is more of a what-not-to-do.... it looks clever to start... but having reasonably sized sectors is more advantageous... and does nothing but complicate the offsets to wrap between sectors.

General Discussion / OpenGL Performance
« on: October 02, 2015, 09:03:57 am »
OpenGL performance improvements... requires a pretty advanced OpenGL Level?  But some of it is interesting in pointing out that there might be more.

Did notice a few articles that OpenGL is faster tha D3D ...

General Discussion / Contrib & Assembler & legacy projects
« on: January 08, 2015, 07:55:40 pm »
it's a 0 not a O ... :)  0:)  :O


Looking forward to assembly...

Omega - (dos box)

c-robots (programming guide)

basically a C syntax... with a limited internal library of 'clib' functions... like
turn(), scan(), ...

My automaton game (bugbrain)  (in zip is 16 bit installer, won't work in 64bit systems)
would add input nodes that are graphic images (chips... actually a chip would be a modular thing, with multiple pinouts on it... an input/output node is more like a pin on a chip/module.... )
Needs a way to register inputs and outputs...
(repackaged as a single zip)

 crobots, omega etc, do active scan... so you have to have a run-loop

bugbrain would be more like a event input... which is more suitable for a ladder-logic sort of language... or PAL language ..

or... FPGA programming (Field-programmable_gate_array) ... but I forget the syntax... and cannot find a good example... It's more like parallel state machines... so a machine has a state, and in a state, when it receives inputs it can generate output and/or change states...

inputs are generally logic signals (read/write BUS line for instance) ... but could be multiple in parallel so (this set of pins is 8 bits) is a address... that can be used to reference lookup tables for outputs...

Programming with Blackvoxel / Custom VoxelTypes
« on: November 09, 2014, 01:26:37 am »
I have a block called 'fertile ground' that in a second or 2 from creation grows 'low foliage' aka food.
food will eventually age and become medium and tall; which will be unusable by the first animals... a block called rabbit and a block called fox....
I implemented a type called ZVoxelRef
Code: [Select]

#include "ZVoxelSector.h"
#include "../ZVoxelExtension.h"
class ZVoxelWorld;
class ZVoxelRef
ZVoxelSector * Sector;
int Offset;
int x, y, z;
UShort VoxelType;
ZVoxelWorld *World;
ZVoxelTypeManager *VoxelTypeManager;
ZVoxelExtension *VoxelExtension;
ZVoxelRef( ZVoxelWorld *world, ZVoxelTypeManager *vtm, long x = 0, long y = 0, long z = 0, ZVoxelSector *Sector=NULL, UShort VoxelType = 0, int offset = 0 )
this->x = x;
this->y = y;
this->z = z;
this->Sector = Sector;
this->Offset = offset;
this->World = world;
this->VoxelType = VoxelType;
VoxelTypeManager = vtm;
static int ForEachVoxel( ZVoxelWorld * World, ZVoxelRef *v1, ZVoxelRef *v2, int (*f)(ZVoxelRef *v) );



that I for implemented for the result of raycast at maxiter... before I changed method to render selection cube in space in front of player...

// modified GetVoxel which just returned the UShort from a world coordinate
//  to return the World, Sector, relative x,y,z within the sector, and the UShort type
// the sector has it's x,y,z scaled world coordinate... so the absolute coord is knowable from the reference.
... reviewing this a little... the ref could be used for all the temp variables themselves... this actually returns a copy of the world coordinate, React uses it as x,y,z within the sector...
Code: [Select]
inline ZVoxelRef *ZVoxelWorld::GetVoxelRef(Long x, Long y, Long z)
  ZVoxelSector * Sector;
  Long Offset;


  if (!Sector) return NULL;

  Offset =  (y & ZVOXELBLOCMASK_Y)

  return new ZVoxelRef( this, VoxelTypeManager, x, y, z, Sector, Sector->Data[Offset], Offset );

inline UShort ZVoxelWorld::GetVoxel(Long x, Long y, Long z)
  ZVoxelSector * Sector;
  Long Offset;


  if (!Sector) return(-1);

  Offset =  (y & ZVOXELBLOCMASK_Y)


Used this in VoxelReactor to call React virtual method in voxel table...
Code: [Select]
      Long RSx = Sector->Pos_x << ZVOXELBLOCSHIFT_X;
      Long RSy = Sector->Pos_y << ZVOXELBLOCSHIFT_Y;
      Long RSz = Sector->Pos_z << ZVOXELBLOCSHIFT_Z;
  ZVoxelRef ref(World,VoxelTypeManager, 0,0,0,Sector );
    // z, x, y should just be ref.x, ref.y, ref.z, ... redundant copy
      for (z = 0; z < ZVOXELBLOCSIZE_Z; z++)
        for (x = 0; x < ZVOXELBLOCSIZE_X; x++)
          for (y = 0; y < ZVOXELBLOCSIZE_Y; y++)
VoxelType = *(VoxelP);
            if (ActiveTable->Get(VoxelType))
              if (!Sector->ModifTracker.Get( MainOffset ) ) // If voxel is already processed, don't process it once more in the same cycle.
  ref.x = x; ref.y = y; ref.z = z;
  ref.Offset = VoxelP - DisplayData;
  ref.VoxelType = VoxelType;

IsActiveVoxels = true;
ref.VoxelExtension = (ZVoxelExtension*)Sector->OtherInfos[MainOffset];
// not sure what St is ...
VoxelTypeManager->VoxelTable[VoxelType]->React( ref, LastLoopTime);

Programming with Blackvoxel / MSVC or non-GCC Porting
« on: November 08, 2014, 06:15:32 am »
Specific to using MSVC instead of GCC to build (or OpenWatcom; although doesn't solve OpenWatcom on Linux)

Code: [Select]
#ifndef __GCC__
#    ifdef __64__
#          define __sync_bool_compare_and_swap(a,b,c) InterlockedCompareExchange64((__int64*)a,(__int64)b,(__int64)c)
#    else
#          define __sync_bool_compare_and_swap(a,b,c) InterlockedCompareExchange(a,b,c)
#   endif

although as a quick and dirty hack the following code works
Code: [Select]
// in src\z\ZMemPool_Optimized.cpp
#ifdef __GCC__
      if (__sync_bool_compare_and_swap(&MemTable[BitPosition],NewBlock,NewBlock->Next))
if( (MemTable[BitPosition] == NewBlock) ? (MemTable[BitPosition]=NewBlock->Next),1:0)

which does the same job, but without lock.....

Programming with Blackvoxel / How hard could smoothing be?
« on: October 25, 2014, 02:20:50 pm »
Well... it was a lot harder than I thought...

work in progress; maybe

inner corners are unsmoothed... just smooths the outer edges.

Have many corner cases that have multiple solution paths... light right now single blocks and single rows of blocks don't smooth either....

and I have a broken corner that could be better; not to mention all the directions that are yet missing.

was going to map textures on diagonals such that if it's a top & left visible, to show the top and left side of the texture, so the diagonals would get an extra line; right now all left & anything is left and any right & anthing is right and any forward & any is forward and same for back; sorta, top&((right/left)&(back/front)) is top....

Programming with Blackvoxel / Thoughts on large body collisions?
« on: October 22, 2014, 11:18:13 am »
I ended up breaking collisions by shrinking the world voxel size and keeping the same player size.   I see that you built several planes to represent the character at various levels and an axis through the center.

but with small blocks, 3 or 4 blocks can fit in the spaces... so as long as the voxels that aren't in those planes aren't there, you can pass through it...

So I was considering taking the points of the forward and back planes and iterating through the voxels between them... any thoughts?
Was just now considering instead iterating the central axis and normals along the line.... so the character now is slightly larger than 1 block (6 bits; 64 pixels) so most of the collision stuff works... if I dig a 3 wide 1 deep trench in the ground, it works to keep the feet within it... but if I built bars across the path, can go through a lot. 
Also some single blocks on just the ground I can go through... maybe I end up going around it...

trying to make an argument for only needing to check +/-1 x and +/-1 z from the center axis... character is say 8 blocks high now... would be 40 voxels to check for collision... but only 2 lookups the rest can be iterated through.

Programming with Blackvoxel / Voxel pixel selector box, render offset
« on: October 21, 2014, 05:29:08 am »
There's a constant '256' and '128' in the code, that in most cases is the size of a pixel.
I was making a static const global struct to contain values like this...
but somehow this isn't the value that's used in all places.

Edit: Nevermind I don't have questions... my issue was 256/128 is also used in player dimensions so I ended up shrinking the player... and everything from a mouse's perspective looked the same.... so have to do some more combing; the player doesn't collide right for isntance.

the voxel selection box renders in the new size... but is offset from the floor by 256(ish) so I was wondering what it's called? where it's drawn?

and the cubes are still spaced out by 256... what 'creates' the world?  I would think that saves would be in voxel indexes... so if I change 256 to (GlobalSettings.VoxelBlockSize=64) and 128 to (GlobalSettings.VoxelBlockSize/2)

I implementd a ZMatrix class which is basically ZTransformParams and ZPolar3d rolled into 1... so only the initial setting the yaw/pitch/roll updates that matrix, instead of later computing TransformParams possibly more than one time...
I lost the actual yaw/pitch/roll values, but have functions that can get the relative yaw/pitch/roll of the matrix, which ends up always between -180 and 180 instead of 0-360, and I'm not sure which direction 0 yaw 0 pitch 0 roll is.... THe RTFM block reads normal, but appears behind me... my 'forward' ends up being a 'backward'... Oh also keeping it as a matrix I can just return the address of the row for each axis, which is the normal right, normal up, and normal forward vectors already computed (part of transform params kinda) .
I got the plane mostly working... managed to take off and land and yaw/pitch/roll mostly works... there are some iteritive effects that aren't quite right....
The matrix rotate is always relative to the current rotation.... it's for tracking 6DOF in space really where yaw/pitch/roll is always relative to your current yaw/pitch/roll.  I also have rotate matrix around an arbitrary axis... so I can pass the Y axis and an angle for flat-yaw rotation that the plane does as it is rolled...
The ground mode also has an auto correction to the roll, so every iteration just applied -roll to current roll to make the character stand up... ended up making the look up and down kinda auto rotate you if you pass the top... kinda like watching something go over head, when looking up, you'd keep looking up until you rotate your body and start looking (pitch) down to continue...

The other place I noticed polar vectors used is in the tree generators; so I ended up not replacing that usage.

Oh - so the other thing is I think that the 'view cone' isn't aligned forward anymore... was wondering what builds the forward culling... because it mostly works, but at times I'm getting strange short draws of sectors...(?)

Oh, and modified the save file... added blkplr3 that just stores location (zmatrix.origin) and viewdirection (zmatrix.quaternion) (this is a Vec4 that represents the current 3x3 rotation matrix) ; and not the camera location and direction, since this is always relatively updated by calling Actor->SetPosition()... so onload just set location viewdiection and call setposition.

I reread some of the things on your board, and I realize you're not looking for code input you're looking for funding input... so I'm gonna stuff a copy in my own repository so I can at least track all these changes...

Pages: [1] 2