Unicodetiles.js: JavaScript character tile engine

[Tapio]

Unicodetiles.js



I'm going to make my 7DRL a browser game and I thought it could be nice to share my JavaScript library I'm using for displaying the character tiles. I'm deliberately avoiding the word ASCII, because the engine has a monospace Unicode font bundled, so every user will also see more exotic characters consistently.

The engine is based on pure text and DOM, so there is no <canvas> (nowadays there is a canvas renderer, which is also the default one), WebGL, Flash, Unity or anything like that involved. I aim for compatibility so it should work on latest versions of any major browser. A bit older ones are also fine, but IE8 and below appear to have too slow JavaScript/DOM for this to be usable.

You can read more about the features from the webpage: http://tapio.github.com/unicodetiles.js.
I've also tried to document it and there are several examples available. Some of the examples build upon others so they could almost be regarded as tutorials. Note that even though the demos produce roguelike lookalikes, the library itself is for displaying stuff and does not contain e.g. dungeon generators or FOV algorithms.

I was actually toying around with the idea of changing the API look like libtcod, but I think I'll leave it as it is at least for the 7DRL. Anyway, if anyone should like to use this as a basis of libtcod JS port, feel free: it's MIT licensed.

[konijn_]

I very much like it.


Curious questions
1) Why do you "use strict" within each function instead of once at the top of the .js file ?
2) Why do you use    window.setInterval("tick()", 150); in the simpledungeon.js , the engine shows off much better with a tick value of 50
3) Your demo really should use the old fashioned block character to show the unicode part of your engine ( ▒ )
4) The engine is too slow at 120 by 50, but I think with some tinkering, it should run great at mapsize as well.

I looked at the code, oh my, you love commenting, which is great

T.

[george]

Great, I'm planning my 7DRL for the browser too. This is perfect, thanks aave.

[Tapio]

I very much like it.


Curious questions
1) Why do you "use strict" within each function instead of once at the top of the .js file ?
2) Why do you use    window.setInterval("tick()", 150); in the simpledungeon.js , the engine shows off much better with a tick value of 50
3) Your demo really should use the old fashioned block character to show the unicode part of your engine ( ▒ )
4) The engine is too slow at 120 by 50, but I think with some tinkering, it should run great at mapsize as well.

I looked at the code, oh my, you love commenting, which is great

T.

Thanks for your comments.
1) I read somewhere that global "use strict"; might break third-party libraries and JSHint code analysis tool doesn't allow it by default.
2) I'm actually currently revamping the input stuff based on comments I got in IRC. 150 is basically a good (IMO) movement delay for continuous movement, but it's used for other things, which make it a bit broken. However, that's more of an issue with the examples than the engine itself I think, as everybody is free to implement the moving however she wants.
3) Good idea, I'll test how that looks
4) I've actually tried to do quite a bit of optimizing, but didn't yet try with that big viewport. Enabling the tile caching feature might speed up things a bit, but it's already enabled in the forest example. The thing is that the DOM just is rather slow. If it really starts to become a problem (my 7DRL will probably be rather computationally intensive), I'll implement a canvas renderer.

[Tapio]

2) I'm actually currently revamping the input stuff based on comments I got in IRC. 150 is basically a good (IMO) movement delay for continuous movement, but it's used for other things, which make it a bit broken. However, that's more of an issue with the examples than the engine itself I think, as everybody is free to implement the moving however she wants.
3) Good idea, I'll test how that looks

This is now done. The input module can now do custom key repeating, i.e. there is no initial delay and the interval of the events is customizable. For the examples this means that there is no missed key presses, the movement is instant, and holding a key down does not cause a long initial delay.

It works nicely in Chrome and Firefox. Opera has some weird bug that it looses the delay after a sec and goes full speed. For IE9 the keys might get stuck down in Infinite Forest for a while, but that might be because I only tested IE9 on a low powered netbook, which kind of chokes on that example.

[Hi]

the examples work nicely in chrome and safari.
Firefox looks like the font is not monospaced. It is the school library computer so someone might have done something.

[Tapio]

Firefox looks like the font is not monospaced. It is the school library computer so someone might have done something.

Perhaps your school has a really ancient version of Firefox, because it works for me with FF10 and even on FF 3.6.27 I quickly tried. Web fonts are not supported below FF 3.5

[Hi]

