Text/html based display

[jcubic]

Is it possible to have text based (html) instead of canvas? If no is it possible to add some code on top of rot.js without the need to fork and modify the core?

Does creating new ROT.Display that work with html instead of canvas will work?

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/1540196-text-html-based-display?utm_campaign=plugin&utm_content=tracker%2F297828&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F297828&utm_medium=issues&utm_source=github).

[anissen]

Not at present. You might, however, be interested in a similar discussion going on at pull request #30.

[ondras]

There is no such feature. Furthermore, I see no actual benefit in doing so: the performance is going to be horrible (for an 80x25 display, 2000 DOM nodes?).

[jcubic]

I've created editor that use matrix of spans, demo have 3300 elements. I don't think that on modern browser/computer it will make big difference.

And other benefit is that you can apply css effects, without touching the code. Also you will be able to write code that interact with the game outside of the library.

I think that html is more flexible. Canvas is just image.

[ondras]

For the record, your 3.3k element demo is not exactly swift on my (rather old) Core Duo running latest Firefox.

I will probably try to implement some divs/canvas comparison myself later. But even if the bunch of <div> elements is performant enough, it looks like a waste of resources to me (compared with a <canvas>).

I hear the "available to select & copy" argument loud and clear; this is a limitation only solvable via HTML DOM.

CSS styling is problematic. What exactly do you want to style? ROT.Display is particularly good at managing all the styling related to visuals itself and further CSS customizations are almost certainly going to interfere (margin, padding, border, font-size, color, background-color, ... - all these properties will conflict with JS-based styling via ROT.Display::setOptions()). Furthemore, the individual <div> elements are going to be indistinguishable, so you won't be able to style those individually.

I would appreciate a real-life use case showing the need for a DOM renderer; this would help me decide.

Please note that one is not limited to ROT.Display exclusively: for some of my projects, I freely mix a ROT's canvas with other rich HTML features (see http://ondras.zarovi.cz/games/trw/ for an example).

Finally, I do not understand the "you will be able to write code that interact with the game outside of the library" argument. Can you please explain in more detail?

[jcubic]

You can for instance using css3 text-shadow to create glow. You will be able for instance add mouseover/mouseout events (don't know if you can do that right now). If you use jQuery you can easily add event to invidial elements using eq()

Also it would be nice if user can set specific classes to elements like 'player' class for '@' so you will be able to set style just for this element.

There are animations in CSS3.

Users will be able to change how rougelike game look like. Probably argument against.

If you decide not to create html based renderer you can just add a way to change renderer (don't know if that's possilbe without touching the library itself) to different one (object with the same API) so if someone will want for instance change display to use OpenGL will be able to do this.

Also one thing that I have in jQuery terminal is resize that don't scale but change number of columns and rows, and redraw the content to fit this new area, micro editor do the same. I have project leash that use terminal and I would like to create command that wil run the game, my own or existing one. and it would be nice if the game act the same as terminal.

[ondras]

ROT.Display provides means to convert event coordinates into character coordinates. This can be used to handle mouse events (just add "mousemove" to the whole canvas).

ROT.Display also offers the feature you mentioned, i.e. "compute a proper number of rows/cols for a given viewport size and font size".

After reading some of the use cases you describe, I am unsure whether ROT.Display is the proper way to go. Why don't you call your own drawing routine that picks the correct absolutely positioned <div> and sets its contents? This would give you the flexibility you want - not sacrificing anything, as most ROT.Display's features are based on emulating CSS.

The CSS3 transitions/animations are a particularly good example. I really enjoy using them (outside of roguelike projects), but they are completely incompatible with ROT.Display (if you start transitioning stuff via CSS3, how does this correspond to ROT.Display's data cache? What if the display resizes itself during a transition? etc...).

There is really no need to use ROT.Display as the only way of outputting stuff.

[msarchet]

@jcubic I would suggest that you take a look at pixi. It is a super powerful 2d renderer for the browser. It does a lot of what you are wanting to do. I'm currently making use of some of ROT to render maps onto it.