2008
01.25

Noise, Fov…

The two new modules have been incredibly easy to port from the game to the library. Even the samples almost worked right after the first compilation ! If only coding could be always as easy…

The noise module provides easy access to 1d, 2d, 3d and 4d Perlin noise functions and two derived functions : fractional brownian motion (fbm) and turbulence. Exemple of 2d functions :

Perlin noise
Fractional Brownian Motion
Turbulence

The sample allows to easily modify the different parameters and see their impact on the noise function.


The Perlin noise is often associated with procedural texture generation and one can wonder what’s its use in a roguelike. I personnally use intensively the 1d Perlin noise function as a ‘smooth’ random number generator. Look at the Perlin noise 2d squared picture and imagine you follow a straight path in this picture. The value of the pixel you’re walking on randomly moves between 0 (black) and 1 (white), but always in a smooth way.

The Field Of View toolkit is really basic and doesn’t restrain you from using any map format you want. It is based on the algorithm described on the TCOD website. The FOV sample is a mini dungeon in which you can wander to see how the fov behaves. There’s also an ‘eye-candy’ mode with a realist torch flickering effect obtained with 1d perlin noise. Since tonight, TCOD actually uses the fov toolkit from the library.

Now, I have to find the time to compile this on every platforms (eventually including VS2008 / Borland C++ 5.5 targets as requested recently on r.g.r.d). If no major issue occurs, libtcod-1.1 should be out this week-end \o/

5 comments so far

Add Your Comment
  1. Thank you Jice for describing your Fov algorithm. I am trying it in my roguelike, and it’s pretty functional.

    Nevertheless I have a case where I still get artifacts : when the player is close to a wall, and there is a hole in it. The wall will be lighten by the post-processing artifact killer, but not the hole in it.

    In my case, those holes are windows in walls, so there is no real reason for them to be hidden when the wall next to them is shown.

    Did you think about that case already ?

  2. Hell, you’re right! I also have windows in TCOD but I’ve never noticed this issue.

    The current post-processing uses the following algorithm :
    if a blocking cell is behind a visible cell, it is visible.

    Since windows are not blocking cells, they are not fixed. The obvious fix would be :
    if a cell is behind a visible cell, it is visible.

    But depending on how it is applied, it may mark the whole screen as visible. I’ll try to fix this asap. I’m at home today so it may be out this afternoon ;).

  3. Ok, this is more tricky than I expected. The problem is that the status of the cell cannot be deduced from the ‘transparent’ information alone. The same map topology can represent different world topologies :

    ###=### This is a wall with a window. The window should be in fov.

    ### ### This is a wall with a hole. The hole should not be in fov, because in such a case :
    #####################r###
    @
    #########################
    the rat ‘r’ should not be visible. It hides in the hole in the wall.

    To handle both cases, I need another cell information : if it is walkable.

    Thus, the post processing rule becomes :
    if a not-walkable cell is behind a visible walkable cell, it is visible.

    I’ll put this fix in a 1.1.1 release, but I will wait a bit in case someone find another issue. Until then, you can download a beta version here.
    I updated the samples to show the fov behaviour with windows. There is an API change :
    TCODFov.setTransparent(int x, int y, bool isTransparent)
    replaced by
    TCODFov.setProperties(int x,int y,bool isTransparent, bool isWalkable)

  4. Good trick, that solved it on my side too :-).

    Another one : when the player is in a corridor, corners are not shown :

    ########################.
    @ #
    ########################.

    That’s not a big deal for an ascii display, but it can appear as a bug with graphic tiles, since a wall corner is effectively drawn.

    To correct that I have added a third cell to test in the artifact killer process, the cell diagonally opposed.

  5. Yeah, processing the diagonal cell was also suggested by Krice on r.g.r.d. It fixes room corners, but I’m afraid it may also produce other artifacts. It’s probably impossible to get a perfect fov with this technics (if ‘a perfect fov’ really means something in a discrete, cell-by-cell pixelized world).

    Anyway, I’m interrested to ear about other improvements you could find. Fov artifact are much more annoying in a graphic game like yours than in an ascii one where you barely notice them, so you may progress faster than me on this ;).