mIRC Home    About    Download    Register    News    Help

Print Thread
Page 1 of 2 1 2
16 color box limit #110457 07/02/05 01:49 PM
Joined: Feb 2005
Posts: 6
L
ladyevene Offline OP
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
L
Joined: Feb 2005
Posts: 6
if mirc can support more then 16 box color limit it would be good.

Re: 16 color box limit #110458 07/02/05 04:01 PM
Joined: Feb 2003
Posts: 372
R
Rounin Offline
Fjord artisan
Offline
Fjord artisan
R
Joined: Feb 2003
Posts: 372
This should be possible - mIRC supports more than 16 color codes, but I believe a lot of them represent the same color. I'm sure this has been discussed before though - I advise you to try the search, and set the time limit to include really old posts!

Re: 16 color box limit #110459 07/02/05 04:39 PM
Joined: Feb 2005
Posts: 6
L
ladyevene Offline OP
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
L
Joined: Feb 2005
Posts: 6
mirc support the colors with replacing in the limited 16 color box,if just more 4 5 more color box without changing the 16 box colors it would be nice,i couldn't find any add-on that extends the 16 color box..

Re: 16 color box limit #110460 07/02/05 07:31 PM
Joined: Sep 2003
Posts: 4,230
D
DaveC Offline
Hoopy frood
Offline
Hoopy frood
D
Joined: Sep 2003
Posts: 4,230
mirc likely stores color changes in one byte so cant get any more than 16 colors since there isnt no more room in the byte, why its one (or if it is) I have no idea, but if it was going to be changed, well heck let it go all the way to truecolor 24bit, its only going to be 6 bytes smile Well maybe 3 depending on how its implemented.

Re: 16 color box limit #110461 10/02/05 05:03 PM
Joined: Feb 2003
Posts: 307
T
tontito Offline
Fjord artisan
Offline
Fjord artisan
T
Joined: Feb 2003
Posts: 307
Hello, correct me if i am wrong but isn't a byte = 8 bits can go from 0 to 255, can't this be used to code the colores?

thanks

Re: 16 color box limit #110462 10/02/05 09:26 PM
Joined: Sep 2003
Posts: 4,230
D
DaveC Offline
Hoopy frood
Offline
Hoopy frood
D
Joined: Sep 2003
Posts: 4,230
yeah your right, 4 bits for the forground color, 4 bits for the background color, 8 bits in total, 4 bits = 16 options (in this case colors)

Re: 16 color box limit #110463 11/02/05 07:09 AM
Joined: Feb 2003
Posts: 307
T
tontito Offline
Fjord artisan
Offline
Fjord artisan
T
Joined: Feb 2003
Posts: 307
uhmm ok thanks for the tip...

Re: 16 color box limit #110464 16/02/05 05:58 AM
Joined: Feb 2003
Posts: 32
P
praetorian_ Offline
Ameglian cow
Offline
Ameglian cow
P
Joined: Feb 2003
Posts: 32
It is highly doubtful that mIRC uses a single byte to process color codes. The information is presented as two integer values as part of a string. It would be more complicated to transform the codes into a bitwise value (string -> int -> byte-order -> byte) than to just parse them as integers (string -> int).

The most obvious reason as to why only 16 colors are allowed is the fact that no other clients (that I know of) support more than 16 colors. Extending the palette would create problems for other IRC applications, and I'm sure Khaled is aware of this.

Re: 16 color box limit #110465 16/02/05 08:53 AM
Joined: Sep 2003
Posts: 4,230
D
DaveC Offline
Hoopy frood
Offline
Hoopy frood
D
Joined: Sep 2003
Posts: 4,230
Quote:
It is highly doubtful that mIRC uses a single byte to process color codes. The information is presented as two integer values as part of a string. It would be more complicated to transform the codes into a bitwise value (string -> int -> byte-order -> byte) than to just parse them as integers (string -> int).


Well everything is more complicated than if u dont do it now isnt it, doesnt mean you shouldnt do it tho does it. And a bitwise move is hardly rocket sience now is it.

