Hi d3x0r,

If you changed code for conversion, there is a little trap in the player to voxel coordinate conversion. If you replace shift by division it won't work because result is different on some values. Try with negative value -64.0, division(/256.0) and shift(>> won't give the same results. That could be enough to mess a lot of things.
The shift conversion was used to avoid having two "0" voxels ( 64.0 and -64.0 position would have given the same result : 0).

Another problem if you replaced the "256" constant in code is that this number is also the number of voxels in a zone. The zone is the unit for the generator to choose the kind of landscape that will be generated. That's used in some code in the generator ("ZWorldGenesis.h" and .cpp).

The Blackvoxel Team

Right; I actually ended up replacing '256.0' so it missed all the integer versions... there are a few other places that 256 is used...

I ended up making a separate global varible "VoxelSizeInBits" which then expands and creates the actual voxel size... then I had the number to fixup the shifts too.

'12' and '16' are also rarely used numbers, these were shifts from world space to sector (world_bits + ZVOXELBLOCSHIFT_[x/y/z]) and a few places where it was just '8' from world space to voxel coordinate.

most compiles generate shifts if the constant is a power of 2 in a multiply or divide when generating optimizations; at least MSVC and GCC do.

-64 = 0x(ffffff)C0
dividing or shifting a signed variable results in the same value
if the value was an unsigned integer the shift would give the wrong result because it would not be sign extended, and would be 0 filled at the top instead...

-----
Made a fork on github...
I would try to make a pull request to sync some of the stuff; (cmakelists for instance) but I mangled(touched/modified) a lot of sources in the update to use SDL2.
I don't know if you get to see forks on github
My original changes were from the source download, which was behind the sources on github... hmm maybe I can fix that... otherwise I think I end up losing some changes...

Well at least there isn't a lot in code conflicts... (fixed reversions)

if normal selection fails, I was using the same raycaster and shortening the max iterations; then realized I just had to scale forward by world voxel size * (6), get the voxel that point is in and draw voxel selector in air... and set that it collided so click can set the block... want to add like shift-scrollwheel to change the distance of that block... but still need to fix scrollwheel events in SDL2 port.

Fixed that; I ended up missing searching headers for '256' and '128' (and shifts....) but most important there was a translation of player position to player sector position that was not updating correctly... so every sector block was outside of distance and qualified for ejection.

much more stable now... (well as stable as before I started mangling it with a global setting for block size)
really want to make it more like an object setting ala Space Engineers

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...

Do you have something like 'the voxel in-line with the screen pos at a certain distance' sort of thing?  I found the add a block on right click, and extended it to do something silly like make a cluster of blocks in a relative direction... So it's pretty easy to set voxels in the world.

Is there something about the order to set voxels in so transparent textures work better?  When I used fiber optic, repeated, complex stepping had transparency issues, that the textures further back were rendered over the visible fronts...

Something like in space engineers, when you create a new ship, your first focus is at a fixed distance from you along the mouse ray.
-----
THe other feature I was thinking I'd like would be, the block next to an existing type of block that the mouse ray is passing through... I realize that if you were looking down a wall that many voxels in line would be valid... so again maybe at a distance from the cursor... use like ctrl or alt-scroll wheel to set the distance?  Maybe I don't want that... maybe I can just click on a point to begin pathing.... well see still need to know which side near that block the mouseray is going through...

Like if I start with a center block in space (give the player a zero-g jetpack something) was going to use a center block with 6 blocks around it also filled in as a base shape for a neuron, and use the 6 voxels around it as connecting points... then still in that place, to extend a line outwards from there; in space engineers creative you cyou can hold ctrl and when building it selects a line of blocks... it's only a valid line when the mouse ray passes through a block on that line... so in theory there's 6 lines that extend out from this central shape, that I want to extend out away from myself, so i can't see the face to add the block to...

Break out SaveWorld from End_PhysicsEngine()....

void ZGame::SaveWorld(  )
{
  ZStream_SpecialRamStream Stream;
  ZStream_File FileStream;
  ZString FileName;
  if (COMPILEOPTION_USEHOMEDIRSTORAGE)
  {
    FileName = ZStream_File::Get_Directory_UserData();
    FileName.AddToPath(COMPILEOPTION_SAVEFOLDERNAME);
  }
  FileName.AddToPath("Universes").AddToPath((ZString)UniverseNum).AddToPath("PlayerInfo.dat");
  FileStream.SetFileName(FileName.String);
  if (FileStream.OpenWrite())
  {
    Stream.SetStream(&FileStream);

    PhysicEngine->GetSelectedActor()->Save(&Stream);
    Stream.FlushBuffer();
    Stream.Close();
    FileStream.Close();
  }
/*
  // Inventory Saving
  char Buffer[1024];
  sprintf(Buffer, "%s/%ld/PlayerInfo.dat", UniverseNum);
  PhysicEngine->GetSelectedActor()->Inventory->Save(Buffer);
*/

}

bool ZGame::End_PhysicEngine()
{

  // Save Physic engine actors

#if COMPILEOPTION_ALLOWSAVEPLAYERSTATE == 1
  SaveWorld( );
#endif


  if (PhysicEngine) delete PhysicEngine;
  PhysicEngine = 0;
  Initialized_PhysicEngine = false;
  return(true);
}

add save world key F6...
case SDLK_F6 & 0xFF:
GameEnv->GameWindow_Advertising->Advertise("Saving....", ZGameWindow_Advertising::VISIBILITY_HIGH,0,1000,500);
GameEnv->SaveWorld( );
break;

disable auto save

How deep is Blackrock Green? How do I find it?

it's like 64-75 down... and another 64 down is orange.

I key; great

-----
(SDL2 changes; SDL_CreateThread takes a name now (of the thread proc itself, instead of "thread_proc" maybe)
---------
My games aren't saving.
my last world2 I died, and saved hit escape and got out before being respawned.  Now I get console messags that say 'fatal fall...' something but don't die.   And when I move a couple steps and quit, it always starts where it was, including old worlds... hmm the binary download saves... wonder what I broke.