libtcod 1.5 design thread

[jice]

Updated October, 19 :
It appears the 1.5 scope is too big for me to handle. The svn trunk is in a really messy state and I don't think I'll be able to clean it.
I will backport working part of libtcod 1.5 to he 1.4 branche, including :

• subcell resolution blitting (1.4.3)
• colored tile support (1.4.3)
• automake compilation system (1.4.3?)
• debug/release versions of the library (1.4.4?)
• layer system (1.4.4?)
• parser pull-parsing API (1.4.4?)

The big structural changes (store console colors in TCODImages, opengl support and alpha channel) might not appear before a while...


This is a brainstorming thread where I put ideas about where libtcod 1.5 should go. I'll see if some of the proposal prompt an outcry from users.
Keep in mind that 1.5 is totally open. Everything can be broken/changed. Feel free to add suggestions, but keep in mind two guidelines :

• libtcod is a toolkit, not a framework. It must not provide all-in-one solutions, but flexible tools adaptable to any needs
• libtcod must not become a carryall. Things that can be easily done by the user or that are not in the scope of a roguelike library must stay out of it.

- to remove
% to change
+ to add

• General

+ dev/prod versions of the library. dev uses assert to stop as soon as a parameter has a bad value. prod is bullet proof and never crashes. DONE
% all function having file name parameters should be variadic loadFromFile("savefile.sav") => loadFromFile ("savefile_%d.sav", myint);

• Console module

- TCOD_bkgnd_flag_t (console background operations, to be replaced by TCODColor features) DONE
Trivial functions rarely used :
- TCOD_console_hline DONE
- TCOD_console_vline DONE
- TCOD_console_print_frame DONE
Encourages bad architectures / not supported on every platform :
- TCOD_console_set_keyboard_repeat DONE
- TCOD_console_disable_keyboard_repeat DONE
+ support for colored tiles in bitmap fonts DONE
% TCOD_console_put_char(int ch, const TCODColor &back, const TCODColor &fore) DONE
% Console background & foreground stored in TCODImage => TCODConsole::set/getForegroundImage DONE
% isKeyPressed(TCOD_keycode_t key, int asciiCode) to get status of TCODK_CHAR keys
% TCODConsole::blit(... , float foreGroundAlpha, float backgroundAlpha) to ease TWOF-like windows with transparent background / opaque text DONE

• Fov/Path module

+ add TCODPath::clear

• Image module

% replace screenshot-like functions (refreshConsole, ..) by createScreenshot / refreshScreenshot
% blit should blit on another TCODImage, not on a console (except for subcell blitting function blit2x) DONE

• Parser module

+ support for TCOD_key_t type to ease key configuration
% replace SAX API by a StAX-like pull parsing API DONE

[das]

I think I remember reading something about layers while you were discussing tilesets - I'd like to see something like that go in, but have it so we aren't forced to use the same traditional roguelike 'cell' structure. Sort of like overlays where we can just use straight pixels instead of cells. I know libtcod's a roguelike library, and I'm happy for it to be that, but we shouldn't be forced into a graphical layout that is sometimes more restrictive than creative simply because it's nostalgic. Even if it was some sort of option to just access straight SDL, grab a normal image with transparency, and blit that over the console screen, that'd be fine (for things like interfaces, GUIs, menus). Although what I'm leaning towards is using it for a particle system for more eye candy and gameplay possibilities (smoke, fire, more impressive magical effects)  Forgive me if this is already possible, it's just something that I haven't seen.

I love libtcod for the fact that it's saying to me "We can have roguelikes, but we can transcend the limitations that forced them to be like this in the first place" by adding things like truecolour natively. Giving us the option to transcend the limit of the cell would be part of that.

[jice]

I've just had this very discussion with Mingos and previously with Jotaf and I have to disagree. Because you can easily transcend all the graphical limitations : use a Final fantasy-like flat tile engine, use a Diablo-like isometric tile engine or use a World of warcraft-like 3D engine. This is not the goal of TCOD, because I think text-mode has some real advantages over those three display modes.

From the developer point of view, the advantage is obvious. No time to spend on artwork that will anyway look terrible except if you hire a professional artist or if you have both coder and artist skills.

But even more important, there's a huge advantage from the player point of view. If you played nethack in text-mode, flat tile mode and vulture eyes mode, you'll probably see that the text-mode version has by far the better gameplay.

That's why I'm currently against breaking the console/cell paradigm either by allowing overlapping characters or blitting at pixel coordinates.

Now the issue with text-mode as it has been used by most roguelike is that it's ugly.

