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 [2] 3 4 5
16
Troubleshooting & Bug Reports / Code Bugs
« on: October 23, 2015, 12:03:33 pm »
ZWorld.cpp
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


17
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...
https://www.factorio.com
short, quick start... guess this game is pretty deep....
https://www.youtube.com/watch?v=sMgtUxpGlPc
there's lots of other in-play videos

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

18
General Discussion / General Voxel Performance... no; no it's not
« on: October 07, 2015, 10:28:11 am »
Was going to mention this....
http://www.volumesoffun.com/implementing-morton-ordering-for-chunked-voxel-data/#more-1755
(references https://en.wikipedia.org/wiki/Z-order_curve http://www.forceflow.be/2013/10/07/morton-encodingdecoding-through-bit-interleaving-implementations/ )

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

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

19
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.
http://blogs.nvidia.com/blog/2014/03/20/opengl-gdc2014/

Did notice a few articles that OpenGL is faster tha D3D ...
http://www.extremetech.com/gaming/133824-valve-opengl-is-faster-than-directx-even-on-windows

20
General Discussion / Re: OSX port
« on: August 02, 2015, 11:21:28 am »
Re Deprecated register keyword...

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4340.html
http://stackoverflow.com/questions/10675072/is-the-register-keyword-still-used

I personally disagree that this should be deprecated... but apparently has, and will be removed in C++17.
There are certainly more ideally things the compiler can't figure out, and doesn't. I've seen worse and worse code generation by more modern compilers than things in the mid 90's. 

The argument goes like 'it was only a hint, and the compiler has register coloring anyway so it's meaningless.' but I've seen little effort by the compiler to preserve values in registers, mostly because by nature it assumes things are 'volatile' so it reloads them (I guess, can't otherwise figure why just bad code would be generated).

I certainly don't want people to go to inline assembly for something so simple since that's far from portable between compilers... this really all makes me sad.


21
General Discussion / Re: Contrib & Assembler & legacy projects
« on: January 09, 2015, 12:33:11 am »
FPLA programming with high level languages.
there are lots of registers available.  A register is a single bit, it can be used just like any input or output bit.

Every node fires at a clock and can process...


 Reg1 = Input1
 
all logical operators .... & | + - * / > < = .... get supported... with carry and overflow able to be redirected to other registers/outputs..

---------
When used on a BUS controller to communicate data between a PC and Modcomp computer, the chips had states.. basically a set of bits that are known internal registers get set to a known state on reset,

I would think though that a input/output/register (sh/c)ould be an analog value instead... which allows more operators like sin/cos/square wave pulse generator functions... which can be done at a digitial level also... a single register in a FPLA could be toggled and provide a /2 clock for some other function... shifting a value through several registers can provide delay-line short of character... by single clocks (not really recommended... since all states process at once, ended up isolating logics but... )

-----------------
This is a more modern thing, and I can see benefit in learning this instead... it's a decade ahead of altera chips
there's examples....
http://en.wikipedia.org/wiki/VHDL
http://en.wikipedia.org/wiki/Dataflow_programming

22
General Discussion / Re: Contrib & Assembler & legacy projects
« on: January 08, 2015, 08:46:36 pm »
I don't remember if I mentioned Alice...
http://www.alice.org/index.php?page=what_is_alice/what_is_alice

And microsoft has another model...
http://msdn.microsoft.com/en-us/library/bb483088.aspx  but that's dead long time... but it's .NET and sorta works... so it's got some longevity maybe

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

anyhow...

Looking forward to assembly...

Omega -
http://www.abandonia.com/en/games/29295/Omega.html (dos box)
http://en.wikipedia.org/wiki/Omega_(video_game)

c-robots
http://corewar.co.uk/crobots/
http://corewar.co.uk/crobots/crobots.txt (programming guide)

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

My automaton game (bugbrain) 
http://www.biologic.com.au/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)
https://drive.google.com/file/d/0B812EYiKwtkkai00aTlRYkZRU28/view?usp=sharing

--------
 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 .. http://en.wikipedia.org/wiki/Programmable_Array_Logic

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



24
Programming with Blackvoxel / Re: How hard could smoothing be?
« on: November 22, 2014, 03:53:07 pm »
Did some research on implementing glCallLists in my stuff; and learned they have been depricated... in favor of vertex buffer objects... which kind of makes sense, since you can create vertex buffers in threads asynchronous to the display... where glCallLists have to be built on the GL thread context...

so shaders and display buffer building as another pluggable renderer :)

I find that the resonable relation would be building buffers per shader per image source... or per block type; with shaders would think the 'default' blocks could be computation shaders based on a distance from poly edge and a color scalar...

and those built per voxel sector ....

there's also no multi-indexed buffers... like normals in this world I'd only need a buffer of 6 points, if I could have a index buffer for texture, index vertex and index normal independantly... but indirect uses the same index map for vertex/texture and normal so they all have to be the same length...

http://stackoverflow.com/questions/11148567/rendering-meshes-with-multiple-indices for instance indicates it can be done, but it's more work than benefit.


25
Programming with Blackvoxel / Re: Custom VoxelTypes
« on: November 18, 2014, 04:11:21 am »

Hum, I wouldn’t recommend doing this.

The way the storage was made is for memory bandwidth efficiency.

Packing these data will lead to waste an important amount of memory bandwidth.

This is a weird side effect of how modern processors access memory with prefetch mechanisms and important bus width : processors can't fetch only a byte or short.

Sectors are 16384 indexes... voxel types are 2 bytes... so 32k or 8 4k pages.
TempInfos is another short for block temperature; this should probably be in an infos since in general blocks don't change behavior based on tempurature....
OtherInfos is 4/8 bytes to reference voxel instance data; VoxelExtension*... 

all together 341 + 4 bytes to 512 per page..........

total is 32k + 32k + 64k(32 bit)/128k(64 bit)  (I've been running 64 bit build, because I have more sectors of smaller voxels usually)

128k/192k ..  32 or 48 pages (4096 bytes) for a sector...

-------------------
I made a branch at that point... I wasn't sure how much of a performance hit it would be... I'm aware of cache... *see below*

I guess given the defined scope of the project
for the renderer which only needs voxel type, then it needs to only fill 8 pages instead of 48... given no custom render for custom voxels... (color shading)... although maybe renderer uses TempInfos to determine texture... so 16 pages; even if blocks are rarely shaded, so temp isn't checked always... could be less...

voxel reactor uses (tempurature?  does temp get modified except by time and water?  Does it dissapate?  Each voxelType have a thermal coefficient thing? :)  ) and OtherInfos... unless a highly static level is used with non extended voxels... with an active environment, OtherInfo will definatly be cached... so no 8+32.. 40 pages loaded without tempurature... so there's no real savings at this level...

Feature: at a voxel-is-center-of-universe view, if I'm given an offset to my data, to get near voxel's (extended)data... I dunno I guess I still need the sector reference...

so ya... a highly static map benefits from only needing 32k loaded for working with a sector (plus another page for the sector, and another for the voxel type manager) ... but then again in a 1M cache 32 sectors can potentially be loaded... so that's only a few more than the block of 9 around the player at any point... so it still has to scroll through the memory...

....
in a sequence of processing blocks, only 4-6 pages are used ... (the center, left/right) (above and below) (forward and backward) , especially on boundaries of sectors... I dunno; the working set is still the same.... this is tripled with the current scheme... because mirror otherinfo, tempinfo pages may be used... 12-18 working set pages...

it resulted in more efficient assembly because there was only one pointer and other offsets computed from that...in the other place I was looking at I do remember noting that...

It may be arguably better if they were allocated all together... and put all voxeltypes and all tempinfos and all otherinfos together instead of interlaced, but with a single pointer...

What is lost is gained in other ways.... and I don't notice a particular performance hit from this change...

--------------

Once upon a time I got to play with/use a logic analyzer that decoded the pins interfacing from 386 to motherboard... got to see read/write memory to fetch instruction blocks... so there's the clearing of cache on calls and jumps backward... jumps forward are better handled by setting a ignore flag and processing the prefetch cache anyway... kinda like how arm handles short jumps.... but anyway... it's just much wider now... and burst mode...

26
Programming with Blackvoxel / Re: Custom VoxelTypes
« on: November 16, 2014, 12:26:08 am »
A large performance increase can be made in the water processor...

Code: [Select]
// original
                              for(i=0,j=4,vCount=0,WaveCount=0;i<4;i++,j++)
                              {
                                cx = x+bft[i].x ; cy = y+bft[i].y ; cz = z+bft[i].z ; SecondaryOffset[i] = If_x[cx]+If_y[cy]+If_z[cz];St[i] = SectorTable[ Of_x[cx] + Of_y[cy] + Of_z[cz] ]; Vp[i] = &St[i]->Data[ SecondaryOffset[i] ].Data;
                                cx = x+bft[j].x ; cy = y+bft[j].y ; cz = z+bft[j].z ; SecondaryOffset[j] = If_x[cx]+If_y[cy]+If_z[cz];St[j] = SectorTable[ Of_x[cx] + Of_y[cy] + Of_z[cz] ]; Vp[j] = &St[j]->Data[ SecondaryOffset[j] ].Data;
                                if (VoxelTypeManager->VoxelTable[*Vp[i]]->Is_CanBeReplacedBy_Water && VoxelTypeManager->VoxelTable[*Vp[j]]->Is_CanBeReplacedBy_Water) {vCount++; DirEn[i]=true;}
                                else DirEn[i]=false;
                                if (VoxelTypeManager->VoxelTable[*Vp[i]]->Is_CanBeReplacedBy_Water) {WaveCount++;WaveDirEn[i] = true;}
                                else                                                                {WaveDirEn[i] = false;}
                              }

// modified; move the test for (*Vp ) as a common point, then Vp[j] doesn't have to be computed, or tested, because it's an and condition with Vp
Code: [Select]

                              for(i=0,j=4,vCount=0,WaveCount=0;i<4;i++,j++)
                              {
                                cx = x+bft[i].x ; cy = y+bft[i].y ; cz = z+bft[i].z ; SecondaryOffset[i] = If_x[cx]+If_y[cy]+If_z[cz];St[i] = SectorTable[ Of_x[cx] + Of_y[cy] + Of_z[cz] ]; Vp[i] = &St[i]->Data[ SecondaryOffset[i] ].Data;
                                if (VoxelTypeManager->VoxelTable[*Vp[i]]->Is_CanBeReplacedBy_Water )
                                {
                                  cx = x+bft[j].x ; cy = y+bft[j].y ; cz = z+bft[j].z ; SecondaryOffset[j] = If_x[cx]+If_y[cy]+If_z[cz];St[j] = SectorTable[ Of_x[cx] + Of_y[cy] + Of_z[cz] ]; Vp[j] = &St[j]->Data[ SecondaryOffset[j] ].Data;
                                  if( VoxelTypeManager->VoxelTable[*Vp[j]]->Is_CanBeReplacedBy_Water) {vCount++; DirEn[i]=true;}
                                  else DirEn[i]=false;
                                  {WaveCount++;WaveDirEn[i] = true;}  // bad braces
                                }
                                else  {WaveDirEn[i] = false; DirEn[i]=false;}
                              }

50% processing time reduction

27
Programming with Blackvoxel / Re: Custom VoxelTypes
« on: November 14, 2014, 06:12:28 am »
Voxel extensions don't come from pooled memory.
Moving a voxel from one place to another that has extension causes new and delete operators; and the new voxel is not the same as the prior... (maybe there's a copy operator)...

but also there is no 'move voxel to' or 'swap voxel with' which could move the reference to the original voxelExtension.

So motion is (set new voxel, create extension ) (clear old voxel, delete old extension)

28
Programming with Blackvoxel / Re: Custom VoxelTypes
« on: November 12, 2014, 10:00:54 am »
Managed to add Aroma Generator and Aroma types.
Aroma diffuses itself such that if it is near itself, it moves away from itself, otherwise if it is not in free space it moves.  I dunno basically it works pretty well... gave me something to think about regarding inter-mingling voxels, and various things... like 'wind' .... and what it actually is useful for... and what meaning it would have...

the particles also age-out so after 12 seconds they evaporate... but worked good for a long time without despawning... also had a really cool overflow that resulted in a solid growing bubble form... not sure if the inside was just solid transparent of it if was just the outside sheet somehow... but it's fixed now and that was a memory fault anyway...

https://github.com/d3x0r/Blackvoxel/blob/group_voxel_datas/src/ZVoxelType_AromaGenerator.cpp
https://github.com/d3x0r/Blackvoxel/blob/group_voxel_datas/src/ZVoxelType_Aroma.cpp

also; in consideration of making a container for voxels, needed to know what a voxel was, so I reimplemented Sector->Data,OtherInfos,TempInfos as VoxelData *Data;

https://github.com/d3x0r/Blackvoxel/blob/group_voxel_datas/src/ZVoxelSector.h#L203

------------
just messing around... it is rather stable backend for dynamic updates to voxels ...

noting that there should be some more standard routines... like to get the array of voxels around a single voxel...

----------
Oh; a sector reactor... to do computations between sectors... could use a point per sector as a air pressure, and create a gradient between sectors for 'wind'... wind as a velocity could represent a propability of motion in time rather than a linear motion....

1.0 = 1 voxel in (100ms?) a 1 tick... how long is a 'tick' target?
0.5 = 50% chance to move 1 voxel in 1 tick.. something... for partial motions... I guess use the fraction as a proabilty to move one more (if available )... might work


29
Programming with Blackvoxel / Re: Custom VoxelTypes
« on: November 10, 2014, 12:52:38 pm »
Hmm... does the mem pool really help?  Is new and delete not really based on malloc/free?  Glibc usually collects garbage pretty well... I had my own memory allocator that was in the core of my library; still do, just hard to initialize a dynamic program without having initialized memory; and sometimes core debugging becomes impossible....

In my library I made a set allocator which is a linked list of nodes that have a bitmap mask of used mono-sized nodes... also keep a counter of used nodes so can just check if all used, otherwise scan the bits 32 at a time until it's not ~0 ... otherwise allocates a new block of nodes... so all nodes are continuous in memory ...

even if you're recycling previously allocated things, they're still jumbled all over memory....

30
Programming with Blackvoxel / Re: MSVC or non-GCC Porting
« on: November 10, 2014, 11:24:25 am »

Stack overflow 'compare and swap atomics...'
Quote from: StackOverflow

On Mac OS X and Windows there are builtin CompareAndSwap functions you should be using anyway (InterlockedCompareExchange() and OSAtomicCompareAndSwapPtrBarrier() respectively). Thus will work regardless of the compilers on those platforms.

How to get predefined macros...
Quote
Code: [Select]

Command lines
Compiler C macros C++ macros
Clang/LLVM clang -dM -E -x c /dev/null clang++ -dM -E -x c++ /dev/null
GNU GCC/G++        gcc   -dM -E -x c /dev/null g++     -dM -E -x c++ /dev/null
Hewlett-Packard C/aC++ cc    -dM -E -x c /dev/null aCC     -dM -E -x c++ /dev/null
IBM XL C/C++     xlc   -qshowmacros -E /dev/null xlc++   -qshowmacros -E /dev/null
Intel ICC/ICPC icc   -dM -E -x c /dev/null icpc    -dM -E -x c++ /dev/null
Microsoft Visual Studio (none) (none)
Oracle Solaris Studio cc    -xdumpmacros -E /dev/null CC      -xdumpmacros -E /dev/null
Portland Group PGCC/PGCPP pgcc  -dM -E (none)
looks to me like also ICC is a gcc variant that might (and on further research it does....)  and maybe that hewlett-packard version...


Modified location to "ZOs_Specific_Various.h"
modified define test to #if defined( _MSC_VER ) || defined( __WATCOMC__ )
for known exceptions.


Pages: 1 [2] 3 4 5