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

Pages: 1 2 [3] 4
31
General Discussion / Re: Voxelarium.js
« on: June 01, 2016, 05:27:00 am »
That's Nice.

The 8 bit fonts are well in the Blackvoxel style. (Don't forget Blackvoxel is in one word  ;))

And that's remember good old days of early personal computing when we where young...

As we are programming rarely with Javascript, we can't help you about what are the best tools and libraries to use with it.

We'll go to look at your github as soon as we'll have some little time.

The Blackvoxel Team

32
General Discussion / Re: Just started using this engine today!
« on: June 01, 2016, 05:25:06 am »
Hi, and welcome to Blackvoxel.

Glad to see you enjoy Blackvoxel engine and it's universe style and mysterious ambience.

We are happy to see some creators to find interest in free software development.

Textures for the Blackvoxel engine are easy to do because of it's lighting model.

We would be very interested to follow your creation.

Good work ;)

The Blackvoxel Team

33
General Discussion / Re: Voxelarium.js
« on: May 26, 2016, 06:00:52 am »
Hi D3x0r, glad to have news from you...

Quote
I got tired of the C# port already :)  (never did finish actually implementing the game portion of it... just water)

We understand that.

Unfortunately, video games are kind of program that requires a tremendous work.

Quote
Started a new javascript/three.js version...

https://d3x0r.org:444/javascript/Voxelarium.2

click and drag; 's' enables moving scaling, it's not very good... faster than scroll wheel though

it's actually broken into separate files on the source side; fed through 'browserify' to make it simple to load on the web page.... but you can save the page and have all the sources; soon to make a github branch for it

(the mode buttons don't do anything any more; I also did a test ... https://d3x0r.org:444/javascript/test3d )

(although it's more inspired by, and plajurizing a couple algorithms like sectorSphere :)

That's a pretty interesting example. I guess it's using WebGL capability of the browser.

There's a lot of things to do with modern browser capabilities.  :)

The Blackvoxel Team

34
General Discussion / Re: Hoping for some help getting started
« on: March 12, 2016, 11:28:43 am »
Hi, I just downloaded this game and I'm really liking the concept of it. But alas, I have no clue at all what to do. I saw in a different forum post that someone received a very helpful "newbie" guide, and that's really great, but what I want is someone's opinion on whether or not this game is something for a casual player like myself. I know nothing of programming and the idea of switching between the game and the manual all the time is a little annoying but I can look past that. But is the game worth playing if I can't program any personal preferences into it?

Ps. I noticed there haven't been any recent posts on here. Is the game still in production? And thanks in advance for any help.

Hi Nemnadogg, welcome to the Blackvoxel Forum.

Yes, the game remains in production and there is no plan to stop.

Like most Free Sofware,  that's a long term project that (we hope) will have no stop and no end.

At this time, progress on development depend on our time, so that could go faster or slower.

Activity on the forum are usually higher when there is big updates and usually goes down in between.

About your question on a "newbie guide", a quick tutorial is here : http://forum.blackvoxel.com/index.php?topic=64.0

For programming, there is also the first lesson on our youtube channel : https://www.youtube.com/user/Blackvoxel

About programming, it's not mandatory at all for playing Blackvoxel. This game can be played like any other adventure games. At this time, programming is only an option you can choose in term of game to see what programming can help you to achieve. That what is making Blackvoxel a good educational programming learning playground.

Yes we think Blackvoxel can be played by a casual player. But that could depend on what you like in games. Blackvoxel is an adventure and sandbox game where the goal is to explore this mysterious world, encounter very unknown things and situations and find how to deal with these. So the game will be suited for you if you like to take time to explore, discover... and build. And like in all games with total freedom, some of the goals are up to you...

What I can say to help you about the game goals are :

As you start with nothing, the goal of the game is to develop technology, tools, vehicles, means to explore the world and make things around you "more friendly" :

You'll have to build what we call a "tech tree" : collect resources to build tools. Use tools to build machines, use machines to make other machines. Use machines to make parts. Use parts to make vehicles, tools and machines.

The first goal should be to build some new constructor/destructor tools in order to dig faster and be able to collect some voxels that your "first tool" is unable to grab.

The second goal is to build some extraction robot to get mining operation automated. Achieving this need to master the metallurgy part of the game.

Ultimately, the ending of the "tiers 1" actual game is to build the airplane, takeoff and fly to discover the world.

The game universe is made of "zones" made of square rings around the central blue area you started on, each with it's own looking and dangers.

So one other goal of the game is to discover each of these zones and to get trough each to discover the next one. Very unknown things are to be expected...

Don't hesitate to ask if you have other questions about the game.

The Blackvoxel Team

35
Suggestions / Re: Some ideas for more user friendly features
« on: March 12, 2016, 11:13:32 am »
It would be really great if this game was a bit more user friendly. Sure there are shortcut keys to a bunch of stuff, but a menu option outside of the inventory would really be heavenly. Maybe some labels for the materials. A bit of an in-game manual/blueprint book. It just seems like this game was made for people who have experience with it already, and that just doesn't make sense.

Don't get me wrong, I think this is a great game, but as a casual gamer I want something I can just jump into and lose a few hours with. Going between the game and the manual is really immersion breaking, so some in-game instructions would be great enough that I could completely look past any other flaws.

Also I'm confused about something. The manual says that blackrock green can be found in the blue flat-zone, yet there is an entire zone made up of green. Is that just outdated information, or am I misinterpreting here?

Hi Nemnadogg, thanks for your very good suggestions.

Yes, as you guessed well, the starting Blackvoxel's primary target are regular players rather than casual gamers.

With this kind of game it's not easy to start directly with casual users in mind. Making complicated concepts accessible is possible, but unless you have important resources, it always takes time.

But as a long term project, we are working to make the game gradually more and more suitable for less experienced players.

What we are planning in the future to make beginners life easier is to make ingame tutorials and game missions with progressive learning goals. These features will break the difficulty to understand the game and it's goals.

About making the game manual "in game", that's a good idea that was already suggested by some users.
Unfortunately, the cost in development time for this feature would be huge. That explains why in games manuals are so uncommon in video games.
But we hope that maybe a day will come where more users will support free video games and we'll be able to get resource to make such kind of feature.

At this time Blackvoxel goes already further than many games in providing direct connection between game and manual. Just press "F1" key while pointing a voxel and it will launch directly your web browser at the relevant page about this particular voxel. We suggest you to use windowed mode as it will help to make transition between game and your browser more "friendly".

Yes, the manual said Blackrock green voxels can be found in the blue flat zone... and that's true (it's underground).  But this information is intended only as a clue where to find it, not as a list of all the place you'll find Blackrock green. Maybe we should say it's not the only place you can find it.

We wish you a good game...

The Blackvoxel Team

36
Oh, that's nice...

Welcome to the Blackvoxel Forum, Karats  :)

