I’ve been working on the cave, polishing the title screen. I’m still not fully satisfied with the forest picture though, but I did two nice improvements :

• 3d smoke fx ripped from pyromancer is now much faster. Instead of computing a full screen picture each frame (one 3D simplex noise call for each subcell, 30 times per second => 480 000 calls per second), I compute it only 4 times per second and linearly interpolate the pictures (=> 64 000 calls per second). At 30 fps, this leaves a lot of free CPU, which brings me to the second improvement…
• the lengthy world generation (around 7 seconds on my Athlon Phenom 9650) is now computed by a background thread during the title screen. If you spend a few seconds staring at it, you can almost switch to the school selection screen without any delay. And I have plans to make you stare at it not only the first time you run the game …

Jotaf’s posted two videos on youtube to show the use of libtcod’s fast color filling function for python. Along with numpy, he gets some pretty amazing fps even with fullscreen animation (and this is only using the SDL renderer). Note that libtcod’s python sample works in 1.5.0 only if you don’t have numpy installed. The numpy version is fixed in the latest svn version.

[edit]erratum : in fact the renderer is OpenGL, not SDL.[/edit]

In case you didn’t see them on r.g.r.d, here are the results of the roguelike language survey. To be taken with a grain of salt, but this makes me want to try a Lua wrapper even more…

Some time ago, I made a survey to try and see what languages were used by roguelike devs. You can still see the results here :

https://spreadsheets.google.com/ccc?key=0AlivQdkktdH3cHFDaGFFMUYzdnlEbk1ZZWwwUF9pY1E&hl=en

This survey was plagued by a 16% “other” category. Fortunately, google tools have evolved and we can now discover what’s hiding behind those 16% (and also if there’s an evolution in the main languages usage) with this new survey :

https://spreadsheets.google.com/viewform?formkey=dEdmcTFTTTJ6amVWV29NZjJIWGI0NkE6MA

Results will be available here :
https://spreadsheets.google.com/gform?key=tGfq1SM2zjeVWoMf2HXb46A&gridId=0#chart

Thanks for your participation.

[edit] Google’s summary page doesn’t seem to work. You can consult the results here :
https://spreadsheets.google.com/ccc?key=0AlivQdkktdH3dEdmcTFTTTJ6amVWV29NZjJIWGI0NkE&hl=en

Smocking FPS…

Antagonist’s GLSL renderer has been succesfully integrated in libtcod 1.5.1 svn trunk. While I consider it currently highly unoptimized (in both the libtcod “client” part and the critical fragment shader), it already skyrocketed the true color sample to the unknown and mysterious world of 4 digits frames per seconds…. It’s only available if you have an OpenGL 1.4 compatible video card (it requires the GL_ARB_shader_objects OpenGL extension). If something goes wrong with openGL, libtcod will hopefully fall back to the default SDL renderer. You can also completely disable the OpenGL renderer by compiling libtcod with -DNO_OPENGL make option, or by uncommenting this option in libtcod.h.

Wrapping frenzy !

Paul Sexton’s common lisp wrapper cl-tcod should be compatible with libtcod 1.5.0 since there are no API changes between 1.5.0rc1 and 1.5.0. Get it there.

Other news on the wrapping side of the force are an ongoing community brainstorming leaded by Jotaf about refactoring the python wrapper. There’s a poll here. Be sure to check it if you’re using the python wrapper for libtcod.  Altefcat also started to work on a epydoc standalone documentation for python that will hopefully be available in the 1.5.1 release.

Umbrarum dokumentum…

Last but not least, Mingos started the documentation reskinning sisyphal work. The new look will be more user friendly and more “library documentation”-esque .