libtcod 1.1 released

On 30 jan, 23:25, Nick Beam <winkerb....DeleteThis@gmail.com> wrote:
> Very good work. I've only tinkered with it, can't wait to give it a
> real go.

I'm glad you like it. I'd be very happy to see someone else's game
using it..

--
jice
 >> Stay informed about: libtcod 1.1 released 

Finally, no linker errors under VS2008! Thanks, jice. Still, the
compiler gives me odd errors while trying to build the Perlin noise
generator, but if the rest works fine, I'll live without it .

By the way, the demo looks great, I found especially interesting the
torch fx.

Mingos.
 >> Stay informed about: libtcod 1.1 released 

On 4 fév, 12:52, dominikmarc... RemoveThis @gmail.com wrote:
> Finally, no linker errors under VS2008! Thanks, jice. Still, the
> compiler gives me odd errors while trying to build the Perlin noise
> generator, but if the rest works fine, I'll live without it .
>
> By the way, the demo looks great, I found especially interesting the
> torch fx.
>
> Mingos.

Ok, I didn't try to compile the library on VS2008, I only checked that
the binary release worked. I will check that it compiles on VS2008 for
the next release. Note that the torch fx is precisely using the perlin
noise generator.

--
jice
 >> Stay informed about: libtcod 1.1 released 

> Ok, I didn't try to compile the library on VS2008, I only checked that
> the binary release worked. I will check that it compiles on VS2008 for
> the next release. Note that the torch fx is precisely using the perlin
> noise generator.

Yes, that's a pity, but at least it works. Umbrarum Regnum is slowly
taking shape. I'm forced to use the C version, since C++ keeps giving
errors, but I kind of prefer C over C++ when there's no apparent need
to use objects, so that's fine by me.

The graphical representation of my maps looks fine and is stunningly
fast in comparison to the Java version of the same algorithms (random
cavern/labyrinth/perfect labyrinth/dungeon generation) and Java AWT
GUI, which means I'll stick to C rather than tinker with Java after
all.

Thanks a million for the library, jice, it really saved me a lot of
pain.

Oh, one more thing. Remember when I asked whether LibTCOD supported
UNICODE? I'm interested in just a few non-English characters and it so
happens that they're all there in the terminal.bmp file .

Now if I can only get my hands on a FOV algorithm that will suit my
needs (no LOS radius, but rather an algorithm that considers distance,
Perception score and amount of light on a given tile)... But that's a
different story.

Thanks again.
Mingos.
 >> Stay informed about: libtcod 1.1 released 

On 7 fév, 22:30, dominikmarc... DeleteThis @gmail.com wrote:

> The graphical representation of my maps looks fine and is stunningly
> fast in comparison to the Java version of the same algorithms (random
> cavern/labyrinth/perfect labyrinth/dungeon generation) and Java AWT
> GUI, which means I'll stick to C rather than tinker with Java after
> all.

Yet, the library rendering engine is far from being optimized. I've
never really cared about optimization because I get good performances
on a Celeron 466Mhz in The Chronicles Of Doryen even with the huge
amount of effects I'm using. With nowaday computers, you almost never
have to care about optimization in C/C++ (provided you don't do
patently stupid things).

> Thanks a million for the library, jice, it really saved me a lot of
> pain.

You're welcome .

> Now if I can only get my hands on a FOV algorithm that will suit my
> needs (no LOS radius, but rather an algorithm that considers distance,
> Perception score and amount of light on a given tile)... But that's a
> different story.

Yes, the FOV module in the library only provides PVS (potential
visible set). You still have to reduce this set by removing cells that
don't get enough light. I didn't put the TCOD lighting engine in the
library because I try as much as possible to put only low level
utilities in the library to keep the games using it from looking all
the same.

--
jice
 >> Stay informed about: libtcod 1.1 released 

Hi again jice.

The line-printing functions (TCOD_console_print_left_rect(...), for
instance) seem to be able to print only up to 255 characters. Is this
a bug? I tried to display race descriptions on the PC generation
screen and the ones that were longer than that caused the program to
hang (enter an infinite loop, maybe?).

Mingos.
 >> Stay informed about: libtcod 1.1 released 

On 21 fév, 11:05, dominikmarc....RemoveThis@gmail.com wrote:
> Hi again jice.
>
> The line-printing functions (TCOD_console_print_left_rect(...), for
> instance) seem to be able to print only up to 255 characters. Is this
> a bug? I tried to display race descriptions on the PC generation
> screen and the ones that were longer than that caused the program to
> hang (enter an infinite loop, maybe?).
>
> Mingos.

