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
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 / Re: OSX port
« on: August 02, 2015, 11:21:28 am »
Re Deprecated register keyword...

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.

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

General Discussion / Re: Contrib & Assembler & legacy projects
« on: January 08, 2015, 08:46:36 pm »
I don't remember if I mentioned Alice...

And microsoft has another model...  but that's dead long time... but it's .NET and sorta works... so it's got some longevity maybe

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 / 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... for instance indicates it can be done, but it's more work than benefit.

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

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

                                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

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)

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

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;

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

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

Pages: 1 [2] 3 4 5