We see you managed to understand how the Assembly robot is working without example.

Guess you already have some good knowledge about hardware to have made this...

Yes, examples about programming assembly robot are missing. We'll publish some examples to help understanding.

We'll give you also some though on your program to help improve it.

The Blackvoxel Team

37
General Discussion / Re: Dynamic fonts
« on: November 29, 2015, 08:18:04 am »
Hi, d3x0r,

Sorry for my late response...

Unfortunately, I was verry busy this week.

The choice was primarily that C# comes with the compiler itself so it can build itself.  If you install C# you install the compiler.  It's certainly not without penalties though... like without resorting to 'unsafe' code you can't use pointers to walk arrays, and every access to an array is bounds checked against the instanced array boundaries.  In C# 'struct' is actually a different behavior from 'class' in that struct is a value type like int or float, where classes are always reference types.  So primitives like vectors are good as struct types, but you can't keep a reference to a struct; you can pass a reference to a struct to a function, but can't say 'use that struct over there for this'.  *shrug*

As you seem to know well the pro and cons of this choice and you feel that's the way you want to follow, that's good.

About the problem of installing some language runtime along with a program, in Linux, that's really simple to solve : package managers provide dependency management.

But with Windows, that's a true problem.

Quote
Adding an interop module could have been done; but not without huge expense.  It's not so easy for MS C# and would have to be done with Mono, which is quite a download; but seems to work pretty well for Unity.

We are thinking about this kind of module for Blackvoxel since some time because a lot of people told us "I want to use Blackvoxel with my favorite language".
This include some functionnal languages like Scheme...
But the idea isn't yet mature as there is a lot of considerations and maybe different ways to do depending on the languages.
Some languages could be embedded while others would be better added through some kind of communication.

Quote
I'll spend some time today updating sources; in the process of the porting I created original files and copied header/source file contents as appropriate.  (Actually make that past-tense.)  I have no issue propagating GNU GPLv3 to this :)

Ok, I saw you put the headers, copyright mentions an global licence files with GPL V3.

We'll look on that when we'll have time and eventually make some remarks if needed.

Dont forget to put some header licence on all your own new files (You forgot on some).