Hi,

err.. yes, it's currently limited to 256 and if you print more, you'll
crash the whole thing because there is no out-of-bound check...
I'll see if I can handle strings of any size...

Jice
 >> Stay informed about: libtcod 1.1 released 

On 21 fév, 11:09, jice <jcwilk2....TakeThisOut@gmail.com> wrote:
> On 21 fév, 11:05, dominikmarc....TakeThisOut@gmail.com wrote:
>
> > Hi again jice.
>
> > The line-printing functions (TCOD_console_print_left_rect(...), for
> > instance) seem to be able to print only up to 255 characters. Is this
> > a bug? I tried to display race descriptions on the PC generation
> > screen and the ones that were longer than that caused the program to
> > hang (enter an infinite loop, maybe?).
>
> > Mingos.
>
> Hi,
>
> err.. yes, it's currently limited to 256 and if you print more, you'll
> crash the whole thing because there is no out-of-bound check...
> I'll see if I can handle strings of any size...
>
> Jice

Ok, I've just discovered the vsnprintf function ^^.
The 1.2 release will handle strings of any size. It should be out next
week, with some fixes and some new shiny features...

--
jice
 >> Stay informed about: libtcod 1.1 released 

On Feb 21, 11:09 am, jice <jcwilk2... RemoveThis @gmail.com> wrote:
> err.. yes, it's currently limited to 256 and if you print more, you'll
> crash the whole thing because there is no out-of-bound check...
> I'll see if I can handle strings of any size...

I can imagine you have a line of the sorts of "char buffer[256];"
somewhere in your code?
If you are using c99 you can take advantage of variable-length arrays:

char buffer[snprintf(NULL, 0, your_string)];

Or just dynamically allocate if you use c89.

-Ido.
 >> Stay informed about: libtcod 1.1 released 

On Feb 21, 11:38 am, jice <jice.nos....DeleteThis@gmail.com> wrote:
> Ok, I've just discovered the vsnprintf function ^^.

Didn't notice you've already found it out by yourself by the time I
wrote my reply...
 >> Stay informed about: libtcod 1.1 released 

On 21 fév, 11:46, Ido Yehieli <Ido.Yehi... RemoveThis @gmail.com> wrote:
>
> I can imagine you have a line of the sorts of "char buffer[256];"
> somewhere in your code?
> If you are using c99 you can take advantage of variable-length arrays:
>
> char buffer[snprintf(NULL, 0, your_string)];
>
> Or just dynamically allocate if you use c89.
>
> -Ido.

To avoid calling vsnprintf twice for each printed string, I'm now
using a resizable buffer :

static char *TCOD_console_vsprint(const char *fmt, va_list ap) {
static char *msg=NULL;
static int buflen=0;
bool ok=false;
if (!msg) {
buflen=512;
msg=(char *)calloc(sizeof(char),buflen);
}
do {
ok = (vsnprintf(msg,buflen,fmt,ap) != -1);
if (!ok) {
buflen*=2;
free( msg );
msg=(char *)calloc(sizeof(char),buflen);
}
} while (! ok);
return msg;
}

--
jice
 >> Stay informed about: libtcod 1.1 released 

On Feb 21, 11:56 am, jice <jice.nos....DeleteThis@gmail.com> wrote:
> To avoid calling vsnprintf twice for each printed string, I'm now
> using a resizable buffer :

Whatever works for you
I would have optimized for shorter/simpler code though, seeing as
calling [v]snprintf twice is most likely not a performance bottleneck.

-Ido.
 >> Stay informed about: libtcod 1.1 released 

On 21 fév, 12:08, Ido Yehieli <Ido.Yehi... DeleteThis @gmail.com> wrote:
> I would have optimized for shorter/simpler code though, seeing as
> calling [v]snprintf twice is most likely not a performance bottleneck.
>

Not in a turn-by-turn roguelike, but for a real-time game with 25
fps... You would be surprised how slow the *printf functions are. I
already add to rewrite simplified version of them in two high-
performance projects where intense profiling showed at some point that
they actually were the bottleneck. After memory allocation, they are
the functions I'm the most afraid of (with the C++ STL which I don't
use anymore)...

--
jice
 >> Stay informed about: libtcod 1.1 released