Recent Posts

Pages: 1 ... 8 9 [10]
91
General Discussion / Re: Dynamic fonts
« Last post by Enigma on November 20, 2015, 01:23:02 am »
Hi d3x0r,

That's a great job you are doing here. And we are really proud to see you are using Blackvoxel as a base for your game. :)

Maybe the start of a great adventure for you.

The choice of C# is slightly surprising to me  :o. But why not if you like it... so I'm just curious to know why you choose this language.

Why not a C# robot. I'm not a C# expert at all, but that could be interesting to add one in Blackvoxel. Our long term goal is to add many languages. (The problem will be how to make it in a "clean" way).

I see you have mentionned that your work is derived from blackvoxel, that is right.
I know your code is at a preliminary state, but there is something very important you must add in your code ;). As a derived work of a GNU GPL v3 software, you must mention the GPLv3 licence AND original copyrights, both on a Copyright/License files and in the headers of the source code. (GPL V3 Licence).
That's not only for legal reason about the Blackvoxel license, but also for the guys crawling on your github : Even if your game is only in source form at this time, someone could go into your github and take code or assets without knowing licencing conditions. Imagine someone make proprietary software with it or simply use this code without mentionning copyright, they can and end up with troubles with us (Blackvoxel code was legaly registered in order to protect the licence).
Third party libraries should also be listed with their copyrights, authors and licencing conditions. Cross compatibility legal issues should be avoided.
Above legal reason, that's important for authors and contributors to be listed : that could help some to find a job.
I understand (as I remember that by the past, you said) you are not aware of all theses picky legal stuff . But we have worked a lot (and unfortunately spent a lot of time) about these legal details in order to avoid problems.
But, don't worry, we can help you and explain what must be done and even help you to write some of these "legal stuff" files for you.

That could also be interesting for you to know why we made the choice of free software. And why we choose the particular GPL V3+ licence that is a free licence, but somewhat restrictive in some way compared to MIT or BSD like licences : In few words, a software derived from a GPL v3+ free software must be a GPL v3+ free software without exception. That's a way to protect the work for free software programmers : Everybody can use the code freely and make their stuff with it, but in return, they must do the same. Of course, licencing terms have heavy consequences depending on your goals.

About the font class, that's an interesting developpment. As you know, in Blackvoxel, we made a particular design choice with "8 bit computer style fixed font" kind of text. But as you know the font rendering system is made only for this particular case. The static rendering way of vector font is a good choice. No need for dynamic one that would be... slower.  :)

Even if ores aren't un-minable by hand in Blackvoxel, the required quantities to make an airplane are very important for simple hand mining. But I'm not completely sure that every players understand that. In the future, there will be more in-game tutorial and missions to help player to understand what are the best ways. Blackvoxel is a long term project and there is a lot of things remaining to do.

About physics engines, I can't say what is the best depending on what you want to do. Including vector entities or making multi-grids interactions might mean different approachs. In Blackvoxel, the choice of an unique grid and "pure voxel" interactions is a strong choice. But we understand that someone wanting to make a different game could want some different choices. The two library you mentioned are free and have compatible licence.

The ability to well sandbox code in C# is interesting. C# is a fast and efficient language compared to little scripting ones. Of course, not as fast as C/C++, but C/C++ is unsuitable for doing sandboxed parts(unless wanting to play with heavy hardware processor sandboxing stuff...).

The Blackvoxel Team
92
Programming with Blackvoxel / Re: Tips with assembly code
« Last post by as3ii on November 19, 2015, 08:01:52 am »
Ok, thank you for the explanation!
93
General Discussion / Dynamic fonts
« Last post by d3x0r 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 https://github.com/nothings/stb/blob/master/stb_truetype.h which is part of  https://github.com/nothings/stb

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.
94
Programming with Blackvoxel / Re: Tips with assembly code
« Last post by Enigma on November 18, 2015, 11:44:26 pm »
Hi, as3ii... and welcome to the blackvoxel forum  :)

The problem about "the real assembly" is that there's not one, but a lot of very different "real" assembly languages.

Each different microprocessor or microcontroller type have it's own. And there's a lot of processors on the market...

The idea behind the virtual processor in the Blackvoxel assembly robot was to focus on basic principles and understanding the role of each different instructions categories.

