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.

Messages - d3x0r

Pages: 1 ... 3 4 [5]
Programming with Blackvoxel / Re: Voxel pixel selector box, render offset
« on: October 24, 2014, 02:29:38 pm »

Yes, compilers are replacing some divide by shift. But there is a trap...  ;)

Look at this program:

Code: [Select]
    int a = -64, b, c;
    b = a / 256;
    c = a >> 8;
    printf("Divide : %d\nShift : %d \n",b,c);

Oh I see... well I didn't change any operators....
that's interesting...
that does solve some boundary issues (or cause if not recognized)

Programming with Blackvoxel / Re: Voxel pixel selector box, render offset
« on: October 23, 2014, 04:40:54 am »
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(>>8) 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.

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 / Re: Voxel pixel selector box, render offset
« on: October 21, 2014, 03:28:56 pm »
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

Programming with Blackvoxel / Re: Voxel pixel selector box, render offset
« on: October 21, 2014, 08:19:56 am »
Ehm what?
I have no idea what you are trying to to say. Are you discussing the BV source code or some other code?
What is a voxel pixel?
Sorry I don't know your dictionary.  Voxel pixel is probably a redundant statement and should just be voxel... voxel block?

Of course I'm talking about BV code.
I ironed out a few more issues with changing 256 to a variable... there was a few place where shift operators were used.  Fixed the ZSectorSphere (which was actually IsPointVisible, which I broke by not using TransformParams class) usage so correct 'distant' things are rendererd.... there's also a near render ... I know because I had one working and not the other.

Now most everthing is good until I get to the first random land sectors, and I have sectors appearing in air, and sectors rendering and then not rendering and I'm just sitting still...  what class/function renders the first random landscapes? 

World_Genesis; and various functions there.  got it.... still don't know why.... I assume it's some base offset based on height map as a unit of real space?  something I dunno

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

Programming with Blackvoxel / Re: What things are already available?
« on: October 18, 2014, 05:20:35 am »
So overlapping textures is a known issue :)  The fire texture did the same thing...

Programming with Blackvoxel / What things are already available?
« on: October 18, 2014, 01:12:48 am »
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...

Programming with Blackvoxel / Re: Stair building script
« on: October 18, 2014, 01:05:24 am »
(didn't mean to reply)

General Discussion / Re: SDL2 and how to close gui's?
« on: October 17, 2014, 04:44:23 am »

Break out SaveWorld from End_PhysicsEngine()....

Code: [Select]
void ZGame::SaveWorld(  )
  ZStream_SpecialRamStream Stream;
  ZStream_File FileStream;
  ZString FileName;
    FileName = ZStream_File::Get_Directory_UserData();
  if (FileStream.OpenWrite())

  // Inventory Saving
  char Buffer[1024];
  sprintf(Buffer, "%s/%ld/PlayerInfo.dat", UniverseNum);


bool ZGame::End_PhysicEngine()

  // Save Physic engine actors

  SaveWorld( );

  if (PhysicEngine) delete PhysicEngine;
  PhysicEngine = 0;
  Initialized_PhysicEngine = false;

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

disable auto save :)

General Discussion / Re: SDL2 and how to close gui's?
« on: October 16, 2014, 08:47:48 pm »
I also threw together a cmake build script for the project since the make system was simple enough.
Need an option to set things like

Code: [Select]

Oh I see; I should have traced that back to its actual defintiion; assumed it was just undefined....

:) DEVELOPPEMENT_ON :) is spelled wrong
I guess the option should be more like

Code: [Select]
OPTION( DEVELOPPEMENT_FORCE_DEV "Build dev mode (disable save)" OFF )
OPTION( COMPILEOPTION_DEMO "Build demo mode (enable save)" ON )

or something....

General Discussion / Re: Newbie Guide?
« on: October 16, 2014, 08:53:44 am »
How deep is Blackrock Green? How do I find it?
it's like 64-75 down... and another 64 down is orange.

General Discussion / What I want to do....
« on: October 16, 2014, 04:17:43 am »
I have ...

On the left is a piece and a via connection thing, so you put down a block, and connect to it.
I want to work on a 3d version of the via(path) logic .

I'm going to allow diagonal block selection, with the assumption that I can patch in a diagonal block shape for filled edges... like I do with a 2d cell sort of thing...

like .. page 19 of this....

I'm pretty sure I can just hook my dialogs in... or make a alternate OnRender path and share a space.... probably remove SDL video; sdl sound seems OK other than it's not easy to just pass end of stream when no sounds... so it's always processing.  I used OpenAL with ffmpeg library....

and text labels over process blocks; maybe indicating how much carbon I fed it... it was not clear that many carbon followed by a metal uses all carbon, but it doesn't... it's like there was carbon left in the furnace.

You have a very large system of available processes; and the default theme appeals to me :)

(Dystopia game screenshot of matrix.)

General Discussion / Re: SDL2 and how to close gui's?
« on: October 16, 2014, 03:56:09 am »
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.

General Discussion / SDL2 and how to close gui's?
« on: October 15, 2014, 11:59:30 pm »
So I found the keys that generate mouse buttons (like scroll wheel) and I guess middle click is how to activate the user block cube; but the only way I found to close that is to hit escape which is save and exit...  can escape be pre-empted by gui screens to close?

SDL2... I grabbed this, only took them 10 years to come out with it :)  Not a lot changes... have to change the type of 'GameEnv::screen' and use a different function to open the window; and unfortunatly the display info stuff is different, ended up just chopping that out for a fixed value from the settings file.... the swap call takes the GameEnv->screen(window) variable...

Code: [Select]
#define SDL_GL_SwapBuffers()             SDL_GL_SwapWindow( GameEnv->screen )

/* .... in ZGame... */
#ifdef SDL1
  SDL_Surface * screen;
  SDL_Window * screen;

The sound system is different I guess; the last buffer is never cleared,
at the end of ZSound::MixAudio....

Code: [Select]
  if (nSounds) for (i = 0; i < Buffer_Len / 2; i++) ((Short *)stream)[i] = (Short)(SoundBuffer[i]);
  memset(stream, 0, len);
otherwise stream is not cleared when there were no sounds to mix, and that block keeps looping.

removed a lot of references to including SDL, since it's included in ZGame.h anyway and seems most everything ends up including that.

how do I exit a gui dialog?   is it easy to add a X button?

The method for the mouse is different; but a simple define can fix that

Code: [Select]
#define SDL_WM_GrabInput      SDL_SetRelativeMouseMode
#define SDL_GRAB_ON          SDL_TRUE
#define SDL_GRAB_OFF           SDL_FALSE

// otherwise warp mouse takes the window/screen as parameter
#define SDL_WarpMouse SDL_WarpMouseGlobal

Some missing/modified keyboard handling/mapping.  Have to take the sym & 0xFF a lot of places because they set a high-bit in it (1<<30)

Code: [Select]
#define SDLK_KP0 SDLK_KP_0
#define SDLK_KP1 SDLK_KP_1
#define SDLK_KP2 SDLK_KP_2
#define SDLK_KP3 SDLK_KP_3
#define SDLK_KP4 SDLK_KP_4
#define SDLK_KP5 SDLK_KP_5
#define SDLK_KP6 SDLK_KP_6
#define SDLK_KP7 SDLK_KP_7
#define SDLK_KP8 SDLK_KP_8
#define SDLK_KP9 SDLK_KP_9

SDL2 also changes how the scroll wheel is handled, instead of passing it as a button it's an axis, and they support horizontal/vertical scroll...  so my scroll wheel is broken for changing items, but I found the keys for now.

Pages: 1 ... 3 4 [5]