While not planned for the libtcod 1.4 release, there is already a working prototype of the sub-cell resolution module in TCOD. This might be a rather controversial module. With true colors and customizable bitmaps fonts, we might already wonder if libtcod still produce text-mode games. With this module, the question is even more justified. Of course from the technical point of view, we still only print fixed size characters from a set of 256. But from the gamer point of view, distinguishing between games using libtcod and full graphics games is more and more difficult. Of course using the sub-cell toolkit to do an actual graphical game would be stupid. It’s only there to improve the game look to make it more appealing. Look at those early screenshots from TCOD (title screen and death screen).

Now look at the new version, using the sub-cell resolution. It looks like real graphics uh ? And yet it only uses 7 special characters (see this post). Zoom on the picture and you’ll see that every console cell always contain only 2 colors (foreground/background). While being highly unoptimized, the sub-cell toolkit is already fast enough for fullscreen animation with the 80×50 TCOD console as you can see on the youtube video below. The question is… Is sub-cell resolution evil ? Maybe I’m pushing too far the visual limits and in the process, TCOD may definitely lose its mind as a text-mode game… Should I really add this in libtcod 1.5 ? I’m waiting for your comments / votes on this subject.

3 comments so far

Add Your Comment
  1. Continuing our previous discussion, I’m not “actively developing” the way I wanted, there is so much that I need to get out of my way — but it’s better than nothing 🙂 I’ve got great plans, I just need some time…

    Okay, sub-cell accuracy: I agree it starts to look more like a pixelated game, less like a RL. But I think it’s ok. It all falls within the same system.

    This sub-cell thing will probably be used only for the most graphical aspects of RLs, like menus, creature images (became a fan since I first saw it in DoomRL), and some nifty graphical effects. The rest is still ASCII at heart.

    It’s arguable whether you should allow more and more graphics routines to draw minimaps, etc. This would inadvertently turn it into a software rendered. My suggestion? Allow other buffers to be turned into windows, with a bitmap font, with a function call similar to the usual initialization routine. Might be a bit too much work, but it would allow a smaller font to display a minimap in a clean way. Maybe even other screens, inventory, etc. Or a compromise that would go easier on your already overloaded schedule: changing the font bitmap in real-time.

    I dunno, just brainstorming here 🙂
    Possible next steps in this direction that don’t involve software 3D rendering 😉

    Anyways it’s a great feature, it looks awesome in those screenshots!

  2. Great plans, need some time… I know this story already, reminds me TCOD 🙂

    Supporting different fonts is planned for 1.4, but not fonts with different sizes. Could be useful in your multi-window minimap example, but I think it’s more a multi-window feature than a multi-font feature. I’m not planning to support multi-window for the time being, because I’ve always found multi-windows were a pain in every user interface (game or not). That’s why I hate gimp…

  3. True, I guess. Well it’s not like it’s a problem. I’d much rather see other stuff in libtcod — altough I must say, almost everything I was wishing for is already in 1.4 so I’m pretty pleased right now 🙂