| 10-05-2003, 05:17 PM | #46 |
I managed to reduce the loading time of 79 lines to 16 milliseconds. Too bad 655 lines is still take 2179 milliseconds... :( But I won't give up!! I will keep optimizing whereever I can. |
| 10-05-2003, 09:38 PM | #47 |
It seems you are using some kind of algorithm with quadratic behaviour which I think is rather strange for syntax highlighting. What algorithm are you using ? |
| 10-06-2003, 03:47 PM | #48 |
I'm not using any "quadratic" algorithm. I guess the reason why the lines per millisecond increases is that I have some problems in my code atm. I just converted the method by which I highlight text, so it writes directly in RTF, and the problem will probably solve itself when I fix the other few (but vital) problems. Also, when you say "Full support for AI editing", keep in mind that I have never made a single AI script, nor do I intend to, so please be more specific about what you want. There are probably some functions used in AI scripting which you want implemented in the explorer. If that is the case, please tell me which file(s) they are declared in. If you want more templates added, please post them here. You won't be able to change their hotkeys, though. Things to be implemented/fixed: - Find + Find and Replace - Go to line # - Statusbar showing line- and charnumber. - Long loading time will be reduced. - Keep track of paranthesises Things already implemented/fixed: - Load/Save to Trigger Editor fixed - Sort functions/constants by their type/return type I'm still open for suggestions. EDIT Hey! I just got an idea! I'll make it keep track of paranthesises, by highlighting the corresponding end of the selected (, ), [ or ] For example if you had the text: call MyFunc( GetUnitLoc( GroupPickRandomUnit( GetGroup( x ) ) ) ) and you had the cursor on the second-last ")", it will underline the second "(" on the line. I added this to the list above. |
| 10-06-2003, 09:27 PM | #49 |
AI files take their natives and globals from common.ai But you can also use any other function declared in common.ai and most of the functions in common.j. (I think AIAndy knows exactly which functions from common.j don't work) So the perfect solution would be to read in the functions from the common.ai in one of your programm's folders, so the user could put a modified common.ai there and his own functions would be read in. |
| 10-07-2003, 09:53 AM | #50 |
Okay, I will add a tab to the explorer with all the functions in common.ai. Btw, I figured out that I was wrong earlier. The file I was opening was actually 1725 lines long instead of 655. That explains why the lines per millisecond didn't match. I will improve it even more if I can. |
| 10-08-2003, 02:20 AM | #51 |
It would be really cool if you can make it so that when you type in a blizzard.j/common.j/ai function, it would show you the prototype (parameters, etc) for it like this the pic below. Also, you should post the algorithm you use to highlight the code, as I'm quite sure a lot of the people here can help you improve it's runtime speed a lot. Finally, it would be amazing if you could implement a simple line by line syntax checker (using the code from Sourceforge) so that if you forget a = sign or something, it would warn you when you move to the next line instead of having to check the entire script every time. |
| 10-08-2003, 12:58 PM | #52 |
I have already thought about code insight and code completion etc. but it's pretty hard doing that real-time. I have found that the source of the lag is not in my own code, it's in the RichEdit code, which parses the RTF code and paints the component. If you really want to see the algorithm then have a look. *My code* I go through the text line by line. With each line, I split it up into tokens, where each of them are checked if they have a syntax. If they do have a syntax, it will put the proper RTF control characters on front of it and behind it, and return the RTF enhanced text. The main runner then assembles all the RTF text, and adds the needed RTF prefix and postfix to the entire text. Finally, the RTF text is thrown into the RichEdit's text. *Borland code* It somehow parses the RTF text, and paints the component. I use a common tokenizer (eg. check first character of text. Loop and increase the character, until end of file or character is no longer of the same type). When looking if a word has a syntax, and which syntax it has, I use binary search. Binary search is pretty fast so it's definately not that. In conclusion, it's not the algorithm but the methods which cause the lag. |
| 10-08-2003, 05:08 PM | #53 |
There is one thing in your code that could have a quadratic behaviour depending on the implementation. That is the assembling of the strings. If the concatenation of 2 strings has linear complexity instead of constant then the following has quadratic complexity: for x = 1 to n do s = s + stringline[x] Of course that depends a lot on the implementation of the string class. To test where the real problem is you could open a message box when you have assembled the text and then look at what time that message comes. Or you could run a timer while processing and then store what time each step needs. |
| 10-08-2003, 07:10 PM | #54 |
I am using an object called TStringList (T just signifies that it's a class name). Where I actually add the strings it looks like this: Code:
for I := 0 to Lines.Count-1 do RTF.Add( SyntaxHighlightLine(I, True) ); Of course, it might be hard to read if you don't the language pascal. Anyway, I'm sure that it doesn't have any quadratic behavior, because it stores the amount of strings in the list in a field variable, so it doesn't have to count them when adding a new one. |
| 10-08-2003, 08:17 PM | #55 |
Well, I guess the best method is to add some stops with the debugger and look where the time is lost or adding some message boxes at the respective positions. |
| 10-11-2003, 08:58 AM | #56 |
After numerous optimizations in the RTF code, I tried opening common.j. I was expecting it to take quite a while. BUT! It took exactly 1000 milliseconds to load! Note that this file is 2078 lines. Surprised by its performance I wanted to push it even further, and I dared opening Blizzard.j (9201 lines) It took 8547 milliseconds. Also, a couple of features are complete: - Find text - Find and replace text - Goto line - Display line number and line index on statusbar - Automatic bracket tracking (highlights selected bracket's opposite end) Now I'll start working on the Undo/Redo thing. It's not as easy as it sounds :bgrun: |
| 10-11-2003, 10:22 PM | #57 |
Good job, 8 seconds is much better for Blizzard.j than before. :D |
| 10-12-2003, 09:24 AM | #58 |
I have added two tabs to the explorer bar: AI Functions, and AI Constants. But seeing that the only AI Constants are the IDs of various units I decided to rename it to AI Globals and merge the constants and normal globals into one. I wondered if you want the normal Constant tab made into a Globals tab where both constants and global variables are listed. Well, do you want it constants only or all globals? |
| 10-12-2003, 05:21 PM | #59 |
This is sweet =) |
| 10-14-2003, 05:03 PM | #60 |
Ok I implemented a basic syntax checker which is very shortsighted. That means that it only looks at the first word of each line, and checks if the line is valid. Seeing that in Jass you have to use words such as set and call to make a statement, my job got a lot easier. However, I was unable to make a functional undo/redo feature, you'll have to make do without ://// |
