Temple of The Roguelike Forums
Development => Programming => Topic started by: Tapio on February 22, 2012, 11:37:17 AM
-
Unicodetiles.js (http://tapio.github.com/unicodetiles.js/)
(http://tapio.github.com/unicodetiles.js/docs/pics/lighting.png) (http://tapio.github.com/unicodetiles.js/examples/)
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 (http://tapio.github.com/unicodetiles.js).
I've also tried to document it (http://tapio.github.com/unicodetiles.js/docs/html/) and there are several examples (http://tapio.github.com/unicodetiles.js/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.
-
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.
-
Great, I'm planning my 7DRL for the browser too. This is perfect, thanks aave.
-
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.
-
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.
-
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.
-
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
-
I believe that it is probably a really ancient version of firefox. They do not update too frequently.
-
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.
-
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/
-
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?
-
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.
-
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
-
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.
-
@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.
-
@aave:
That's odd about unifont. I would have thought it would have exclusively been either 8x16 or 16x16. The fact that any of them became anything else would have to be a bug in the TTF conversion process. The things start off as an old-school bitmap font -- this is why it is blocky. The dual size thing is should be relatively common for a lot of fixed-width fonts -- it dates back to the old dumb terminals where a Chinese character would be twice as wide as a Latin character. Decent terminal emulators deal with this properly. (Though sometimes they only allow double-wide characters in every other location.)
In my "Blacken" Java library, I explicitly check to see if the max width of a character in the font is twice as wide as an "M". If so, it is a dual-width font. I have code to support it... but I've not gotten around to actually testing it.
I think one thing that would really benefit the roguelike community as a whole would be a high-quality "Roguelike" font. The focus would be on glyphs useful for roguelike games. Sort of a companion and alternative to the shared tile projects... So far, I've gotten as far as getting FontForge installed and working... We'll see how much steam I actually have for the project. ;)
In particular, I want doors which look like doors on architectural drawings -- complete with a directionality. I want to increase the clarity of the display -- something possible with the clear meanings of standardized iconography, but muddied with colorfully drawn tiles. That said, I also want monsters incomprehensibly horrible -- something only possible with fully abstract representations. Any tile graphic fails. With a tile you always eventually know what you're up against. With an letter you may never know...
The difference between basing a "Roguelike" font on DejaVu versus "FreeMono" is a one of license. DejaVu is public domain. FreeMono is GPLv3. For a web game, it means you can keep the source to DejaVu secret, but for FreeMono you need to make it available (along with any changes).
I actually think we would need three Roguelike fonts: 1 single width, 1 double width, and one dual width. I think the dual-width can be automatically created from the other two source fonts with a script, so it would be a distributed font but not one that would require a separate source file.
-
Oh my god, this is exactly what I have been looking for for months and months! Thank you!
I want to develop an ASCII lookalike RogueLike with Multiplayer and this looks like the perfect engine for the job. You code is beautiful and well documented. The infinite forest demo is amazing and means I can have world sizes of infinite size and be fed from a database along with player positions.
Apart from posting to thank you I just wanted to please ask you to keep up with this project and I look forward to seeing it develop further. Its wonderful.
Chris.
-
Oh my god, this is exactly what I have been looking for for months and months! Thank you!
I want to develop an ASCII lookalike RogueLike with Multiplayer and this looks like the perfect engine for the job. You code is beautiful and well documented. The infinite forest demo is amazing and means I can have world sizes of infinite size and be fed from a database along with player positions.
Apart from posting to thank you I just wanted to please ask you to keep up with this project and I look forward to seeing it develop further. Its wonderful.
Chris.
Thanks for the positive comments. As a side note, I'd recommend node.js with socket.io for your multiplayer server and communication library respectively. You'll get real-time communication, dead-simple API and the ability to write the server in JavaScript too.
Regarding the future of Unicodetiles.js, I'm currently not coding any web roguelike actively, so the library is also in "maintenance mode", which in this case means I'll probably make tiny tweaks/fixes from time to time and handle pull requests should some emerge, but chances are nothing major will happen, until I pick up a project that uses UT. If you have bugs or feature requests, feel free to shoot though.
-
{deleted}
I sorted my problem.
-
@aave : the only thing that I would want for this engine is to have smoother large maps, tripling map size makes the engine too slow.
Other than that the engine is pretty much spot on.
T.
-
@aave : the only thing that I would want for this engine is to have smoother large maps, tripling map size makes the engine too slow.
Other than that the engine is pretty much spot on.
T.
Why not just use the infinate map example? You can then just populate the world dynamically as the player explores.
-
@aave : the only thing that I would want for this engine is to have smoother large maps, tripling map size makes the engine too slow.
Other than that the engine is pretty much spot on.
T.
Why not just use the infinate map example? You can then just populate the world dynamically as the player explores.
Sorry, what I meant was tripling the viewport/screensize, not the map.
T.
-
@aave do you have a quick solution to getting contents of a tile from a mouse click?
-
tripling map size makes the engine too slow.
I've spent quite a bit of time trying to optimize the performance, but in the end it's browser performance that counts. The canvas renderer is much faster than the DOM one and the choice of browser brand counts too: e.g. in one benchmark, I get average frame time on 20ms in Firefox, 12ms in Opera and 10ms in Chrome (there is a small pause at the start of Firefox benchmark, perhaps it analyzed that GPU acceleration should be used and switched to that, so the number might be affected by that initial pause). You can test yourself here: http://tapio.github.com/unicodetiles.js/tests/
You should also try enabling the tile cache, but it probably maters only if you do heavy procedural "infinite" stuff.
If you really want to fill the screen with tiles, you should make the font bigger with CSS. No roguelike uses hundreds of tiles x hundreds of tiles viewport anyway.
@aave do you have a quick solution to getting contents of a tile from a mouse click?
Nope. Somehow I dislike mouse in roguelikes, so I have not given it any thought before. For the DOM renderer, it would probably be rather easy to attach an event handler to all of the tile elements on the engine side, but the canvas renderer needs fiddling with mouse coordinates, i.e. you need to get the mouse x,y, subtract the canvas x,y from that, then divide by the canvas w,h, multiply by tile counts in w,h and take the integer portion (or something along those lines). Not actually that hard probably, but I'm not too interested in adding the feauture (patches welcome though).
PS. I uploaded a new example (http://tapio.github.com/unicodetiles.js/examples/) I had lying around. It's not too exciting and presents a feature that has been in the engine for some time now, but still.
-
A quick dev update!
I added a QtWebkit based native wrapper app, so if you want to cheat those weird people who prefer native executables (http://roguetemple.com/forums/index.php?topic=2142.0) into liking you, this is what you have been wating for (works for any HTML5 game, not just Unicodetiles.js based). Also useful if you'd like to offer the game to someone who's stuck with IE.
In other news, I forgot to mention here that Kevin Mees has ported Unicodetiles to Ruby language. You can take a look at it here: http://kmees.github.com/projects/unicodetiles.html