Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ MUSHclient ➜ MXP and Pueblo ➜ MXP Image

MXP Image

It is now over 60 days since the last post. This thread is closed.     Refresh page


Pages: 1  2  3  4  5  6 7  

Posted by Belgarath   (2 posts)  Bio
Date Reply #75 on Mon 01 Nov 2004 11:19 PM (UTC)
Message
Nick,

Images, at least with the Pueblo spec, are not as hard to implement as you might think. (it was one of the failings of Pueblo - loose control on the images. But it's biggest failing was to expect people to buy it - those people make their own graphic client for most control).

I am just brainstorming here, it might not match anything of what you are doing (but I have seen some simple clients that work this way).

First you get a good library for http connections, or you can write one. Find a good graphics library because writing one is an exercise in futility. It will determine which format you support (maybe snoop Pueblo's code and see what he is using - it does PNG).

When you do the http connection, if it fails (file not found, it's huge, it's not in a format you like) - you substitute a broken image icon, and make an entry in the MXP log. So you have an image, even if you don't.

If a size is defined, then reserve that space - this is where it might be hard, but usually you have to boil it down to pixels and that is what an image is. There are only three possibilities - left side of the screen at the cursor position, right of it, and center. Left means anything already there gets shoved to the right of the reserved space. Right means anything in the way gets booted to the next line. Center is a mix of those (I never use it anyway).

If the image was padding with the space a character occupies it would still be acceptable for most cases I am sure. Then you just make your text redraw routine not draw anything when it sees a special character in the text array (for example), and the image drawing is done after.

The only thing complicated is when the image size is not specified (caveat mud implementor!). However, depending on how the graphics routine is written, it may possible to just repeat the above bumping everything out of the way and then redraw.

I may yet have to put my money where my mouth is because I am thinking of writing a small Java text and graphic applet.
Are you interested?

Caching on disk can be done later. Run out of disk space? User dialog, don't write it. Heck, do like Windows and crash :P
Top

Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #76 on Tue 02 Nov 2004 05:34 PM (UTC)
Message
So.. In other words Pueblo (and probably others) cheats and doesn't really do 'inline', which would imply text wrapped around the image, not just adjusted a bit for it... Makes things easier, though it would still require Nick redesigning his custom output window to work, so it isn't exactly easy.
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #77 on Wed 03 Nov 2004 04:28 AM (UTC)
Message
We are up to page 6 of this thread, so I won't rehash most of the old arguments.

Basically, images may be easy to display per se if you have the appropriate snippet or code from somewhere, but my point is that the design of MUSHclient, as a text-only client, does not lend itself to easily incorporating images inline.

It would be a fundamental change to, say, how it calculates what line the mouse is on if you click somewhere, if there is not a direct relationship between pixels on the screen and lines. At present there is, say each line is 10 pixels high, you can easily work out what line is what.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by HR-Trevor   USA  (5 posts)  Bio
Date Reply #78 on Wed 21 Dec 2005 08:00 AM (UTC)
Message
I'd just like to say that with all due respect, resisting adding support for inline images is not a healthy thing for MUSHclient. I am sure that printers who believed books without pictures were purer made their job easier, and yes, it certainly allowed them time to devote to other aspects of text printing. But the truth is, versatility is key and just as a printer has a happier and wider client base if they are willing and capable of printing images alongside text, so would MUSHclient.

Having inline pictures doesn't detract from a text based game than having pictures in a book does. It's a matter of how the pictures are used, how often, how well placed and timed. In fact, this whole matter of "pure text" is really out of the scope of design as a whole. You wouldn't regulate MUSHclient by saying red is gaudy so the client won't display that color. You don't limit it from displaying certain font types or sizes. That's for the user (and in this case, the world creator) to decide.

I realize the bottom line here is, "Is adding pictures to a client that's been text-only from the start worth it?" but I think it should be looked as natural evolution and whether or not you choose to resist that evolution. A lot of things are being done in text games that weren't done in days past. More and more images, sound, context menus, specialty guages and controls -- just look at the emergence of XML based client applications for instance.

I can certainly respect if you, the author, feel it's not worth the time, but I can also say that it most definitely limits just how desirable and versatile MUSHclient is and can be to choose to exclude inline images. This isn't a very finite, specific request, this is a broad capability that could have a number of uses on many games worldwide.

Regards,

-- Rich
http://www.haelrahv.com
Top

Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #79 on Wed 21 Dec 2005 05:06 PM (UTC)
Message
No HR-Trevor, the **main** issue is how to successfully impliment it at all, given the custom desing of Nick's existing output system, without sacrificing speed and the existing functionality. Images require extra processing, tests to make sure you don't get buffer over flows, adding in true HTTP support, or at least functional code to download with, which for many of us does equal lag anyway. Placing the code in a seperate thread doesn't help that last issue, since additional text can't be shown until the image loads anyway. Its not a simple case of, "Plug this in, and it will work." Or if it was that simple, someone would need to give a concrete example of it in code, so Nick could *see* how to do it without the above problems.
Top

Posted by HR-Trevor   USA  (5 posts)  Bio
Date Reply #80 on Wed 21 Dec 2005 08:00 PM (UTC)
Message
Oh, I wasn't by any means implying it to be easy. I was responding to comments by Nick that interpreted to mean that he wasn't sure inline images had a viable role in the client.

But I will say that even the issue of performance should be carried in great part by world developers. I suppose this is a matter of opinion, but I don't personally see a fast text only interface versus a moderately paced mixed media interface as a reflection on the client used so much as a reflection on the game using them. Certainly there are also measures world designers can take to minimize impact too, including using formats and specifications for images that allows them to be rendered more quickly. I don't think Nick should feel obligated to bear all of that on his shoulders.

I saw a mention of the many image formats, for instance. While it would be nice to support all of those, I think that it's quite reasonable for MUSHclient to only support select common and efficient formats. I wouldn't even bother with BMP's for example, because they're ridiculously huge, if this is a matter of time/dev and we're looking for fat to cut. But then again, going back to my previous statement, if Nick did allow bmp's and world designers opted to use them when other formats may have been more efficient, that's no reflection on MUSHclient nor on Nick, it's a reflection on the world builder.

As it is now, MUSHclient is, in my opinion, the best and most versatile telnet client available - hands down. I've been using it for years. But, I still recognize the viability, and in my opinion, need for image support, and inline image support. But don't mistake my support for trivializing the actual technical aspects of implementation, that's an issue I'm not going to even begin to get involved in.

-- Rich
http://www.haelrahv.com
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #81 on Wed 21 Dec 2005 10:20 PM (UTC)
Message
I hear what you are saying about needing to move with the times. However the problem for me is that it is basically a rewrite of the entire outputting section, which has ramifications through a lot of the code. Banging an inline image in affects things like:


  • Where the cursor is when you click (ie. what word on what line)

  • Highlighting words when you do a find

  • Clicking and dragging the thumb to scroll.

  • Things like "omit from output" - what if the output line you are omitting had an image in it?

  • Trigger highlighting of words in lines.

  • The "info window" that pops up when you hover over a line

  • Caching the images

  • Emptying the cache sometime

  • Drawing different formats

  • Allowing for people who might be using 256 colours

  • Handling malformed images (eg. a GIF image that won't decomprses)


It could be done, especially if I wrote the client again from scratch.

However I'm inclined to think this is a bit of a hybrid solution. If you really want games with images, play an MMORPG - their graphics are fantastic these days. However if you like straight text, well that is the market MUSHclient is addressing.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #82 on Wed 21 Dec 2005 10:56 PM (UTC)
Message
Of course, some of those could be avoided by treating an image as having a newline both before and after the image, even when none is explicitly given, but I have to agree. MXP, while it does provide a neat feature that *could* be used well in some cases, its imho actually too limited and is little better than a hack. This is why most people build custom clients to add such graphics. MXP is the Mosaic of MUD protocols, doing some things that do pretty neat tricks with HTML, but its no Firefox, or even an IE, if you get my meaning. For it to be widely used it will require:

1. Clearer specs about what to do in some cases, like when you get and error.
2. Additional and better features.
3. If at all possible, am open source library for *correctly* implimenting those things.

Instead we have a spec that its own developer's client doesn't "quite" follow properly, features that should, but never actually are used, like full colors, and the ones that do get used are used badly, or, in the case of ones like images, only in maybe one tenth of one percent of the muds that exist. Maybe if/when Nick builds a true Linux version it can happen, but even then its probably easier to redo the existing system than try to add code to handle the images, despite how much I wish it did support some of these things.
Top

Posted by HR-Trevor   USA  (5 posts)  Bio
Date Reply #83 on Wed 21 Dec 2005 11:50 PM (UTC)
Message
Thanks for the explanations. I wasn't aware MXP had such underlying problems. I have to say that even just having a window or frame images went to would be nice though.

-- Rich
http://www.haelrahv.com
Top

Posted by Bobbiac   USA  (3 posts)  Bio
Date Reply #84 on Sun 17 Jun 2007 10:40 PM (UTC)
Message
I understand it would be a lot of work to change MUSHclient to do this. But being "open source" you are risking a fork if enough people want pictures.

Using your Photoshop analogy, they did start out somewhat primitive. However, their consumer base demand evolution and Adobe responded.


Mr. Gammon please don't let your baby run away.
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #85 on Sun 17 Jun 2007 11:29 PM (UTC)
Message
As I have tried to indicate, I think it would be an incredible amount of work to make that possible.

However, as it is now open source, someone who is keen to do so, is welcome to make an "image enabled" version.

Admittedly, most of the client wouldn't change. However you would need to alter the way lines are stored (as some lines would really be images and not text), obviously change the way they are displayed, make provision for obtaining the image in the first place, and change the way that it translates a mouse-click in the window to a line in the output buffer.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #86 on Mon 18 Jun 2007 01:15 AM (UTC)
Message
I don't see why we risk a fork. If somebody is willing to make the changes and does them well, and without breaking other things, I think chances are high that their work might get integrated into the main distribution.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top

Posted by Bobbiac   USA  (3 posts)  Bio
Date Reply #87 on Mon 18 Jun 2007 01:35 AM (UTC)

Amended on Mon 18 Jun 2007 01:36 AM (UTC) by Bobbiac

Message
well, would it be hard to supply BASIC levels of image parsing?

that is, to replace some of the ascii art in a mud i frequent, without click-through tags?
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #88 on Mon 18 Jun 2007 02:32 AM (UTC)
Message
Quote:

well, would it be hard to supply BASIC levels of image parsing?


Yes, that would be the hard bit. It is not so much parsing the image, but displaying it.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #89 on Mon 18 Jun 2007 03:06 AM (UTC)
Message
Frankly, I think at some point the "easiest" solution isn't to inline at all, but use a separate window for images. But, obviously this adds more code to the mess. And while FTP/HTTP support is a must (BTW, if done **please** try to find decent code that handles server resuming properly, instead of the garbage in most software and browsers, which is too stupid to tell the difference between a "failure" to complete and a finished file...), since it needs to operate in a separate thread, so as not to muck with client/script operation. Oh, and it needs bandwidth throttling. Some people might not mind waiting an extra 30 seconds or more to "see" an image, if displaying it over dialup didn't also make playing completely impossible while waiting. Most FTP/HTTP systems assume you are using the "full" bandwidth to get it as fast as possible, which isn't too helpful if you don't "have" that bandwidth.

In terms of script operation, obviously you would have something like:

world.download("http://bigfiles.com/mybigfile.dat", "c:\mydocu~1\mushstuff\)

sub OnPluginFTPComplete (name)
  if name = "mybigfile.dat" then
    'do some stuff...
  end if
end sub


Assuming you allowed some means to get other data through the script. A must if the data isn't and image, or is a format you can't handle internally, so do want to use some external system to deal with. You might also want to display existing images from your system, so functions for that could be useful. And, so things work well, you need to a) cache images in a scrollable window, so you can view any you may have missed, and b) have a pending download system, so if someone moves from one room to the next, either the prior one is halted, then shoved down the queue, or allowed to finish *before* the new one is shown. Which one is likely to depend on the player. Of course, there would be a cache for all images on disk, but the internal one would be X number from this "session" or "all from this session". Probably as a list, so they can be reloaded from disk, or resumed if you move back into the prior room.

My only real issue with the whole thing is, this adds more code to the client, without adding code that helps solve the problem I have always wanted to. Hear me out. What makes more sense, a window that supports objects, which just *happens* to be used to be used by the new feature for images, but whose same "image" code can be use in a script generated one to say, display you inventory graphically, or one that is hard coded only to deal with the images, requiring yet "more" code to be added to the client to handle the next trick we want pulled from the hat? The later is bound to bloat things far faster than a universal window which can be scripted to do other things.

Just saying, since, if this makes sense to people, maybe it would encourage them to look for how to do it too, not just leave me as the only one trying to find a solution. We want to avoid bloat, but every time we add new windows or features, without more generic support "for" them, we add even more code to the client, which we wouldn't necessarily need, if we had something more generic that could be adapted readily to do it. Just a thought.
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.


243,931 views.

This is page 6, subject is 7 pages long:  [Previous page]  1  2  3  4  5  6 7  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum


[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.