On Mon, Nov 15, 2010 at 07:15:55PM -0800, Enne Walker wrote:
> 2010/10/28 Adam Borowski <kilob...@angband.pl>:
> > I think the only operations that Crawl uses are:
> > * drawing text into a panel/tooltip; these panels contain nothing elseC
> > * drawing a rectangular part of a big texture, with alpha, over blackness or
> > underlying things (also parts of that big texture)
> > * the minimap
> >
> > Even in plain HTML the two first are easy, it'd be just a matter of checking
> > what works best: a big table, 80x70+ divs, or SVG. The minimap is trickier,
> > but even if done completely server-side it won't cause unacceptable delays
> > as it's a small image.
>
> This is a minor point, but canvas might be a better option for both
> the map and the minimap. Most browsers will have this hardware
> accelerated by the time you need it, especially the "draw a subimage
> to the canvas" bit.
There's a problem with canvas here: no versions of Internet Explorer support
it, and even in the not yet released IE9 the support is reportedly very
shaky -- not to mention that it won't work on WinXP which is what any sane
Windows users use. Tables and positioned divs are supported everywhere, SVG
on IE <9 requires a plugin (there are several to choose from), but in that
case the browser itself will guide the user how to install one (if we
provide an URL).
> >> For example, after the refactoring in the second milestone is complete the
> >> JSON blobs could become updates instead of full refreshes of the game.
> >
> > Because of the way map_knowledge works, I see no benefit in sending the
> > whole table every time instead of just updates.
>
> If you are only sending map updates, you're more or less going to need
> to reimplement 90% of tile*.cc in Javascript. The advantage to a C++
> tiles client is that the code already exists, you just have to
> abstract the client from the server. In Javascript, you'll have to do
> the Crawl type -> tile indices -> texture coordinate lookup yourself
What I was thinking about is sending not the monster_info structures over,
but already cooked coordinates to texture fragments. Ie, "draw region
192,64+32+32 of floor.png into cell 21,35".
> Also, if you want the on-screen inventory, spells, monster list, &c you'll
> need to implement all of that in Javascript as well.
My solution would require contacting the server when you switch between
inventory, spells and monster lists, but I'm not sure if that's done that
often.
Or alternatively, we can send a cooked list of texture fragments together
with monster_info -- so the client would be able to do most logic by itself
but won't have to think how to draw it. Ie, instead of a monster type as an
int, the client would receive a textual name of the monster, a list of flags
and a list of texture fragments needed to draw it.
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
Crawl-ref-discuss mailing list
Crawl-ref-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/crawl-ref-discuss
