|
Joined: Feb 2005
Posts: 6
Nutrimatic drinks dispenser
|
OP
Nutrimatic drinks dispenser
Joined: Feb 2005
Posts: 6 |
if mirc can support more then 16 box color limit it would be good.
|
|
|
|
Joined: Feb 2003
Posts: 372
Fjord artisan
|
Fjord artisan
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!
|
|
|
|
Joined: Feb 2005
Posts: 6
Nutrimatic drinks dispenser
|
OP
Nutrimatic drinks dispenser
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..
|
|
|
|
Joined: Sep 2003
Posts: 4,230
Hoopy frood
|
Hoopy frood
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 Well maybe 3 depending on how its implemented.
|
|
|
|
Joined: Feb 2003
Posts: 307
Fjord artisan
|
Fjord artisan
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
|
|
|
|
Joined: Sep 2003
Posts: 4,230
Hoopy frood
|
Hoopy frood
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)
|
|
|
|
Joined: Feb 2003
Posts: 307
Fjord artisan
|
Fjord artisan
Joined: Feb 2003
Posts: 307 |
uhmm ok thanks for the tip...
|
|
|
|
Joined: Feb 2003
Posts: 32
Ameglian cow
|
Ameglian cow
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.
|
|
|
|
Joined: Sep 2003
Posts: 4,230
Hoopy frood
|
Hoopy frood
Joined: Sep 2003
Posts: 4,230 |
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 ** 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.
|
|
|
|
Joined: Feb 2003
Posts: 32
Ameglian cow
|
Ameglian cow
Joined: Feb 2003
Posts: 32 |
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. 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 ). 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.
|
|
|
|
Joined: Sep 2003
Posts: 4,230
Hoopy frood
|
Hoopy frood
Joined: Sep 2003
Posts: 4,230 |
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 ) 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.
|
|
|
|
Joined: Jan 2005
Posts: 44
Ameglian cow
|
Ameglian cow
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. (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.
|
|
|
|
Joined: Sep 2003
Posts: 4,230
Hoopy frood
|
Hoopy frood
Joined: Sep 2003
Posts: 4,230 |
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.
|
|
|
|
Joined: Dec 2002
Posts: 2,962
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 2,962 |
(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.
|
|
|
|
Joined: Sep 2003
Posts: 4,230
Hoopy frood
|
Hoopy frood
Joined: Sep 2003
Posts: 4,230 |
(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. 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 * 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.
|
|
|
|
Joined: Feb 2003
Posts: 32
Ameglian cow
|
Ameglian cow
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.
|
|
|
|
Joined: Sep 2003
Posts: 4,230
Hoopy frood
|
Hoopy frood
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.
|
|
|
|
Joined: Nov 2003
Posts: 2,327
Hoopy frood
|
Hoopy frood
Joined: Nov 2003
Posts: 2,327 |
I didn't read your whole post, but i'll reply anyway. Starbucks is right. && (AND)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 only parse the part before && the majority of the time. 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 often parse both parts of the statement and find that the part after the && is $false. || (OR)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. 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.
New username: hixxy
|
|
|
|
Joined: Dec 2002
Posts: 2,962
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 2,962 |
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. 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.
|
|
|
|
Joined: Dec 2002
Posts: 2,962
Hoopy frood
|
Hoopy frood
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 .
Spelling mistakes, grammatical errors, and stupid comments are intentional.
|
|
|
|
|