I just read the thread on ScapeFX you linked. Wow. :ghostface: I couldn't get over the chip on Hephos' shoulder. At any rate, I'd like to quote 'tommi' from this post, and provide my answers.
Quote
In business there are some standards you should always follow before you announce anything,
1. know your products strengths and weaknesses, 2. know your competitors products strengths and weaknesses, 3. know what the market wants and needs, 4. know who your customers are and the best way to reach them.
1. It's based in the cloud, so you can play from any computer using the same settings. It will have a plugin API, though I haven't decided between client JS or server Lua. MUD admins can create a default interface for their MUD. One weakness is its lack of a direct interface with the OS, making certain things impossible or undesirable. Another is that it's not open-source, though I will (and have) open-source components such as Anachronism, my Telnet library. (I'm aware of elanthis' libtelnet, but there were a couple things I wasn't happy with.)
2. As mentioned, other clients have the benefit of interfacing directly with the OS. They also use your own computer's CPU, whereas Aspect may need some load optimizations. However, most downloadable clients take a lot of effort to customize (i.e. MUSHclient), or can't be customized at all. Even if you can customize it, your users may get the generic client instead of the specialized one out of ignorance. There is only one Aspect.
3. This is an interesting one. I know that the MUD community is small, so Aspect should attract new players to the field. I also see a number of customized interfaces for MUDs, such as Nexus (IRE) and FMud, and KaVir's MUSHclient plugins, so Aspect should make that easier to do.
4. My primary customers are the MUD admins. I have a few admins I want to contact when the time comes, and of course I'm posting here to give Aspect some coverage. After that it's unclear, but I'm hoping to take advantage of word of mouth, and player pressure on a MUD to register with Aspect.
And yes, it is likely that I will charge at some point. God, nothing like the insane ScapeFX prices though. (EDIT: Wait, ScapeFX is free now?)
I figured it would probably be a good idea to spawn a new thread for Aspect. Also, COLORS ARE WORKING! Next I'm going to clean up some of the code and work on the interface, which is currently held together by duct tape and wishful thinking.
Not yet! It's on the list, but it's not a huge priority. The ANSI sequence parser I wrote was made with xterm colors in mind, so it shouldn't be hard to implement.
One suggestion, from the way I implemented xterm256 in my LpMUD, if you do it abstractly, you can allow the user to switch display modes on the fly. That is, in my game, I can set my terminal type to xterm256 and see the full palette, or I can switch it to greyscale and it will downconvert tags to the 32 shades of grey that are in the xterm256 palette, or I can set to ANSI and it will downcode to the 16 regular ANSI colors.
So, if you recognize the incoming tags (MXP) or escape sequences (ANSI/xterm), instead of immediately setting the color, you could run it through another layer of filtering, which would let the end-user change colors as they wish. Besides cosmetic niceness, the ability to force greyscale or convert red/green to other values might help those who are colorblind.
This isn't pretty, but this is the code I used to generate the code my LP mud uses, and it's the part you would probably be interested in, as it does the color conversions.
I just added support for a few silly ANSI codes, like italics and negative image. :lol: I also killed an impressive amount of perceived lag by buffering up events from a packet and sending them all at once, rather than sending each event individually as it was detected. Since my ANSI parser is server-side currently [but not for long], it was sending a lot of events for ANSI-heavy data like the map in the screenshot I posted. Now it's pretty much instant.
EDIT: I've switched my rendering process from using inline styles (e.g. style="color: #FFFFOO;") to classes (e.g. class="fg11"). So far this means I can change the class of my output <div> to turn colors on and off completely, but it also means I can add the xterm palette very easily. Also, I am mightily impressed with the speed with which Chrome can do the change-over.
Do you support \e Do you support \e[22m as well as \e[90m to \e[97m and \e[100m to \e[107m?
[quote=[url=/topic-3362-54991#p54991]quixadhal[/url]]One suggestion, from the way I implemented xterm256 in my LpMUD, if you do it abstractly, you can allow the user to switch display modes on the fly. That is, in my game, I can set my terminal type to xterm256 and see the full palette, or I can switch it to greyscale and it will downconvert tags to the 32 shades of grey that are in the xterm256 palette, or I can set to ANSI and it will downcode to the 16 regular ANSI colors. [/quote] I wonder if someone could come up with a better down conversion algorithm (no offense meant), though it's not too much trouble to use a translation table with only 256 fields. One annoying issue is that there's no information about which clients support all available ANSI color codes.
Do you support \eDo you support \e[22m[/quote] Yes. [quote=[url=/topic-3362-55019#p55019]Scandum[/url]]as well as \e[90m to \e[97m and \e[100m to \e[107m?[/quote] [url=http://www.ecma-international.org/public... specced[/url] (8.3.117), so no. What do they do?
08 Apr, 2011, quixadhal wrote in the 11th comment:
I wonder if someone could come up with a better down conversion algorithm (no offense meant), though it's not too much trouble to use a translation table with only 256 fields. One annoying issue is that there's no information about which clients support all available ANSI color codes.
None taken. :)
In fact, if someone has a better algorithm, I'd love to see it. The one I used seems to be accurate, but too expensive to use in real-time, hence the reason my script generates a bunch of mappings which get used at runtime.
Out of the palettes you showed, Quix, I think I'm going to support the xterm-256 and greyscale palettes. There's no reason for me to support the xterm-to-ansi palette because, well, I'm going to support xterm-256. It makes sense for the MUD to change what it sends if the client doesn't support the full range, but it doesn't make sense for the client.
The nifty thing about this is that it makes player palette customizations a very real possibility.
Out of the palettes you showed, Quix, I think I'm going to support the xterm-256 and greyscale palettes. There's no reason for me to support the xterm-to-ansi palette because, well, I'm going to support xterm-256. It makes sense for the MUD to change what it sends if the client doesn't support the full range, but it doesn't make sense for the client.
The nifty thing about this is that it makes player palette customizations a very real possibility.
Some users may not like 256 colours. It's also a lot easier to customise 16 colours than 256.
as well as \eas well as \e[90m to \e[97m and \e[100m to \e[107m?[/quote] [url=http://www.ecma-international.org/public... specced[/url] (8.3.117), so no. What do they do?[/quote] Okay, just did some research. It looks like \e[90m is basically exactly like \e[1;30m, and \e[100m lets you use the bright colors for the background too (since 1 only affects the foreground). I should be able to implement that no problem.
Alright, implemented. Five lines.
[quote=[url=/topic-3362-55023#p55023]chrisd[/url]]Some users may not like 256 colours. It's also a lot easier to customise 16 colours than 256.[/quote] Point taken.
Success! xterm-256 is now supported. I haven't added the ANSI-downcoded or greyscale palettes yet, but I'll get to it. About 15 lines were added, not including the generated CSS.
I also fixed a number of bugs in my renderer, mostly due to how Javascript treats 0, "", and null as equal. I found a MUD called "8Bit-MUSH" that heavily - and I mean heavily - uses ANSI, and that really helped flush out the bugs.
Okay, just did some research. It looks like \eOkay, just did some research. It looks like \e[90m is basically exactly like \e[1;30m, and \e[100m lets you use the bright colors for the background too (since 1 only affects the foreground). I should be able to implement that no problem.[/quote] One thing to take into consideration is that if you print \e[91m\e[22mtest the color should still be bright red, while \e[0m\e[91m\e[31mtest should print test in dim red. They should behave a like 256 color code would, unaffected by the bold flag.
I'm not entirely sure about the origin of those codes, but xterm and several other terminal emulators support them.
I started using Fixedsys Excelsior in MUSHclient after playing with UTF-8. Something I noticed was that bold ANSI colours would also use the bold character set, which is slightly wider than the regular one, and therefore messes up the formatting of tables and such. Unselecting the "bold" box in MUSHclient resulted in using the bold characters for everything, and they're not very pretty. XTerm 256 colours allowed me to display the bright colours without switching to the bold character set.
However this brought up another issue: Some of my players reconfigure their ANSI colours in the client. With the switch to XTerm 256 colour, they suddenly found themselves using the "proper" colours instead of those they'd configured.
Okay, just did some research. It looks like \eOkay, just did some research. It looks like \e[90m is basically exactly like \e[1;30m, and \e[100m lets you use the bright colors for the background too (since 1 only affects the foreground). I should be able to implement that no problem.[/quote] One thing to take into consideration is that if you print \e[91m\e[22mtest the color should still be bright red, while \e[0m\e[91m\e[31mtest should print test in dim red. They should behave a like 256 color code would, unaffected by the bold flag.[/quote] Testing confirms that those cases work as described, but I do have a question. What should happen given \e[1;91;31m? My implementation would currently print text in dim red, but I suspect it should really be bright red. I can change this triially for the 90s codes, but xterm has a very unfortunate problem: \e[32;5;1m generates the exact same foreground color as \e[31m, yet the latter is affected by the bold flag while the former is not. This means I have to come up with a new flag or something… bleeech. What I have now:
[code]if @bright and fg? and fg < 8 fg += 8[/code]
I'm going to have to have, I don't know, an @xterm flag… Alright, changed. Feels like a hack, but it works.
I also fixed a number of bugs in my renderer, mostly due to how Javascript treats 0, "", and null as equal. I found a MUD called "8Bit-MUSH" that heavily - and I mean heavily - uses ANSI, and that really helped flush out the bugs.
You should be using the === and !== operators for equality checking, rather than == and != with JavaScript. Adding the extra = prevents casting, making the checks much faster and ensuring that 0, "", and null aren't treated as being equivalent values. DecafMUD pretty much never uses == and != because of that.
Yeah, I'm using CoffeeScript which has is and isnt operators that map to Javascript's !== and ===. It's just one of those things that catches you up unless you've been using Javascript a long time.
1. know your products strengths and weaknesses,
2. know your competitors products strengths and weaknesses,
3. know what the market wants and needs,
4. know who your customers are and the best way to reach them.
1. It's based in the cloud, so you can play from any computer using the same settings. It will have a plugin API, though I haven't decided between client JS or server Lua. MUD admins can create a default interface for their MUD. One weakness is its lack of a direct interface with the OS, making certain things impossible or undesirable. Another is that it's not open-source, though I will (and have) open-source components such as Anachronism, my Telnet library. (I'm aware of elanthis' libtelnet, but there were a couple things I wasn't happy with.)
2. As mentioned, other clients have the benefit of interfacing directly with the OS. They also use your own computer's CPU, whereas Aspect may need some load optimizations. However, most downloadable clients take a lot of effort to customize (i.e. MUSHclient), or can't be customized at all. Even if you can customize it, your users may get the generic client instead of the specialized one out of ignorance. There is only one Aspect.
3. This is an interesting one. I know that the MUD community is small, so Aspect should attract new players to the field. I also see a number of customized interfaces for MUDs, such as Nexus (IRE) and FMud, and KaVir's MUSHclient plugins, so Aspect should make that easier to do.
4. My primary customers are the MUD admins. I have a few admins I want to contact when the time comes, and of course I'm posting here to give Aspect some coverage. After that it's unclear, but I'm hoping to take advantage of word of mouth, and player pressure on a MUD to register with Aspect.
And yes, it is likely that I will charge at some point. God, nothing like the insane ScapeFX prices though. (EDIT: Wait, ScapeFX is free now?)
I figured it would probably be a good idea to spawn a new thread for Aspect. Also, COLORS ARE WORKING! Next I'm going to clean up some of the code and work on the interface, which is currently held together by duct tape and wishful thinking.