Show Posts
46
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.
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.
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.
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).
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 ?
It seems some players prefer playing with the game than playing in the game
But... why not.
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.
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++.
As I understand it's something equivalent to SDL. But I can't give any though on that.
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
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
. But why not if you like it... so I'm just curious to know why you choose this language.