The one and only goal of libtcod is to help to produce games with that kind of clarity, that kind of depth (which is only possible if you don't have to create artwork for every item/monster), but without the ugly part. I'm convinced that any player can enjoy a text-mode game if it is as beautiful as Umbrarum Regnum or The Way of Fallen. In fact I even believe such games would escape the niche and go mainstream.

[Jotaf]

I'm only going to mention the ones I deem more relevant.

- TCOD_line (bresenham atomic callback function. trivial)

Oops. See note about TCODMap/callbacks, below.

Trivial functions rarely used :
- TCOD_console_put_char ?

Actually, it would be much better if a single function could modify everything: background/foreground colors and character. The way it is, most people are calling setFore/setBack/setChar (or putChar), sequentially -- which is a bit redundant.

+ add color alpha channel ?

Sorry, can you elaborate a bit?

+ support for colored tiles in bitmap fonts

Please do!

% Console background & foreground stored in TCODImage => TCODConsole::set/getForegroundImage

So it stores 2 images? Wouldn't it be easier to have a blit function that prints either to foreground or background? (Unless this already exists; this is one part of the library that I haven't used yet.)

% TCODConsole::blit(... , float foreGroundAlpha, float backgroundAlpha) to ease TWOF-like windows with transparent background / opaque text

Sweet

% replace TCODMap based functions by callback based functions (TCODMap encourages bad architecture)

Understandable, but just try calling back Python 500 times per frame and let me know if there's a performance hit compared to the current system...

I don't mind the maps, they're just data structures that sit there peacefully. The tiles' "blocked" state rarely needs to be updated.

- keep only simplex noise

And FBM Simplex, right?

Just asking: are the other noises that useless?

[Scautura]

• Bresenham module

- TCOD_line (bresenham atomic callback function. trivial)

I would argue (at least, from the point of view of a Python dev) a Bresenham line from TCOD would be quicker than a Python one - either that, or I've missed the point entirely and you're not removing the whole Bresenham line thing...

• Console module

- TCOD_console_print_frame

Am I the only person who uses this? Since I had a similar implementation before I even used TCOD, this won't be a problem for me.

• Fov/Path module

- keep only one fov algorithm

No matter which one you keep, there will be whinging people - a bit of a hiding to nothing, as there appears to be no "best" algorithm.

% replace TCODMap based functions by callback based functions (TCODMap encourages bad architecture)

Yay! Same lines as Jotaf, this might be awkward from Python, but I asked for this from a Python point of view. It will surely be quicker to use a Python callback than to iterate through the entire processed "Map" just to create a grenade effect (spherical damage using a FOV area).

I'm looking forward to seeing where TCOD goes with this - however, I'm probably going to have to stick with 1.4.1 otherwise I'm going to get nowhere (fast!) with my roguelike!

[sandman]

heya

- keep only one fov algorithm
- keep only simplex noise

please don't remove those niceties, having different fov algorithms and noise at hand
is a real boost for tcod. in my opinion those and the pathfinder make tcod a useful
library for roguelikes.

the sdl console thing is nice, granted, but actually simple to implement for anyone who has
written a bit of that kind of stuff.

-sandman

[ehertlein]

% isKeyPressed(TCOD_keycode_t key, int asciiCode) to get status of TCODK_CHAR keys

Would this be like the SDL_GetKeyState function? I really like the way that one works.

[jice]

Actually, it would be much better if a single function could modify everything: background/foreground colors and character. The way it is, most people are calling setFore/setBack/setChar (or putChar), sequentially -- which is a bit redundant.

Ok it's not the first time someone ask for it. Let's replace putChar by this almighty function

+ add color alpha channel ?
Sorry, can you elaborate a bit?

Add a "a" (for alpha) field in TCODColor (with all implications for functions using colors).

% Console background & foreground stored in TCODImage => TCODConsole::set/getForegroundImage
So it stores 2 images? Wouldn't it be easier to have a blit function that prints either to foreground or background? (Unless this already exists; this is one part of the library that I haven't used yet.)

Having actual TCODImage in the console makes it possible to use every image utilities (like loading from a file) on the console. Instead of having image->console utilities and image->image utilities, I can keep only the latter. I find this cleaner. The only image->console functions will be the sub-cell blit2x because they update every property of the console.

% replace TCODMap based functions by callback based functions (TCODMap encourages bad architecture)
Understandable, but just try calling back Python 500 times per frame and let me know if there's a performance hit compared to the current system...
I don't mind the maps, they're just data structures that sit there peacefully. The tiles' "blocked" state rarely needs to be updated.

Err yeah. I have to admit I never thought about python while writing this list down... Have to think a bit more about the impact of bresenham/fov/path stuff on python...

And FBM Simplex, right?

Yes, simple/fbm/turbulence simplex noise. Junk Perlin & wavelet.

Just asking: are the other noises that useless?