And how the information is presented (to mirc) as two integers in a string doesnt mean thats how its stored in mirc to produce colors. Although Im not saying its not 2 bytes either.
An example of this is the following...
/echo 10,98abc98,12def13,98ghi

(* note my forground color is 1 & background color is 15)

highlight the text with the CTRL key down, then paste it into the editbox
10,15abc98,12def13,98ghi

now highlight the cdef with the CTRL key down, then paste it into the editbox
c98,12def

now highlight the def with the CTRL key down, then paste it into the editbox
1,12def

now highlight the fghi with the CTRL key down, then paste it into the editbox
f13,98ghi

now highlight the ghi with the CTRL key down, then paste it into the editbox
13,15ghi

An Inital ctrl-k colorization of text retrieved does not match that which it was set to ie: 98 becomes 1 or 15 depending if it was foreground or background, this alone would lead me to believe that each character has a seperate stored color value, and the ctrl-k codes that exist are simply stored for re-refrence sakes, rather than actually being used to color the text.

There are some other interestingish things such as
/echo <ctrl-k>1<ctrl-u><ctrl-b><ctrl-r>abc
highlight the text with the CTRL key down, then paste it into the editbox
1abc ... <ctrl-b><ctrl-u><ctrl-r><ctrl-k>1abc<ctrl-o>

Now this might be a result of a look back system to define what colors & appaernece it should be or it could be stored per byte as it went, i wouldnt like to hazzard a guess at which it is, with out greater study.

Here is a possable packaging of 2 bytes to represent each characters color and apparence
1 bit bold
1 bit underline
1 bit reverse
1 bit foreground value represents a numeric not a color
5 bits forground color (using 4 bits) || numeric representing one of the possable forground selectable texts ie "action text" "ctcp text" etc (using 5 bits)
1 bit background value represents a numeric not a color
4 bits forground color (using 4 bits) || numeric representing one of the possable forground selectable texts ie "windowl background" "listbox background" etc (using 2 bits)
2 bits still free

** Please remember everything about how mirc MAY pack info is speculative **


Quote:
The most obvious reason as to why only 16 colors are allowed is the fact that no other clients (that I know of) support more than 16 colors. Extending the palette would create problems for other IRC applications, and I'm sure Khaled is aware of this.


If this was the concern this doesnt limit the ability of local colorizing beyond 16 colors, it could have been simply noted that any value higher than 15 would be made mod 16.

Re: 16 color box limit #110466 16/02/05 06:01 PM
Joined: Feb 2003
Posts: 32
P
praetorian_ Offline
Ameglian cow
Offline
Ameglian cow
P
Joined: Feb 2003
Posts: 32
Quote:

Well everything is more complicated than if u dont do it now isnt it, doesnt mean you shouldnt do it tho does it.


Actually, it does mean you shouldn't do it. In terms of CPU cycles, the bitwise shifting would take more resources than a simple string-to-integer parse. Given that control codes are processed in each line displayed to a window, the speed of the parser is of the utmost importance.

What you have described is certainly possible and might prove advantageous given the right situation, however in this context it is not plausible to do the extra processing required, which provides no added advantage over a simple string parser.

Quote:
If this was the concern this doesnt limit the ability of local colorizing beyond 16 colors, it could have been simply noted that any value higher than 15 would be made mod 16.


