For what it's worth I was (and hopefully will be again) working on an
iPad port. Most of what I did was generalize tile* so that you could implement
your own windowmanager, 3d, and type renderer, if you so desired, to this exact
end.From what I was able to do I believe that it would be possible for you to
make a js version of the windowmanager and glmanager code that emitted state in
some way that js was able to read and present to the client in whatever way you
felt was necessary. I don't know nearly enough about how webservers work or
js to tell you exactly how to do this, but I'd like to dissuade people of the
idea that the entire thing needs to be rewritten.That said, I am all for a
greater diversity of target platforms for the crawl client and if anyone needs
any info about the files I've touched just let me know.
-- Chris Galardi (used to be c...@325i.org)Sent with Sparrow
On Monday, November 15, 2010 at 11:04 PM, Henry Cipolla wrote:
Thanks for the reply.I agree with you that the JS client is more
starting from scratch than a C++ client. However, I think all I need to do is
put together a very rough proof of concept and then it would be easy for
anybody to take the client and run with it as a project. The nature of
Javascript makes this a very good project for a younger developer looking for
an exciting project. The real goal of this project is for there to one day be
many clients, an iPhone client, web client, a really good bot-interface, etc.
I do, however, reserve the right to give up and fall back on a native client
w/o shame! :)-- HenryOn Mon, Nov 15, 2010 at 10:15 PM, Enne Walker
<enne.wal...@gmail.com> wrote:2010/10/28 Adam Borowski <kilob...@angband.pl>:
> On Thu, Oct 28, 2010 at 12:29:16AM -0400, Henry Cipolla wrote:
>> There is currently a document outlining how to get there:
>> https://crawl.develz.org/wiki/doku.php?id=dcss:brainstorm:internal:clientserver
>>
>> However, my impression is this plan has been around for a while but hasn't
>> actually gained much traction. If that is incorrect, I apologize.
>
> It's not that -- there is consensus that this is the way to go forward, it's
> just that people doing that (Luca and to some point by) are inactive due to
> RL duties. If someone like you could carry on, it would be wonderful.
This is an extremely belated reply, but I'll second that. Having a
better net tiles implementation would be quite awesome.
>> 5) Update that client to actually parse the JSON and draw the map and info
>> based on the values in the JSON.
>
> 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.
>> 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
in Javascript, which may not be so speedy. To be performant you'll
likely need to rewrite the drawing routines to redraw less. Also, if
you want the on-screen inventory, spells, monster list, &c you'll need
to implement all of that in Javascript as well.
Don't get me wrong, I'd *love* to see a Javascript-based Crawl client.
I think it'd be awesome and it'd do a lot of good towards sucking in
new players. Maybe this is all less work than I'm thinking, but it
looks like quite a bit from my perspective and also quite a bit more
than a pure C++ client.
-enne
------------------------------------------------------------------------------
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
------------------------------------------------------------------------------Beautiful
is writing same markup. Internet Explorer 9 supportsstandards for HTML5, CSS3,
SVG 1.1, ECMAScript5, and DOM L2 & L3.Spend less time writing and rewriting
code and more time creating greatexperiences on the web. Be a part of the beta
todayhttp://p.sf.net/sfu/msIE9-sfdev2dev_______________________________________________Crawl-ref-discuss
mailing
listcrawl-ref-disc...@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/crawl-ref-discuss
------------------------------------------------------------------------------
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