Well they're much slower and the difference is barely visible. Since I implemented simplex, I've never used any other noise (neither Umbrarum Regnum, which makes heavy usage of noise, so I'm pretty confident about junking the other ones)

- keep only one fov algorithm
- keep only simplex noise
please don't remove those niceties, having different fov algorithms and noise at hand
is a real boost for tcod. in my opinion those and the pathfinder make tcod a useful
library for roguelikes.

Concerning noise, see above. I don't think the slight difference justify to increase the library bloat...
Concerning fov, I admit it's a bit brutal. But what if the only remaining fov algorithm is proved to be the best ? I really think it would be better for everybody not to have to choose one. Moreover is the difference between 2 algo that important for the gameplay ? I have the feeling that it's rather a semi-religious thing.

% isKeyPressed(TCOD_keycode_t key, int asciiCode) to get status of TCODK_CHAR keys
Would this be like the SDL_GetKeyState function? I really like the way that one works.

No, the current isKeyPressed is like the SDL_GetKeyState. It can only check special keys. This version would allow to check any key on the keyboard including standard char keys.

[Jotaf]

Add a "a" (for alpha) field in TCODColor (with all implications for functions using colors).

Nice. But you have to think this through. The lerp system is intuitive, this one has great potential both for power and for confusion...

Concerning fov, I admit it's a bit brutal. But what if the only remaining fov algorithm is proved to be the best ? I really think it would be better for everybody not to have to choose one. Moreover is the difference between 2 algo that important for the gameplay ? I have the feeling that it's rather a semi-religious thing.

Actually, I just switch from simple FOV to diamond FOV because I don't want the player to see through a diagonal wall...

 

[jice]

ok let's keep the fovs then. But for the noise, I really think it's not necessary.

[ehertlein]

% isKeyPressed(TCOD_keycode_t key, int asciiCode) to get status of TCODK_CHAR keys
Would this be like the SDL_GetKeyState function? I really like the way that one works.

No, the current isKeyPressed is like the SDL_GetKeyState. It can only check special keys. This version would allow to check any key on the keyboard including standard char keys.
[/quote]

What makes you say that? SDL_GetKeyState() lets me know everything about the keyboard...

http://sdl.beuc.net/sdl.wiki/SDL_GetKeyState

[jice]

% isKeyPressed(TCOD_keycode_t key, int asciiCode) to get status of TCODK_CHAR keys
Would this be like the SDL_GetKeyState function? I really like the way that one works.
No, the current isKeyPressed is like the SDL_GetKeyState. It can only check special keys. This version would allow to check any key on the keyboard including standard char keys.
What makes you say that? SDL_GetKeyState() lets me know everything about the keyboard...
http://sdl.beuc.net/sdl.wiki/SDL_GetKeyState

Oh ok, indeed

[Jotaf]

ok let's keep the fovs then. But for the noise, I really think it's not necessary.

I must agree about the noise. Maybe keep the old noise types in a different folder just in case someone wants them; but no longer remaining part of the main project. About the FOVs, leave a note in the docs saying "if you're in doubt, use the default FOV". They shouldn't add a lot of confusion since they're all used in pretty much the same way.

BTW, what are the plans for the custom chars? This has been discussed in another thread, but can you give us a peek of how that system is going to work?

[mingos]

Concerning the noise:
Indeed, I (as the developer of UR, which you explicitly mentioned) make heavy use of noise. I use simplex for one basic reason: its speed (you know all too well how very much CPU-hungry is the two-layered smoke in the title screen). BUT...

Note that each noise has different usages and potentially might be useful.

1. SIMPLEX
- it's fast, good for real time.
- high contrast.
- it has a bug with negative offsets (you can only scroll it in one direction).
- it has a tendency to create large areas with extreme values (-1 and 1) - the uniform extreme values aren't too pleasing to look at.
- uniform when zoomed out
- at 1 octave and especially when zoomed in, the simplices are visible (a bit ugly).

2. PERLIN
- average speed, not well suited for real time
- low contrast
- barely ever reaches extreme values, so there are no uniform areas with the same value of -1 or 1, making it suitable for terrain generation
- uniform when zoomed out
- when zoomed in, no visual artifacts can be seen

3. WAVELET
- crawling slow, never to be used in real time
- average to high contrast, visually way better than both Perlin and Simplex
- only small areas with the same extreme value
- bug with extreme values (you implemented clipping to avoid that, luckily)
- never gets uniform, even when zoomed out
- no visual artifacts when zoomed in

Do as you will, I certainly won't cry if Perlin and wavelet disappear since I don't use them. Just wanted to make things clear.

[Jotaf]

- it has a tendency to create large areas with extreme values (-1 and 1) - the uniform extreme values aren't too pleasing to look at.

I noticed this, it's ok for clouds, but not for other textures. FBM kinda solves this, right?