Quote
Yes I know all about the 'style choices' :)  I just figured I'd mention it as it was a small source addition (some 3000 lines) and not a lot of work to implement; though does remove stylized look; and ends up making rather fuzzy characters when blown up large.  Looks nice in small cases.... will have to provide a couple different renderings in the future for things like the large text on the main menu.... a slowdown of only a tiny fraction of a percent in the grand scheme; except the one-time hit to render to the texture when a character doesn't exist.  *shrug*  It still fits within the idle time of a frame at 60fps... 

Yes, vector font are nice but the counterpart is the needs to manage the different size.
There are different approach for this problem.
Some are converting vector fonts to polygons. Some other are caching different sizes on different textures.
As I understand, you want to make rendering character textures on an "as needed" basis.
As a comparison to fully prerendering all size and fonts at startup, I guess you expect some gain (memory ?) as a counterpart ?

Quote
Actually; ores don't last 'forever' but instead are consumed over time, apparently removing the furthest block of ore attached to a seam until it's all gone.  I hadn't played long enough to exhaust an ore until yesterday... then I had to move my coal and tin drills to another vein.

Yea; I didn't actually make it to genuinely making a plane, and instead ended up enabling creative mode and just created one :)

It seems some players prefer playing with the game than playing in the game ;)

But... why not.

Quote
Actually javascript is all the craze now; the Chome V8 javascript engine actually emits native instructions and is very fast; amazingly so given the generic-ness of javascript.

Yes, there are some guys that just want to put some javascript everywhere... even in micro-controllers  ::).
No need to say I'm not convinced with some of these "uses" nor by the Javascript language itself.
That said, a Javascript Robot could be added because it is an "everyday use" popular language.
As you said, some Javascript runtimes are really efficient.

Quote
Medieval/Space Engineers is C# entirely; they use Havok as a physics engine.  https://github.com/KeenSoftwareHouse/SpaceEngineers
I've seen quite a few C# games coming out so I guess it is a viable platform for rather large spaces.  I'm still iffy on this whole garbage collection thing and would much rather release/delete things in a controlled manner.

Maybe good programmers can make good games whatever language they use.

But "large space" can mean different technical considerations depending on the game.

I don't know what Space Engineers does as I'm avoiding looking their game code : I believe that doing so would break my creativity.

C/C++ is faster in performance and provide more fine control. But the managed languages like C# or Java can help to develop faster and avoid some kinds of weird bugs caused by "crazy pointers".

Anyway, it's difficult to compare different games and approaches. And no one can say what Minecraft or Space Engineers would have been if made in C/C++.

Quote
I'm using OpenTK as the graphics interface layer (which provides OpenGL and sound in theory)  But I have yet to have any sounds ported.

As I understand it's something equivalent to SDL. But I can't give any though on that.

Quote
BEPU has a voxel physics demo - it is the engine for Lemma http://lemmagame.com/ https://github.com/etodd/Lemma  which is another voxel based game.  The demo source includes creating a custom voxel collision shape handler; basically it's a large array of bools instead of building actual box shapes and stuffing them into a compound object.  Will be interesting :)

That's an interesting approach. It's mean you have to update your array from the grid... which takes some overhead. But this doesn't mean it's bad : physics engine could maybe take advantage of data on a particular format and maybe could have lost more time in accessing directly the grid. Too difficult to say without a deep analysis.

Anyway, the use if an existing physics engine is a significant time saving.

The Blackvoxel Team

38
General Discussion / Re: Dynamic fonts
« 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

39
Programming with Blackvoxel / Re: Tips with assembly code
« 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

40
Troubleshooting & Bug Reports / Re: Code Bugs
« 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.

41
General Discussion / Re: General Voxel Performance... no; no it's not
« 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

42
General Discussion / Re: OpenGL Performance
« on: October 03, 2015, 02:49:24 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

Hi d3x0r, glad to see you :)

Thanks, I'll look at that. It seem very interesting.

This move of the graphic industry in driver overhead reduction is really positive.

As you know, that's especially true for a game like Blackvoxel because of it's massive playfield refresh.

With the new API generations, they are also moving on a more low level approach, which mean (at least in theory) more flexibility. And maybe (I hope) something better suited for the particular case of rendering voxels.

We also hope the new Vulkan API will be as good as the promises.

43
Suggestions / Re: Website css
« on: August 17, 2015, 02:28:08 am »
Hello MUY_Belgium and welcome to the Blackvoxel forum  :)

Tank you for this useful suggestion.

Thats done !

If your computer have modest hardware, don't forget to take a look at our optimization tutorial :
https://www.blackvoxel.com/view.php?node=1248

