2009
04.25

libtcod 1.5 sneak peek

Mmmh… The library version apart, do you see any difference ?? 😉


9 comments so far

Add Your Comment
  1. OMFG!!! I can’t believe it!!! What did you do???

  2. Now I’m even more excited for 1.5. Is the performance through Python significantly effected in any way?

  3. I know! The letters are different! And the colors.

    😛

    Wow that’s a huge FPS increase. What did you do?!

  4. Don't expect miracles for python. I get only a 19 fps => 22 fps. Most of the time is spent in the python part.

    For C/C++ it's that fast because it uses a dedicated renderer for opengl enabled computers (probably 99% of nowadays computers). It's only the first work-in-progress version of the renderer so we can probably expect more optimizations on it.

    I don't plan it for 1.5 but doing mersenne twister / perlin noise ( / fov ?) on the GPU is probably perfectly doable too… That would beat 1.4 perfs to a pulp…

  5. Well, I tested UR with libtcod 1.5 and have two remarks (apart from the screenshots bug which you already know about):
    1. The performance boost is nil (literally) in a game (UR spends most of its time lerping colours, while the actual display is only a fraction of the computational needs). You’ll have to move more than just the display to the GPU.
    2. The fonts seem to work incorrectly. They’re not mangled, but there are weird horizontal lines all over the main menu (not ingame though; characters 0-255 seem to work fine).

  6. yeah, even if I divide the flush time by two, if it’s only 5% of your frame time, you won’t see a difference. Fov and noise would be the first area to improve to get significant speed improvement in our type of games.

    I know there are currently some pixel or subpixel issues. If you compare the two pictures, you see that the background in the 1.5 version is 1 pixel higher than the 1.4. Can you send me a screenshot of your issue ?

  7. Sure, I’ll send you a bunch of them with some descriptions.

    Regarding the frame time: in UR, it’s colour lerping, mainly. That’s the most processor-intensive part since there are MANY lerps per frame. I’ve just had an idea on how to improve it. If it works, I’ll up it to SVN.

  8. Dammit to hell! No improvement, guess the compiler does a pretty good job optimising the code. I tried using a macro for lerping colours, but it only accepts the format “colour1, colour2, coefficient”, but not, for instance, “colour1, colour2a*colour2b, coefficient”, making it quite useless. My best was a ~0,5% framerate improvement (in various tests, but it was probably a random speed variation anyways). It’ll have to go to the GPU, I guess.

  9. Would liboil help?

    http://liboil.freedesktop.org/wiki/