I believe that it is probably a really ancient version of firefox.  They do not update too frequently.

[Tapio]

So I spent the afternoon testing HTML5 <canvas> element with unicodetiles.js. Surprisingly I got it to a rather nice state quickly and I already published a new version that has both the old-skool DOM renderer and the new canvas one. The default behavior is to try to use canvas and fallback to DOM. But this can also be changed and even switched on the fly (!) as can be seen in the revised examples.

The canvas renderer doesn't (yet at least) produce pixel perfect copy of the DOM one, but the performance rocks. In the stress tests (that can be found from the tests subdirectory) I get speed factors from 2x to 7x depending on browser and test. Firefox has the greatest benefit, as the DOM version is awfully slow on it.

[Tapio]

I've started to implement my 7DRL with Unicodetiles.js as planned. You can read a status report here: http://7drl.org/2012/03/14/infiniverse-js-7drl-status-report/

The development has spawned several bug fixes and additions back to this library. \o/

[george]

Do you have any interest in the advanced level for Closure compilation? I don't think it would require too many changes to the code?

[Tapio]

Do you have any interest in the advanced level for Closure compilation? I don't think it would require too many changes to the code?

I actually tried it with Infiniverse by exporting the starting function and then posting everything (game sources, unicodetiles and jquery) to closure compiler, but it didn't work. I'll probably revisit it in the future, but currently I have much better things to do now that the 7DRL Challenge is ongoing.

[yam655]

I have a few comments.

1. It would rock if this library could work with smartphones. I have an Android with a hardware keyboard and I couldn't get the arrow keys to do anything but scroll the page. It displays fine and the transition effects work fine, so I think it is just an issue of getting the keyboard input in to the right view.

2. You might want to mention GNU FreeFont as another alternative. <http://www.gnu.org/software/freefont/coverage.html> The FreeMono font in particular needs some catchup. The FreeSans font has 5289 codepoints, but the FreeMono font only has 2120. However, they do have a goal to be rather complete, so this will likely change in the future. (Personally, I think at some point the roguelike community should start a project to extend a font in useful roguelike directions.) I don't know how much active development is going on with the DejaVu font.

3. For the people unfamiliar with some of the fantastic unicode codepoints, you might want to reference <http://unicode.org/charts/>.

Additionally, while Linux has functioning character map tools, (and I don't know about Mac OS X) the Windows default "Character Map" program is broken and can only show one sixteenth of the possible valid Unicode codepoints. Specifically, it is limited to the "Basic Multilingual Plane" which are codepoints between 0x0000 and 0xFFFF.

BableMap <http://www.babelstone.co.uk/software/babelmap.html> is free and has no such limitation. It will also allow you to jump to a codepoint by name or jump directly to a named Unicode block. This is handy when you have been browsing, say, the Unicode charts and you want to check to see whether a font has any glyphs in the "Miscellaneous Symbols" block (2600..26FF). Of course, with the ability to jump to a named codepoint, it is also easy to just do a search of, say "CHURCH" or "PENTAGRAM" or "BUS STOP".

4. If I've not stated it already. I think your library looks really quite interesting. If it could work with my Android phone, I might think about using it. As it is, there appears to be a lot of potential there.

Cheers,
Steven Black

[yam655]

I also wanted to mention GNU Unifont <http://unifoundry.com/> the font coverage is huge (full support of the Basic Multilingual Plane as of Unicode 5.1).

Unfortunately, it is primarily a dual-width fixed-point font. (8x16 and 16x16) There is a TTF version of the font, though it does appear blocky at some point sizes. (However, in some cases that may be considered part of the style.)

It includes glyphs for COFFIN and FUNERAL URN, but it predates PENTRAGRAM and CHURCH.

If the font works for a Roguelike the available codepoints is really impressive.

[Tapio]

@yam655:
I have considered Android. I have an Android smartphone with HW keyboard myself, which made me add HJKL keys to the demos because the phone doesn't have usable arrow keys. I have also thought of creating some custom touch control widget, but nothing on the implementation side yet.

Regarding the fonts you mentioned, I encountered both FreeMono and Unifont when I searched for a suitable monospace font to bundle. I don't remember what turned me from FreeMono, perhaps the lower amount of glyphs. Unifont on the otherhand appeared very blocky and at least some glyphs were not monospace. I guess I could try updating the engine to support non-monospace fonts, but that's not high on the TODO.