In particular, in the Settings_Hardware.dat file, two fields can have a tremendous effect : RenderingDistance_Horizontal and RenderingDistance_Vertical.

By lowering the values on these two fields, we managed to run Blackvoxel on a monocore atom netbook with only 1gig Ram(and GNU/Linux).

The Blackvoxel Team

44
General Discussion / Re: OSX port
« on: July 29, 2015, 11:53:25 pm »
    This is running natively. It took about 4 hours work of source modification, adding extra platform checks everywhere necessary, but most were identical to linux (the things that were unix filesystem operations). It took an hour to get SDL 1.2 working with the mac-specific header files, and to work through a bunch of linker errors. It's a very messy job, but the main outcome is it didn't actually require that much work, and I'd be happy to help more on it. Otherwise the Mac system OpenGL frameworks (libraries) were easy to link to.

    I started trying to use clang (Apple LLVM compiler) with makefile, but couldn't resolve linker errors, so I imported into an Xcode project so it would manage compiling properly. Having got it to run now though, the makefile could be fixed to work.
    BTW there were 395 compiler warnings -- your C++ is a bit outdated and messy :D
    (BTW the 'register' tag is completely ignored by modern compilers, that was most of the warnings)
    There are some obvious problems and as I'm a complete noob to the game I don't actually know how to play to test more things, but generally it worked and created a universe and loaded it.

    Confirmed working:
    • Game graphics
    • World gen, save & load
    • Movement (WASD, jump)
    • Placing voxel (at least the one that was in inventory to start)
    • Key mapping
    • Fullscreen & windowed

    Not completely working or not working at all:
    • Audio (kinda works, but system complains it's using deprecated API. Upgrading to SDL 2.0 would fix). Volume setting has no effect
  • Opening inventory ('I' key) didn't seem to work? Not sure why
  • Retina graphics (this is normal, no openGL games support retina well)

BTW J'ai remarqué que vous êtes français -- je parle français bien mais je vais mieux à comprendre qu'à parler/écrire (j'ai aucune doute qu'il y a plusieurs d'erreurs dans cette phrase).

Congratulation for this work  :)

We'll try to help you as far as we can....

About SDL sound, we already got sound problems on Windows depending on how the SDL library is compiled. The problem with SDL audio is that this library is built differently depending on which audio library header was detected. As we understood, if no "modern" audio system header is detected on SDL compilation, it revert on some kind of default codepath.
We suggest to try a precompiled library from the official SDL website to test if it's working better.

We'll certainly make an SDL 2 official transition soon. (That's a change the core team will do all internally because that's an important move, we have to master it).

At this point, the "not working" inventory seem to be the only serious issue.

The inventory opening is triggered in ZGame_Events.cpp at line 869.

First, we suggest you insert a breakpoint (or a printf) into the "if" block to see if the execution reach in when you press the "I" key. If not the case, it could be a problem about keyboard scancode.

If execution enters well into the "if", make the following tests :
Look at the sidebar : does the sidebar is displaying well ? (Image showing the sidebar at the right of the screen http://www.blackvoxel.com/view.php?node=1239).

Try to hit the "F12" key : A little transparent window should show on the upper left of the screen displaying framerate. (This test is for ensuring that the Blackvoxel windowing system is working well. )

An opengl display problem is always possible, but very unlikely as we choosed a "most compatible" way to make display an never get any serious opengl display problems despite various drivers and platforms.

As we understand, you used the LLVM compiler. As currently, the status of Blackvoxel is "untested" with LLVM, we can not exclude the possibility that some problems can come from.

Like a lot of video games, Blackvoxel uses a rather "low level" programming style and a lot of optimisation (in order to make the dynamic MVI concept running at a good speed : http://www.blackvoxel.com/view.php?node=1569 ).
That can make compiler little differences more important than in regular programs.

Ultimately, if nothing else works, we suggest to make a try with the gcc compiler to see if some issues goes out.

Oui, nous sommes français. Nous avons bien compris ce que vous avez dit.  ;)
Ne vous inquietez pas pour les petites fautes. Nous sommes certains que nous en faisons beaucoup quand nous parlons ou écrivons en anglais.  :)

The Blackvoxel Team

45
General Discussion / Re: OSX port
« on: July 28, 2015, 06:37:35 pm »
Hi cortices,

Welcome to Blackvoxel forum and thank you for your involvment for the Mac Os port  :)

As we don't have Mac, we are searching volunteer for porting Blackvoxel on mac.

We see you have managed to make it running.  :D

Do you compiled it natively or used some stuff to run some Linux version ?

The Blackvoxel Team

Pages: 1 2 [3] 4