That is a good point and would likely be the best solution for the problem and would prove easy to implement, however input text would need to be parsed and any values greater than 15 would be N % 16 - 1 (since it's zero based wink). Furthermore, various shades of red would have to be parsed in such a way that they turned out to be red, otherwise mIRC's extended control codes would look like random colors to any other client.

Re: 16 color box limit #110467 16/02/05 10:17 PM
Joined: Sep 2003
Posts: 4,230
D
DaveC Offline
Hoopy frood
Offline
Hoopy frood
D
Joined: Sep 2003
Posts: 4,230
Quote:
Quote:

Well everything is more complicated than if u dont do it now isnt it, doesnt mean you shouldnt do it tho does it.


Actually, it does mean you shouldn't do it. In terms of CPU cycles, the bitwise shifting would take more resources than a simple string-to-integer parse. Given that control codes are processed in each line displayed to a window, the speed of the parser is of the utmost importance.


You based that on a simple point that this is true IF the text well only ever be parser once, If mirc is based like this the parser would need to reparse the text everytime someone scrolled the window up or down, as that window is not a text box but a graphic window. ( refrence: see "The explanation" under /help Text Copy and Paste )

Quote:
What you have described is certainly possible and might prove advantageous given the right situation, however in this context it is not plausible to do the extra processing required, which provides no added advantage over a simple string parser.


Take into account that a simple parser must/may have to reparse the screen over and over, and verse that against a simple read of info on how it should look becuase its already been parsed once.
And I can see a clear advantage. (if it really made much difference either way, I have coded in assembler and you can really jame a hidiously wastefull loop in and still come out smelling of roses over any highlevel langauge.

Im not actually saying either of these are how mirc actually does this. But I know that alot of things that appear wastefull of time or irelevent in the way you might do them, are often more advatages when placed into a bigger picture of how things must be used. an example just in mirc scripting is the difference in the way i see peoples coding take for example these to appearingly similar if statments (assume a all covering ON *:TEXT: event is in progress)

(1) if (!allow * iswm $1-) && ($nick isop $chan)
(2) if ($nick isop $chan) && (!allow * iswm $1-)

The 2nd of these IFs is far more efficent code, but most people (im not excluded here) becuase of how were taught to think from begining to end. well mostly go with the first option.

Re: 16 color box limit #110468 16/02/05 10:33 PM
Joined: Jan 2005
Posts: 44
S
Splatted Offline
Ameglian cow
Offline
Ameglian cow
S
Joined: Jan 2005
Posts: 44
Sorry, off-topic question, but.. why is the second more efficient?

Are you saying that if the ($nick isop $chan) bit were false, mirc wouldn't bother checking whether (!allow * iswm $1-)
is true? (and since we only want it checking the second bit only while we are opped, it's more efficient?)

I always thought that whatever you put after the IF would get evaluated and checked regardless, hence order would make no difference.

Quote:

(1) if (!allow * iswm $1-) && ($nick isop $chan)
(2) if ($nick isop $chan) && (!allow * iswm $1-)

The 2nd of these IFs is far more efficent code, but most people (im not excluded here) becuase of how were taught to think from begining to end. well mostly go with the first option.

Re: 16 color box limit #110469 16/02/05 11:16 PM
Joined: Sep 2003
Posts: 4,230
D
DaveC Offline
Hoopy frood
Offline
Hoopy frood
D
Joined: Sep 2003
Posts: 4,230
Quote:
Sorry, off-topic question, but.. why is the second more efficient?

Are you saying that if the ($nick isop $chan) bit were false, mirc wouldn't bother checking whether (!allow * iswm $1-)
is true? (and since we only want it checking the second bit only while we are opped, it's more efficient?)

I always thought that whatever you put after the IF would get evaluated and checked regardless, hence order would make no difference.


As soon as the if condition can be defined as false or true no further testing of conditions is done.

example
alias x1 { echo -a x1 $1 | return $false }
alias x2 { echo -a x2 $1 | return $true }
alias x3 { echo -a x3 $1 | return $false }
alias test { if (($x1(a) == $x2(b)) || ($x2(c) == $x2(d)) || ($x1(e) == $x3(f))) { echo -a IF conditions met } }

/test
x1 a
x2 b
x2 c
x2 d
IF conditions met

evaluation of ($x1(e) == $x3(f)) never occurs, this is the most common method of if evaluation of any language I know of.

Re: 16 color box limit #110470 16/02/05 11:36 PM
Joined: Dec 2002
Posts: 2,962
S
starbucks_mafia Offline
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
Quote:
(1) if (!allow * iswm $1-) && ($nick isop $chan)
(2) if ($nick isop $chan) && (!allow * iswm $1-)

The 2nd of these IFs is far more efficent code, but most people (im not excluded here) becuase of how were taught to think from begining to end. well mostly go with the first option.

- Quite the opposite. It's far more unlikely for someone to be saying '!allow ...' than for them to be an op. The point of shortcut evaluation is to put the condition that is least likely to be true first with the and operator and the most likely first with the or operator. If your reasoning was meant to be that isop works faster than iswm then I'm afraid benchmarks show them to be approximately equal.


Spelling mistakes, grammatical errors, and stupid comments are intentional.
Re: 16 color box limit #110471 17/02/05 01:56 AM
Joined: Sep 2003
Posts: 4,230
D
DaveC Offline
Hoopy frood
Offline
Hoopy frood
D
Joined: Sep 2003
Posts: 4,230
Quote:
Quote:
(1) if (!allow * iswm $1-) && ($nick isop $chan)
(2) if ($nick isop $chan) && (!allow * iswm $1-)

The 2nd of these IFs is far more efficent code, but most people (im not excluded here) becuase of how were taught to think from begining to end. well mostly go with the first option.

- Quite the opposite. It's far more unlikely for someone to be saying '!allow ...' than for them to be an op.


Lets see, the !allow command can only be activated by an OP so lets say we have 1 op and 99 users, every single one of them typer !allow blah

using method (1) there are 100 iswm and 100 isop done
using method (2) there are 100 isop and 1 iswm done

Are you telling me 100 iswm's and 100 isop's are "approximately equal" to 100 isop's and 1 iswm ?

The likely hood of someone saying something has no bearing on if its being checked for.


Quote:
The point of shortcut evaluation is to put the condition that is least likely to be true first with the and operator and the most likely first with the or operator.


Thats a narrow view on its purpose im also not sure if in all cases that even holds, from what I know historicly it originated from coders wanting to put there accessing of something into the the same IF as there bound checking of it, such as beinga able to replace...
IF Element(x).exists { IF Element(x).result { ... } } * becuase you cause an error attempting a Element(x).result if it doesnt exist *
with
IF Element(x).exists && Element(x).result { ... } * becuase now no error occurs beucase no Element(x).result is done if it doesnt exist *

The first refrences to this I ever saw were, detecting division by zero errors and subscript out of range on arrays
if (x != 0) && ((y / x) > z) { .... } * under some early compilers this would produce runtime errors when x = 0, regardless of the fact the condition should have be protected by the != 0
if (x >= 0) && (x <= array().size) && (array(x) != y) { .... } * again produce runtime errors of out of bounds on array *


Quote:
If your reasoning was meant to be that isop works faster than iswm then I'm afraid benchmarks show them to be approximately equal.


Actually I found benchmarking on that simple iswm to be faster than isop, but as i have said above In the end the !allow command is only for ops so why even test if it was said if there not an op.

Re: 16 color box limit #110472 17/02/05 03:41 AM
Joined: Feb 2003
Posts: 32
P
praetorian_ Offline
Ameglian cow
Offline
Ameglian cow
P
Joined: Feb 2003
Posts: 32
Your resistance is futile. DaveC is the resident expert in all things related to computers and will be more than happy to inform you of your ignorance, regardless of whether you are right or wrong.

If the omnipotent DaveC is unable to thwart your attacks using logic or actual facts, he will formulate a post so lengthy and poorly connected that merely reading it will instantly render you incapable of reply.

If the sheer bulk of a DaveC post does not sufficiently boggle your mind, the copious amount of spelling mistakes, vague references to historical factoids (which may be real or imagined; such details do not concern DaveC) or random pastings of code will.

I have reached an epiphany on this forum tonight; the only winning move in DaveC's diabolical posting game is not to play.

Re: 16 color box limit #110473 17/02/05 04:20 AM
Joined: Sep 2003
Posts: 4,230
D
DaveC Offline
Hoopy frood
Offline
Hoopy frood
D
Joined: Sep 2003
Posts: 4,230
Well thanks, glad to know you know your place.

Now Stay in it, unless you got soemthing to say.

PS: spelling mistake(s) included just for you.

Re: 16 color box limit #110474 17/02/05 04:22 AM
Joined: Nov 2003
Posts: 2,327
T
tidy_trax Offline
Hoopy frood
Offline
Hoopy frood
T
Joined: Nov 2003
Posts: 2,327
I didn't read your whole post, but i'll reply anyway.
Starbucks is right.

&& (AND)

Code:
if (!allow * iswm $1-) &amp;&amp; ($nick isop $chan) {  }


With the above, since it's not as likely that !allow <text> was said in the channel as it is that the person is an operator mIRC will only parse the part before && the majority of the time.

Code:
if ($nick isop $chan) &amp;&amp; (!allow * iswm $1-) {  }


With the above, since it's more likely that someone will be an op than it is that someone says !allow <text> in the channel, mIRC will often parse both parts of the statement and find that the part after the && is $false.

|| (OR)

Code:
if (!allow * iswm $1-) || ($nick isop $chan) {  }


With the above, since it's not as likely that !allow <text> was said in the channel as it is that the person is an operator mIRC will have to parse both parts of the statement because the part before the || will be $false the majority of the time.

Code:
if ($nick isop $chan) || (!allow * iswm $1-) {  }


With the above, since it's more likely that someone will be an op than it is that someone says !allow <text> in the channel, mIRC will only have to parse the part before the || the majority of the time.

Benchmarks aren't needed here, logic itself will tell you that Starbucks is right. smile


New username: hixxy
Re: 16 color box limit #110475 17/02/05 11:52 PM
Joined: Dec 2002
Posts: 2,962
S
starbucks_mafia Offline
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
Quote:
Lets see, the !allow command can only be activated by an OP so lets say we have 1 op and 99 users, every single one of them typer !allow blah

using method (1) there are 100 iswm and 100 isop done
using method (2) there are 100 isop and 1 iswm done

Are you telling me 100 iswm's and 100 isop's are "approximately equal" to 100 isop's and 1 iswm ?

Where did that clause come from? Nowhere before did you ever say that the '!allow ...' text was only relevant if an op says it - you're changing the rules in the middle of the game.

It doesn't really affect what I said anyway, because on most channels I would expect there to be a far higher ratio of ops[color:red]:non-ops[/color] than there is of '!allow ...' text[color:red]:non-'!allow ...' text[/color] on a channel. So your example is completely flawed. Yes, if 100 people say '!allow blah' and only 1 is an op then your original assertion is correct, however I can just as easily turn this around and say "What if 100 users on a channel are all ops and they each say something, only one of them says '!allow blah' - therefore my way is more efficient'. Of course that's a very flawed example also because it's very unlikely that all the people speaking in a channel will be ops. However, it is far more likely that someone speaking won't be saying '!allow ...' than it is that someone speaking won't be an op, and therefore my original post is still correct regardless of your added 'ops only' rule.



Quote:
Quote:
The point of shortcut evaluation is to put the condition that is least likely to be true first with the and operator and the most likely first with the or operator.
Thats a narrow view on its purpose im also not sure if in all cases that even holds, from what I know historicly it originated from coders wanting to put there accessing of something into the the same IF as there bound checking of it, such as beinga able to replace...

Well, no it's not applicable in all cases. If one condition takes an amount of time to resolve that's disproportionately larger than the difference between it and another condition failing then it would make sense to put the faster condition first anyway. However that's definitely not the case with what we're talking about here. Anyway, I didn't mean the sole point of shortcut evaluation existing was to be more efficient by putting conditions in a certain order (although that's certainly a major one), I simply meant that in order to get the efficiency boost that shortcut evaluation offers you should place your conditions in that order.

Re: 16 color box limit #110476 17/02/05 11:54 PM
Joined: Dec 2002
Posts: 2,962
S
starbucks_mafia Offline
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
It's not a problem for me. I can easily be as arrogant and verbose as anyone else on these boards wink.


Spelling mistakes, grammatical errors, and stupid comments are intentional.
Page 1 of 2 1 2