Even if instructions can be named differently on different microprocessor, you'll find rougly the same principles and instruction categories.

The processor you are speaking about is significantly different. It's architecture is based on the old Motorola 6800 that got out in the market in 1974. Unfortunately, a lot of little microcontrollers on the market still use some old design.

In the other hand, more recent microprocessors(including the 68000 that was the successor of the 6800) made very different architectural choices. As an example, the single accumulator concept and the specialised (index) registers was replaced by a bunch of multi purpose registers. So you wont find the LDA or LDX instructions anymore on recent designs.

The choice on the Blackvoxel's robot processor was rather to make something simple and modern. That explain the differences with your microcontroller.

In theory, it is possible to implement the real instruction sets of a real microprocessors in the blackvoxel robot. But that would be an important work to implement the instructions sets of all real processors on the market.

As we have little ressources at this time, I'm afraid there is nearly no chance we add this in the todo list for now. But if someone want to contribute to write something on this, he is welcome. That could be a good exercice for a student.

About the list of address, there is some documentation here including description of registers and bits of the virtual circuits used. As I assume you have already seen these documents, I guess maybe you suggest something different, like a synthetic register list of all registers ?

But remember that we emulate a computer (and not a microcontroller). Unlike microcontrolers, registers in  simple computers are not always tightly packed in memory space (because chips address space are often decoded in a simple way there is some gaps betweed circuit memory spaces). That's why chip registers in computers are often listed on a circuit per circuit basis.

That said, we think that making a synthetic register map could be a good idea. We'll think about it.

The Blackvoxel Team
95
Programming with Blackvoxel / Tips with assembly code
« Last post by as3ii on November 17, 2015, 11:41:15 pm »
Hello blackvoxel-team,
I'm a student and I'm studying assembly with freescale MCUs (MC9S08QG8). Can you change your language and use the real assembly? Your programming language is very different from the real assembly.
Thank you for your good work!

(P.S: Can you make a list of  address, names and Bit assignments of all registers? Can you add the lda (and ldx) and sta (and stx) assembly command? Thank you!)
96
Troubleshooting & Bug Reports / Re: Code Bugs
« Last post by Enigma on October 25, 2015, 12:58:22 am »
hi, d3x0r,

Thank you for finding this bug. This one could have made problems.  :o

I should also check other face culling functions : in Blackvoxel, this work is distributed among several modules in several threads.

This function (ZWorld::SectorUpdateFaceCulling()) is dedicated for cases where a complete sector needs to get a full face culling.

A little summary about Face culling in Blackvoxel...

The birth of sectors occurs in the ZFileSectorLoader object powered by a dedicated thread. After creation or loading, the face culling of the sector core voxels are computed using ZFileSectorLoader::LimitedUpdateFaceCulling(). Sector's external faces aren't done : at this point, the sector isn't integrated to the world(the concept of world isn't yet existing), so data are missing to compute face culling for boundaries : neighboring sectors are needed for that.

Further, sectors are integrated to the world by the main thread. But remaining culling is done by a third thread along with the MVI engine. When some inter-sector face culling is remaining to do (Indicated by the multi bit field ZVoxelSector::PartialCulling), it's done by the ZWorld::SectorUpdateFaceCulling_Partial() function. This function is doing the face culling link between sectors and can do selective work side by side as soon as some neigboring sectors become availlable.

Some face culling is also done in ZWorld::SetVoxel_WithCullingUpdate() when individual voxels are modified.

The Blackvoxel Teams.
97
Troubleshooting & Bug Reports / Code Bugs
« Last post by d3x0r 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

98
General Discussion / Re: General Voxel Performance... no; no it's not
« Last post by Enigma on October 10, 2015, 02:40:31 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.

On a quick analysis, I guess there could be some advantages if most access on the grid were random and combined with systematic access to neighboring voxels.

But that's not the common case in Blackvoxel. So you are right. That would be a false good idea (at least for this particular game).

Anyway, that's interesting to see some ideas trying to make improvements  ;).

The Blackvoxel Team
99
General Discussion / Similar game?
« Last post by d3x0r 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?
100
General Discussion / General Voxel Performance... no; no it's not
« Last post by d3x0r 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.
Pages: 1 ... 8 9 [10]